Nabble - Gnome - NetworkManager

Mail bounces

2009-12-17T01:22:54Z

Mail bounces

This address is active

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NM-vpn no vpn secrets

2009-12-17T00:21:59Z

I am on Karmic.

Actually if a try multiple times to connect after 3 attempts (or so) it
will connect.

Tried the suggestion below, but Karmic also does not use libexec. I have
no idea how to start up the service on Karmic. Any suggestions?

Ferry

Op woensdag 16-12-2009 om 17:27 uur [tijdzone -0800], schreef Dan
Williams:

> On Sun, 2009-12-06 at 22:55 +0100, Ferry Toth wrote:
> > I confirm this issue.
> >
> > However in my sometimes NM connects to the vpn (openvpn) without
> > problems and sometimes is doesn't. This does not depend on the openvpn
> > server as other machines work fine,as well a previous version of
> > nm-applet.
> >
> > I my case I have a CA cert, a certificate and a key cert (which does
> > not need a password).
> >
> > It may be a problem with the state machine of the networkwork manager?
>
> If you want more information about the problem, you can (as root):
>
> 1) killall -TERM nm-openvpn-service
> 2) OPENVPN_DEBUG=1 /usr/libexec/nm-openvpn-service
> (or wherever it's at on your system, Debian doesn't use libexec)
>
> and then try to connect. It'll spew out a load of debugging information
> which is necessary to figure out what's going wrong.
>
> Dan
>
>

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Reconnection after manual disconnection still fails

2009-12-16T22:22:03Z

Hi,

I have reconnection problems with an Huawei K3715 similar to the
following bug report:

https://bugzilla.redhat.com/show_bug.cgi?id=541314

I'm not using NetworkManager, I have my own Python backends/scripts to
establish the connection:

- Enable the modem
- Send the PIN
- Call Connect("*99#")
- Got CONNECT from the modem
- Start pppd and set DNS and default gateway
- Done

Now when I want to disconnect,

- Send SIGTERM to pppd,
- Call Disconnect() on modem.

I clearly see the state transition from MM's console output. And it also
says

(/dev/ttyUSB0) closing serial device...

Now if I call Connect() or getSignalQuality() I always got a DBus exception:

SerialSendFailed: Sending command failed: device is not enabled.

I have to unplug and replug the device.
I'm using the latest MM from git.

Thanks,
Ozan
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

http-proxy with Open-VPN

2009-12-16T18:23:22Z

Is there an option in GConf to set the Open-VPN plugin to use a proxy?

Thank you!
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Creating VPN plugin using dbus interface

2009-12-16T17:37:53Z

On Sun, 2009-12-06 at 02:49 +0000, Maciej Piechotka wrote:
> I found that in org.freedesktop.NetworkManager.VPN.Plugin in
> Connect/NeedsSecrets connections are described by a{sa{sv}}. I
> understend why a{sv} as it 'logically' map between setting name and
> value - but why additional a{s...}?
>
> Especially that for example in QT it is described as QMap<QString,
> QString>&.

Eckhart Woerner <ewoerner@...> has been doing work in this area...
might want to contact him about it, I know he's developed a Qt-based
plugin helper:

http://gitorious.org/nm-iodine

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NM-vpn no vpn secrets

2009-12-16T17:27:09Z

On Sun, 2009-12-06 at 22:55 +0100, Ferry Toth wrote:

> I confirm this issue.
>
> However in my sometimes NM connects to the vpn (openvpn) without
> problems and sometimes is doesn't. This does not depend on the openvpn
> server as other machines work fine,as well a previous version of
> nm-applet.
>
> I my case I have a CA cert, a certificate and a key cert (which does
> not need a password).
>
> It may be a problem with the state machine of the networkwork manager?

If you want more information about the problem, you can (as root):

1) killall -TERM nm-openvpn-service
2) OPENVPN_DEBUG=1 /usr/libexec/nm-openvpn-service
(or wherever it's at on your system, Debian doesn't use libexec)

and then try to connect. It'll spew out a load of debugging information
which is necessary to figure out what's going wrong.

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NM doesn't scan after powering on radio

2009-12-16T17:25:35Z

On Wed, 2009-12-16 at 16:53 -0500, Matthew Saltzman wrote:
> I suspended, turned off the radio with the hardware switch, resumed.
> The applet showed wireless disabled. I suspended with the switch off,
> resumed (in a location different from my last connection, FWIW), and
> turned the switch off. The applet showed wireless enabled, but NM did
> not initiate a scan at that point. I restarted the NM service and all
> was well.

NM may well initiate a scan, but unfortunately there's no way for the
supplicant to report that the scan request failed (due to its internal
code structure), so NetworkManager doesn't know that it needs to request
another scan when the first one fails. It turns out that some drivers
(especially ath5k) like to deny scans quite a bit. We need more work in
this area, and we may be able to fix up the supplicant to provide "scan
failed" notifications that we can use but that'll take more work.

NM should, however, request another scan within 20 seconds or so. But
of course if that one fails for some reason, then the next request won't
be for 40 seconds after that.

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Testing

2009-12-16T17:23:23Z

On Wed, 2009-12-16 at 21:48 +0100, Tobias Pflug wrote:

> Hi,
>
> I see the nm sources have some test code here and there using some
> slightly customized ASSERT macro. I was wondering what people would
> think about adding more tests using something like cunit [1] or
> cutest [2] or check [3] ?
>
> I'd be interested in working on test cases as I think it could be a good
> way to get to know the code / API / ..
>
> any thoughts on this ? Dan ?

(Tobias poked me on IRC as well, so this reply is for the list mostly)

We should eventually use glib's test framework instead of the homegrown
stuff. That's possible in 0.8 because we require a glib version there
that has the unit test helpers, while 0.7.x can't make that assumption.
Any new tests should probably use the new glib stuff, and we can convert
the old tests over when there's time.

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IP4Config and routes

2009-12-16T17:22:00Z

On Wed, 2009-12-16 at 20:10 +0000, Daniel Drake wrote:

> On Wed, 2009-12-16 at 11:59 -0800, Dan Williams wrote:
> > Yes, it's correct in these cases because for shared, NM is handling the
> > network and there's no routing out of it since the network is NAT-ed to
> > the main connection. In link-local it's not relevant since the
> > link-local is by definition /not routable/...
>
> But just because there is no upstream router doesn't mean that access to
> the routing table should be excluded. The user may want to add a default
> route out on that interface. Or, in our case, we want to pass all
> multicast traffic to the interface.

The default route is controlled internally by NM; it should never be
part of the connection settings. Does your multicast routing need to be
different than the default route?

> > I'm more inclined to think that the bits aren't getting passed by to NM
> > correctly; are you sure you're passing the item with a dbus signature of
> > 'aau'? The code that actually unpacks the routes property is
> > nm_utils_ip4_routes_from_gvalue() in nm-utils.c. Trace into
> > nm-setting-ip4-config.c's set_property() call and see if the PROP_ROUTES
> > case is run.
>
> set_property() was never called but I figured it out: I have to use
> dbus.Array() in Python.

Yeah, you have to cast sometimes in Python if dbus-python can't figure
it out. The properties may need to be casted since it's not possible
for introspection to discover the expected dict property value types.

> I'm now using:
>
> ip4_config['routes'] = dbus.Array([(224,4,0,0)], signature='au')
>
> set_property() is now being called for routes, but the routing table is
> not being modified. I'll continue investigating tomorrow.

Ok, let me know.

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

NM doesn't scan after powering on radio

2009-12-16T13:53:52Z

I suspended, turned off the radio with the hardware switch, resumed.
The applet showed wireless disabled. I suspended with the switch off,
resumed (in a location different from my last connection, FWIW), and
turned the switch off. The applet showed wireless enabled, but NM did
not initiate a scan at that point. I restarted the NM service and all
was well.

--
Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Testing

2009-12-16T12:48:01Z

Hi,

I see the nm sources have some test code here and there using some
slightly customized ASSERT macro. I was wondering what people would
think about adding more tests using something like cunit [1] or
cutest [2] or check [3] ?

I'd be interested in working on test cases as I think it could be a good
way to get to know the code / API / ..

any thoughts on this ? Dan ?

best regards,
Tobias

[1] http://cunit.sourceforge.net/
[2] http://cutest.sourceforge.net/
[3] http://check.sourceforge.net/

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IP4Config and routes

2009-12-16T12:10:46Z

On Wed, 2009-12-16 at 11:59 -0800, Dan Williams wrote:
> Yes, it's correct in these cases because for shared, NM is handling the
> network and there's no routing out of it since the network is NAT-ed to
> the main connection. In link-local it's not relevant since the
> link-local is by definition /not routable/...

But just because there is no upstream router doesn't mean that access to
the routing table should be excluded. The user may want to add a default
route out on that interface. Or, in our case, we want to pass all
multicast traffic to the interface.

> I'm more inclined to think that the bits aren't getting passed by to NM
> correctly; are you sure you're passing the item with a dbus signature of
> 'aau'? The code that actually unpacks the routes property is
> nm_utils_ip4_routes_from_gvalue() in nm-utils.c. Trace into
> nm-setting-ip4-config.c's set_property() call and see if the PROP_ROUTES
> case is run.

set_property() was never called but I figured it out: I have to use
dbus.Array() in Python.

I'm now using:

ip4_config['routes'] = dbus.Array([(224,4,0,0)], signature='au')

set_property() is now being called for routes, but the routing table is
not being modified. I'll continue investigating tomorrow.

Thanks for your help, as always!
Daniel

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IP4Config and routes

2009-12-16T11:59:04Z

On Wed, 2009-12-16 at 18:23 +0000, Daniel Drake wrote:

> On Wed, 2009-12-16 at 17:53 +0000, Daniel Drake wrote:
> > Thanks! Very comprehensive.
> >
> > Is this part correct?
> >
> > "Routes cannot be used with the 'shared' or 'link-local' methods as
> > there is no upstream network."
> >
> > We're using link-local. Might explain my troubles, but in this case we
> > need a route even though we aren't dealing with an upstream network.
>
> Well, if it is correct, we aren't even hitting the bit of the code where
> it is enforced. (or at least I haven't spotted it)

Yes, it's correct in these cases because for shared, NM is handling the
network and there's no routing out of it since the network is NAT-ed to
the main connection. In link-local it's not relevant since the
link-local is by definition /not routable/...

> I have traced the code and I am finding :
>
> - nm_setting_new_from_hash() is being called
> - it is calling parse_one_setting()
> - which then calls nm_setting_new_from_hash()
> - the hash table has 2 properties inside(method,routes)
> - one_property_cb() is called on both those properties and is successful
> at adding them to the list
> - back in nm_setting_new_from_hash(), g_object_newv() is called with the
> property list (method and routes)
> - a NMSettingIP4Config is constructed, and these properties are set:
> 6(ignore auto routes), 7(ignore auto dns), 10(never default), 1(method)
>
> Why is set_property not called for the routes property?
> Is it because routes is a _nm_param_spec_specialized? (I'm not exactly
> sure what the difference is between this and the regular glib param
> specs)

I'm more inclined to think that the bits aren't getting passed by to NM
correctly; are you sure you're passing the item with a dbus signature of
'aau'? The code that actually unpacks the routes property is
nm_utils_ip4_routes_from_gvalue() in nm-utils.c. Trace into
nm-setting-ip4-config.c's set_property() call and see if the PROP_ROUTES
case is run.

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn

2009-12-16T11:53:55Z

On Wed, 2009-12-16 at 14:33 -0500, Matt Wilks wrote:

> > On Wed, 2009-12-16 at 12:43 PM, Dan Williams wrote:
> >> On Tue, 2009-12-15 at 11:08 -0500, Matt Wilks wrote:
> >> What prompted my initial query was the lack of support for<ca>,<cert>
> >> and<key> directives (supported in OpenVPN since 2.1-beta7, Nov
> >> 2005). They allow you to specify the key files directly in the
> >> configuration file, making it a self-contained configuration for a
> >> connection using keys to authenticate. NetworkManager also seemed to
> >> miss the fact that my config required both keys and a password; not
> >> hard to manually set but it wasn't caught by the import.
> >
> > I do believe those have been in the NM openvpn configuration for a
> > long time. What specific version of NM-openvpn are you using? I'm
> > certainly using a CA certificate right now to write this mail. If you
> > pick "Certificates (TLS)" or "Passwords with Certificates" from the
> > dropdown you should be able to use the certificates and keys of your
> > choice. This has been the case for at least a year and a half, since
> > before NM 0.7.x was released.
>
> Keys are supported, but you have to specify them in the NetworkManager
> config through a file browser dialog. The <ca>, etc directives I'm
> talking about go in the config file and you include the actual text of
> the key, something like:
>
> <ca>
> -----BEGIN CERTIFICATE-----
> asdlgkyladkhajf;lkawur;iolw789uafjdslkafjsd;fkj
> dflkajsdlfkaylkxcjfasmjelasjruklasfdjflkasdjrlk
> fasdlfka;wo347;afalk4nasdlfksaydlkaihf3a94rsldj
> -----END CERTIFICATE-----
> </ca>
>
> and so on with <cert> and <key>. I have NM (and NM-openvpn) version 0.8
> on Ubuntu Karmic and it didn't work for me.

Aha, yes that is not yet supported; it wouldn't be too hard to grab the
data out of there and stuff it into its own file in ~/.pki or such; you
don't really want to be storing certificate data in GConf or elsewhere.

In the end, we need a certificate store like Windows or Mac OS X has,
but for now we'll need to use files I guess.

One caveat is to ensure that the user's private key is written out in
encrypted form if it's not already encrypted in the config.

Dan

> > The whitelisting is for security. As a user, if you download a
> > configuration file and want to use it, what's to say it doesn't include
> > some options that make things less-secure or are malicious? Depending
> > on the plugin you could send a config option for "run this script after
> > connection" and since the VPN plugins currently run as root, that script
> > gets run as root. The configuration data cannot /necessarily/ be
> > trusted especially if it comes from the user session. At the same time,
> > you don't want to /necessarily/ lock users out completely (that's the
> > discretion of the sysadmin if there is one).
>
> Ah, this security concern settles it for me. The reason that other
> clients can offer the config file management paradigm is that you must
> have admin privileges to run the program in the first place. Not so
> with NM.
>
> Thanks again for your time. Much appreciated.
>

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn

2009-12-16T11:33:10Z

> On Wed, 2009-12-16 at 12:43 PM, Dan Williams wrote:
>> On Tue, 2009-12-15 at 11:08 -0500, Matt Wilks wrote:
>> What prompted my initial query was the lack of support for<ca>,<cert>
>> and<key> directives (supported in OpenVPN since 2.1-beta7, Nov
>> 2005). They allow you to specify the key files directly in the
>> configuration file, making it a self-contained configuration for a
>> connection using keys to authenticate. NetworkManager also seemed to
>> miss the fact that my config required both keys and a password; not
>> hard to manually set but it wasn't caught by the import.
>
> I do believe those have been in the NM openvpn configuration for a
> long time. What specific version of NM-openvpn are you using? I'm
> certainly using a CA certificate right now to write this mail. If you
> pick "Certificates (TLS)" or "Passwords with Certificates" from the
> dropdown you should be able to use the certificates and keys of your
> choice. This has been the case for at least a year and a half, since
> before NM 0.7.x was released.

Keys are supported, but you have to specify them in the NetworkManager
config through a file browser dialog. The <ca>, etc directives I'm
talking about go in the config file and you include the actual text of
the key, something like:

<ca>
-----BEGIN CERTIFICATE-----
asdlgkyladkhajf;lkawur;iolw789uafjdslkafjsd;fkj
dflkajsdlfkaylkxcjfasmjelasjruklasfdjflkasdjrlk
fasdlfka;wo347;afalk4nasdlfksaydlkaihf3a94rsldj
-----END CERTIFICATE-----
</ca>

and so on with <cert> and <key>. I have NM (and NM-openvpn) version 0.8
on Ubuntu Karmic and it didn't work for me.

> The whitelisting is for security. As a user, if you download a
> configuration file and want to use it, what's to say it doesn't include
> some options that make things less-secure or are malicious? Depending
> on the plugin you could send a config option for "run this script after
> connection" and since the VPN plugins currently run as root, that script
> gets run as root. The configuration data cannot /necessarily/ be
> trusted especially if it comes from the user session. At the same time,
> you don't want to /necessarily/ lock users out completely (that's the
> discretion of the sysadmin if there is one).

Ah, this security concern settles it for me. The reason that other
clients can offer the config file management paradigm is that you must
have admin privileges to run the program in the first place. Not so
with NM.

Thanks again for your time. Much appreciated.

--
Matt Wilks Colossians 2:6-7
University of Toronto Information Security, I+TS
(416) 978-3328 matt@...
4 Bancroft Ave., Rm. 102 Toronto, ON M5S 1C1
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IP4Config and routes

2009-12-16T10:23:42Z

On Wed, 2009-12-16 at 17:53 +0000, Daniel Drake wrote:
> Thanks! Very comprehensive.
>
> Is this part correct?
>
> "Routes cannot be used with the 'shared' or 'link-local' methods as
> there is no upstream network."
>
> We're using link-local. Might explain my troubles, but in this case we
> need a route even though we aren't dealing with an upstream network.

Well, if it is correct, we aren't even hitting the bit of the code where
it is enforced. (or at least I haven't spotted it)

I have traced the code and I am finding :

- nm_setting_new_from_hash() is being called
- it is calling parse_one_setting()
- which then calls nm_setting_new_from_hash()
- the hash table has 2 properties inside(method,routes)
- one_property_cb() is called on both those properties and is successful
at adding them to the list
- back in nm_setting_new_from_hash(), g_object_newv() is called with the
property list (method and routes)
- a NMSettingIP4Config is constructed, and these properties are set:
6(ignore auto routes), 7(ignore auto dns), 10(never default), 1(method)

Why is set_property not called for the routes property?
Is it because routes is a _nm_param_spec_specialized? (I'm not exactly
sure what the difference is between this and the regular glib param
specs)

Daniel

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Wrong SVN information on web site

2009-12-16T09:59:53Z

On Wed, 2009-12-16 at 15:47 +0100, Markus Becker wrote:
> Hi,
>
> I just noticed that on http://projects.gnome.org/NetworkManager/ talk is still
> that the source code is handled in SVN although it is git for some time now.
>
> "For information on obtaining the NetworkManager source code from GNOME SVN,
> read the developers page"

Fixed, thanks!

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: NetworkManager doesn't recover from system crash

2009-12-16T09:54:04Z

On Thu, 2009-12-10 at 03:36 -0200, José Queiroz wrote:

> Hi,
>
> A few minutes ago I had a crash in my notebook while it was asleep
> ("suspend to ram").
>
> After that, NM didn't came back, all managed network devices were deactivated.
>
> KDE-NM-applet were saying only "Network management is disabled". And,
> no matter how long I clicked over it, there were no clue on how to
> change that, I just couldn't re-enable it.
>
> After some digging, I found
> "/var/lib/NetworkManager/NetworkManager.state" this way:
>
> --------------------------------------------
>
> [main]
> NetworkingEnabled=false
> WirelessEnabled=true
> --------------------------------------------
>
> I edited the file, changing to "NetworkingEnabled=true", and restarted
> NM, and it magically started working again.
>
> Shouldn't KDE NM applet show me a way to re-enable NM? Is this an
> error in NM, or in KDE-NM-applet?

It's actually an artifact of how suspend/resume is currently being
handled, and how the "Enable networking" checkbox is currently being
handled. They both tell NM to 'sleep' and 'wake', so if the machine
crashes in suspend/hibernate then yeah, it looks like we'll get to this
point. We need to split these behaviors (user-initiated actions should
be saved, automatic ones should not) so that this doesn't happen.
Thanks for bringing this up.

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IP4Config and routes

2009-12-16T09:53:12Z

On Wed, 2009-12-16 at 09:49 -0800, Dan Williams wrote:
> http://live.gnome.org/NetworkManager
>
> which leads you to:
>
> http://projects.gnome.org/NetworkManager/developers/settings-spec-08.html
>

Thanks! Very comprehensive.

Is this part correct?

"Routes cannot be used with the 'shared' or 'link-local' methods as
there is no upstream network."

We're using link-local. Might explain my troubles, but in this case we
need a route even though we aren't dealing with an upstream network.

Daniel

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: getting started to hack nm ...

2009-12-16T09:51:47Z

On Sun, 2009-12-13 at 16:46 +0100, Tobias Pflug wrote:

> hi everyone
>
> I am currently looking for some open source project to invest
> some spare coding time into as my current job activities are starting to
> bore me to death..
>
> googling leads to http://projects.gnome.org/NetworkManager/developers/
> which lists the git repositories and gives some basic info. The link
> to the TODO list however is out of date. So my questions are ..
>
> 1. is there an up to date TODO list to get some ideas what I could
> look into ?
>
> 2. How do you usually go about working on nm .. do you run your builds
> inside a virtual machine or fake root or something like that in order
> to not collide with your desktop which most likely runs nm as well..?
>
> 3. any other suggestions/hints/warnings/.. ? :)
>
> thanks a lot in advance.

Lest people think I'm a horrible person, replied offlist with a few
suggestions whiel the mail was in the moderation queue this weekend.
The top suggestion was implementing connection time and byte tracking to
enable mobile broadband connection limits and such. Obviously there's
more :)

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IP4Config and routes

2009-12-16T09:49:50Z

On Wed, 2009-12-16 at 12:40 +0000, Daniel Drake wrote:

> Hi,
>
> Ad-hoc networking is broken in Sugar because no route is created for
> multicast packets - this means the collaboration features do not work.
>
> I can see that I can specify routes in the IP4Config object (hence we
> could modify Sugar to fix this) but the only documentation I can find
> is:
>
> Routes - aau - (read)
> Tuples of IPv4 route/prefix/next-hop/metric.

http://live.gnome.org/NetworkManager

which leads you to:

http://projects.gnome.org/NetworkManager/developers/settings-spec-08.html

"Array of IPv4 route structures. Each IPv4 route structure is composed
of 4 32-bit values; the first being the destination IPv4 network or
address (network byte order), the second the destination network or
address prefix (1 - 32), the third being the next-hop (network byte
order) if any, and the fourth being the route metric. For the 'auto'
method, given IP routes are appended to those returned by automatic
configuration. Routes cannot be used with the 'shared' or 'link-local'
methods as there is no upstream network."

If I need to expand on that, please let me know and I'll update the
docs.

> I'm not too knowledgeable about routing tables and the language I speak
> is the one that "route -n" returns, basically I want a route of:
> destination=224.0.0.0
> gateway=0.0.0.0
> genmask=240.0.0.0
> flags=U
> metric=0
>
> I guess next-hop is gateway, and metric is metric, but I'm a bit stuck
> on "route" and "prefix"

route == destination
prefix = "Genmask" from /sbin/route but as a CIDR prefix, not a subnet
mask

> Can anyone help me convert those values into ones that NM understands,
> or point me at some existing code which uses this functionality?

Lot of the internal NM code does this; internally NM uses

GSList *nm_utils_ip4_routes_from_gvalue (const GValue *value);
void nm_utils_ip4_routes_to_gvalue (GSList *list, GValue *value);

to get translate the 'routes' key into something it can use.

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn

2009-12-16T09:43:19Z

On Tue, 2009-12-15 at 11:08 -0500, Matt Wilks wrote:

> On 09-12-14 06:09 PM, Dan Williams wrote:
> > On Mon, 2009-12-14 at 09:24 -0500, Matt Wilks wrote:
> >> This must have been discussed before on this list, but I'm curious the
> >> reasoning behind making network-manager-openvpn have its own GUI for
> >> configuration in the first place. Why not offer functionality similar
> >> to the Windows/Mac clients that simply manage your connections via
> >> configuration files? You'd get all the flexibility of OpenVPN with none
> >> of the overhead of constantly having to write patches to support /
> >> debate the inclusion of individual options.
> >
> > For a number of reasons;
>
> Thanks for your response Dan, I appreciate you taking the time to do so.
> Allow me to make a few comments.
>
> > 1) not everyone wants to use configuration files,
> > 2) not everyone is aware of (or cares about) the intricacies of
> > configuration options, some cannot be used with others, some require
> > others to be turned on,
>
> Granted. However, I would think that anyone who is attempting to
> connect to a work/school VPN is more likely to have a configuration file
> handed to them then a set of OpenVPN parameters. That is how we do it
> with the VPN I am responsible for.

Again, the config file can be imported into NM, so the process you have
still works exactly the same way.

> > 3) GUI interfaces are often more approachable and do not preclude
> > advanced users from using config files anyway, and
>
> I think you are making an incorrect distinction here between advanced
> and beginner users. Using a config file does not necessarily mean that
> a user is advanced. In our case, we distribute a config file precisely
> because so many of our users are not advanced and we don't want them
> having to fiddle around with options on various clients.
>
> > 4) handling random config files is often problematic,
>
> I'm not sure I understand why. Using the model of OpenVPN-GUI or
> Tunnelblick (Windows and Mac GUIs respectively) however, you would just
> have NetworkManager monitor a directory for config files. Could be a
> directory in the user's home (ala Tunnelblick) or a system directory
> (ala OpenVPN-GUI). Even if the user were able to specify arbitrary
> configuration file locations, how is this any more problematic then the
> dialogs to specify the ca, key and user cert that currently exist in the
> NetworkManager GUI?

1) The config file is stored separately from the rest of the
configuration data like IP address, routing information, DNS, etc. If
it's not available (user downloads it into ~/Downloads and then it gets
deleted when FF quits) then it's no longer available

2) root daemons accessing files in users' directories is often not
allowed by security software like SELinux or AppArmor, for good reason;
it's really hard to contain a binary and limit the attack points when
you have to allow the binary to read from all over the hard drive

3) it's a security risk on daemons that require a password in the config
file when not using stdin (ex vpnc)

4) using a config file can create temporary files that require cleanup
which doesn't always get done; if we do need to substitute certain
values (like we do with dhclient) then we need to create a temporary
config file that has to be cleaned up after the transaction is complete,
which is more housekeeping and more trouble.

> > 5) it wasnt' integrated into the consistent NetworkManager
> > configuration system.
>
> I have to admit ignorance about the standards for configuring
> NetworkManager, but I imagine that they say something about storing
> configuration internally rather than referencing external files?

http://live.gnome.org/NetworkManagerConfiguration

The NM configuration system actually produces an abstraction over
various distro and desktop-specific configuration systems so taht you
can use your preferred configuration system. For example, GConf,
KConfig, /etc/network/interfaces, keyfiles, ifcfg files, etc, all are
transformed into a standard format that clients can read and handle.
That allows you, from a client, to actually figure out what's going on
in a standard way instead of having to code logic for each and every
configuration system.

NM doesn't store config /internally/, but the user-settings and
system-settings services do use configuration systems like GConf or
system config files that you might consider to store the config
"internally", at least in a different format than the native config file
for openvpn. That has some benefits; as the admin you can use tools,
behaviors, processes, and knowledge that you already have for your
distro's native configuration file format. You can lock configuration
down using GConf or keep your scripts for fixing up /e/n/i or ifcfg
files. That sort of thing. If it's just a random config file from a
random daemon, you need to start creating custom rules for a lot of the
stuff that you might want to do while administering systems.

> > Now that we have good import/export capability for openvpn, it's not
> > actually that hard to use your own configs. If there's options that
> > people use, we can also whitelist them and add them to import/export
> > even if they aren't shown in the GUI.
>
> What prompted my initial query was the lack of support for <ca>, <cert>
> and <key> directives (supported in OpenVPN since 2.1-beta7, Nov 2005).
> They allow you to specify the key files directly in the configuration
> file, making it a self-contained configuration for a connection using
> keys to authenticate. NetworkManager also seemed to miss the fact that
> my config required both keys and a password; not hard to manually set
> but it wasn't caught by the import.

I do believe those have been in the NM openvpn configuration for a long
time. What specific version of NM-openvpn are you using? I'm certainly
using a CA certificate right now to write this mail. If you pick
"Certificates (TLS)" or "Passwords with Certificates" from the dropdown
you should be able to use the certificates and keys of your choice.
This has been the case for at least a year and a half, since before NM
0.7.x was released.

> > Just because there's a GUI doesn't preclude you from writing a config
> > file and importing it of course.
>
> That's true, and apart from the missing config I mentioned above, I
> found it to be a relatively painless process. Kudos! However I don't
> see how this benefits the NetworkManager developers. Writing a plugin
> that used external config files would be a one-time job. As it stands
> now, each new option must be whitelisted and incorporated into the
> plugin.

The whitelisting is for security. As a user, if you download a
configuration file and want to use it, what's to say it doesn't include
some options that make things less-secure or are malicious? Depending
on the plugin you could send a config option for "run this script after
connection" and since the VPN plugins currently run as root, that script
gets run as root. The configuration data cannot /necessarily/ be
trusted especially if it comes from the user session. At the same time,
you don't want to /necessarily/ lock users out completely (that's the
discretion of the sysadmin if there is one).

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Wrong SVN information on web site

2009-12-16T06:47:54Z

Hi,

I just noticed that on http://projects.gnome.org/NetworkManager/ talk is still
that the source code is handled in SVN although it is git for some time now.

"For information on obtaining the NetworkManager source code from GNOME SVN,
read the developers page"

BR,
Markus
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: IP4Config and routes

2009-12-16T05:14:16Z

On Wed, 2009-12-16 at 12:40 +0000, Daniel Drake wrote:
> Hi,
>
> Ad-hoc networking is broken in Sugar because no route is created for
> multicast packets - this means the collaboration features do not work.
>
> I can see that I can specify routes in the IP4Config object

I started guessing at some numbers and actually, I can't seem to get
this working at all.

With my latest guess, here is the object being returned by
NMSettingsConnection.GetSettings() on the user settings service:

{'802-11-wireless': {'band': 'bg', 'ssid': dbus.ByteArray("asfdsfg's
network"), 'mode': 'adhoc'}, 'connection': {'autoconnect': False,
'type': '802-11-wireless', 'id': "Auto asfdsfg's network", 'uuid':
'28cbb90800f37c775511a1eab45a834b53cb32a1'}, 'ipv4': {'routes': [[224,
4, 0, 0]], 'method': 'link-local'}}

There is no resulting entry in the routing table (checked by running
'route -n')

Even if I use an invalid value (such as a string) for routes, NM doesn't
complain, as if it is ignoring my routes key altogether. Am I missing
something obvious?

Thanks,
Daniel

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

IP4Config and routes

2009-12-16T04:40:14Z

Hi,

Ad-hoc networking is broken in Sugar because no route is created for
multicast packets - this means the collaboration features do not work.

I can see that I can specify routes in the IP4Config object (hence we
could modify Sugar to fix this) but the only documentation I can find
is:

Routes - aau - (read)
Tuples of IPv4 route/prefix/next-hop/metric.

I'm not too knowledgeable about routing tables and the language I speak
is the one that "route -n" returns, basically I want a route of:
destination=224.0.0.0
gateway=0.0.0.0
genmask=240.0.0.0
flags=U
metric=0

I guess next-hop is gateway, and metric is metric, but I'm a bit stuck
on "route" and "prefix"

Can anyone help me convert those values into ones that NM understands,
or point me at some existing code which uses this functionality?

Thanks,
Daniel

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn

2009-12-15T08:08:28Z

On 09-12-14 06:09 PM, Dan Williams wrote:

> On Mon, 2009-12-14 at 09:24 -0500, Matt Wilks wrote:
>> This must have been discussed before on this list, but I'm curious the
>> reasoning behind making network-manager-openvpn have its own GUI for
>> configuration in the first place. Why not offer functionality similar
>> to the Windows/Mac clients that simply manage your connections via
>> configuration files? You'd get all the flexibility of OpenVPN with none
>> of the overhead of constantly having to write patches to support /
>> debate the inclusion of individual options.
>
> For a number of reasons;

Thanks for your response Dan, I appreciate you taking the time to do so.
Allow me to make a few comments.

> 1) not everyone wants to use configuration files,
> 2) not everyone is aware of (or cares about) the intricacies of
> configuration options, some cannot be used with others, some require
> others to be turned on,

Granted. However, I would think that anyone who is attempting to
connect to a work/school VPN is more likely to have a configuration file
handed to them then a set of OpenVPN parameters. That is how we do it
with the VPN I am responsible for.

> 3) GUI interfaces are often more approachable and do not preclude
> advanced users from using config files anyway, and

I think you are making an incorrect distinction here between advanced
and beginner users. Using a config file does not necessarily mean that
a user is advanced. In our case, we distribute a config file precisely
because so many of our users are not advanced and we don't want them
having to fiddle around with options on various clients.

> 4) handling random config files is often problematic,

I'm not sure I understand why. Using the model of OpenVPN-GUI or
Tunnelblick (Windows and Mac GUIs respectively) however, you would just
have NetworkManager monitor a directory for config files. Could be a
directory in the user's home (ala Tunnelblick) or a system directory
(ala OpenVPN-GUI). Even if the user were able to specify arbitrary
configuration file locations, how is this any more problematic then the
dialogs to specify the ca, key and user cert that currently exist in the
NetworkManager GUI?

> 5) it wasnt' integrated into the consistent NetworkManager
> configuration system.

I have to admit ignorance about the standards for configuring
NetworkManager, but I imagine that they say something about storing
configuration internally rather than referencing external files?

> Now that we have good import/export capability for openvpn, it's not
> actually that hard to use your own configs. If there's options that
> people use, we can also whitelist them and add them to import/export
> even if they aren't shown in the GUI.

What prompted my initial query was the lack of support for <ca>, <cert>
and <key> directives (supported in OpenVPN since 2.1-beta7, Nov 2005).
They allow you to specify the key files directly in the configuration
file, making it a self-contained configuration for a connection using
keys to authenticate. NetworkManager also seemed to miss the fact that
my config required both keys and a password; not hard to manually set
but it wasn't caught by the import.

> Just because there's a GUI doesn't preclude you from writing a config
> file and importing it of course.

That's true, and apart from the missing config I mentioned above, I
found it to be a relatively painless process. Kudos! However I don't
see how this benefits the NetworkManager developers. Writing a plugin
that used external config files would be a one-time job. As it stands
now, each new option must be whitelisted and incorporated into the
plugin.

Again, thanks for taking the time to respond. Much appreciated.

--
Matt Wilks Colossians 2:6-7
University of Toronto Information Security, I+TS
(416) 978-3328 matt@...
4 Bancroft Ave., Rm. 102 Toronto, ON M5S 1C1
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Problem with Toshiba L300 wireless interface

2009-12-15T00:16:03Z

On Sat, Dec 12, 2009 at 11:36 PM, john <john@...> wrote:

This may not be the appropriate list but ...

I have a Toshiba L300 (bought in NZ) and the wireless has never worked
under OpenSUSE 11.0.
After googling about the problem, I followed the advice of one site and
installed madwifi modules using Yast2 from the madwifi OpenSUSE 11.0
repository, and I blacklisted the ath5k module.

dmesg reveals:
ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)

PCI: Setting latency timer of device 0000:03:00.0 to 64
wifi%d: unable to attach hardware: 'Hardware revision not supported'
(HAL status 13)

HAL is the binary blob where all the action happens. The ath5k project was created to make a driver with no closed source guts. Sadly, the madwifi/ath5k is in a transition. in the long run this will be better for the community as a whole. Reporting bugs is helpful.

If all else fails grab an Intel 3945ABG for 10 bucks on ebay(make sure your slots pci express). IMO some of Atheros chips are in limbo right now from the transition from madwifi to ath5k. I love what Atheros is doing by opening their drivers and feel in the long run they will be the best chips, but I wasted a year messing with my ath5k to madwifi switch where one kernel it would work then it would break.

DISCLAIMER only change hardware if you know what you are doing. With that said just remove the old one and snap on antennas.

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn

2009-12-14T15:09:58Z

On Mon, 2009-12-14 at 09:24 -0500, Matt Wilks wrote:

> >> Read slowly, im not talking about routes here, talking about all the
> >> openvpn parameters that are not yet configurable/importable with the
> >> current graphical interface. They could just be configured through or
> >> imported into a single listbox as described above.
> >
> > But that's *horrible* UI and not something I'd like to condone. I'd
> > rather add the options on an as-needed basis to ensure we don't just
> > dump everything in, and find out that we overloaded the UI with 50
> > options that almost nobody uses. Which I suspect is true for at least
> > half of openvpn's options, because they did absolutely no work in
> > consolidating them and asking the people who requested the options
> > what they were actually trying to accomplish to constrain the number
> > of switches that openvpn supports. I'm interested in making it work
> > for 90 - 95% of use-cases, but I don't think we should be designing
> > for that last 5%, especially when it makes things nearly unusable for
> > the other 90.
>
> This must have been discussed before on this list, but I'm curious the
> reasoning behind making network-manager-openvpn have its own GUI for
> configuration in the first place. Why not offer functionality similar
> to the Windows/Mac clients that simply manage your connections via
> configuration files? You'd get all the flexibility of OpenVPN with none
> of the overhead of constantly having to write patches to support /
> debate the inclusion of individual options.

For a number of reasons; 1) not everyone wants to use configuration
files, 2) not everyone is aware of (or cares about) the intricacies of
configuration options, some cannot be used with others, some require
others to be turned on, 3) GUI interfaces are often more approachable
and do not preclude advanced users from using config files anyway, and
4) handling random config files is often problematic, and 5) it wasnt'
integrated into the consistent NetworkManager configuration system.

Now that we have good import/export capability for openvpn, it's not
actually that hard to use your own configs. If there's options that
people use, we can also whitelist them and add them to import/export
even if they aren't shown in the GUI.

Just because there's a GUI doesn't preclude you from writing a config
file and importing it of course.

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Internet Connection Sharing

2009-12-14T15:06:49Z

On Mon, 2009-12-14 at 09:30 -0500, Chuck Anderson wrote:

> On Fri, Dec 11, 2009 at 01:34:06PM +0000, Martin Owens wrote:
> > Hello Chuck,
> >
> > On Fri, 2009-12-11 at 01:01 -0500, Chuck Anderson wrote:
> >
> > > I sometimes find myself in scenarios where I have a wireless
> > > connection to the internet that I'd like to share with wired-only
> > > devices (no wifi cards in them). How hard would it be to make the
> > > "Create new wireless network..." dialog generic like "Share network
> > > connection..."? Basically, I would like to be able to share any
> > > active internet connection to any other medium, wired or wireless or
> > > whatever.
> >
> > Would this help you?
> >
> > http://doctormo.wordpress.com/2009/12/06/ubuntus-internet-connection-sharing/
>
> Yes, thank you. Why wasn't this feature touted and advertized as much
> as Wireless network sharing was? I think the disparity between wired
> sharing and "Create new wireless network..." should be addressed.

Partially because the user interface to make it easier to set up isn't
there. But it was on the list of bullet points for 0.7 in most of the
stuff I wrote about in release notes or blogs, as far as I remember.

Dan

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Problem with Toshiba L300 wireless interface

2009-12-14T15:05:55Z

On Sun, 2009-12-13 at 17:36 +1300, john wrote:
> This may not be the appropriate list but ...
>
> I have a Toshiba L300 (bought in NZ) and the wireless has never worked
> under OpenSUSE 11.0.
> After googling about the problem, I followed the advice of one site and
> installed madwifi modules using Yast2 from the madwifi OpenSUSE 11.0
> repository, and I blacklisted the ath5k module.

As others have mentioned, try latest OpenSUSE. Also, I'd
recommend /against/ using madwifi; the in-kernel drivers are much more
actively maintained than madwifi is; Atheros engineers do much of that
and the company is actively involved in the Linux kernel drivers.
madwifi is actually an out-dated dead-end at this point.

Let us know how the upgrade goes.

dan

> dmesg reveals:
> ath_hal: module license 'Proprietary' taints kernel.
> ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)
>
> PCI: Setting latency timer of device 0000:03:00.0 to 64
> wifi%d: unable to attach hardware: 'Hardware revision not supported'
> (HAL status 13)
>
> ACPI: PCI interrupt for device 0000:03:00.0 disabled
>
> Comments:
> 1. lspci reveals that the wireless chipset is Atheros AR242x (not the
> AR5210 etc expected).
> It is located at 03:00.0 and the numeric stamp for the AR242x is
> 168c:001c
> 2. The device (wifi0, or ath0, or wlan0) never gets created.
> 3. Might ACPI be contributing to the problem?
> 4. Is the AR242x designation a maverick?
>
> Can anyone shine light on this?
>
> John O'Gorman
>
> _______________________________________________
> NetworkManager-list mailing list
> NetworkManager-list@...
> http://mail.gnome.org/mailman/listinfo/networkmanager-list

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Internet Connection Sharing

2009-12-14T06:30:27Z

On Fri, Dec 11, 2009 at 01:34:06PM +0000, Martin Owens wrote:

> Hello Chuck,
>
> On Fri, 2009-12-11 at 01:01 -0500, Chuck Anderson wrote:
>
> > I sometimes find myself in scenarios where I have a wireless
> > connection to the internet that I'd like to share with wired-only
> > devices (no wifi cards in them). How hard would it be to make the
> > "Create new wireless network..." dialog generic like "Share network
> > connection..."? Basically, I would like to be able to share any
> > active internet connection to any other medium, wired or wireless or
> > whatever.
>
> Would this help you?
>
> http://doctormo.wordpress.com/2009/12/06/ubuntus-internet-connection-sharing/

Yes, thank you. Why wasn't this feature touted and advertized as much
as Wireless network sharing was? I think the disparity between wired
sharing and "Create new wireless network..." should be addressed.
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: network-manager-openvpn

2009-12-14T06:24:30Z

>> Read slowly, im not talking about routes here, talking about all the
>> openvpn parameters that are not yet configurable/importable with the
>> current graphical interface. They could just be configured through or
>> imported into a single listbox as described above.
>
> But that's *horrible* UI and not something I'd like to condone. I'd
> rather add the options on an as-needed basis to ensure we don't just
> dump everything in, and find out that we overloaded the UI with 50
> options that almost nobody uses. Which I suspect is true for at least
> half of openvpn's options, because they did absolutely no work in
> consolidating them and asking the people who requested the options
> what they were actually trying to accomplish to constrain the number
> of switches that openvpn supports. I'm interested in making it work
> for 90 - 95% of use-cases, but I don't think we should be designing
> for that last 5%, especially when it makes things nearly unusable for
> the other 90.

This must have been discussed before on this list, but I'm curious the
reasoning behind making network-manager-openvpn have its own GUI for
configuration in the first place. Why not offer functionality similar
to the Windows/Mac clients that simply manage your connections via
configuration files? You'd get all the flexibility of OpenVPN with none
of the overhead of constantly having to write patches to support /
debate the inclusion of individual options.

Matt
_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

getting started to hack nm ...

2009-12-13T07:46:50Z

hi everyone

I am currently looking for some open source project to invest
some spare coding time into as my current job activities are starting to
bore me to death..

googling leads to http://projects.gnome.org/NetworkManager/developers/
which lists the git repositories and gives some basic info. The link
to the TODO list however is out of date. So my questions are ..

1. is there an up to date TODO list to get some ideas what I could
look into ?

2. How do you usually go about working on nm .. do you run your builds
inside a virtual machine or fake root or something like that in order
to not collide with your desktop which most likely runs nm as well..?

3. any other suggestions/hints/warnings/.. ? :)

thanks a lot in advance.

best regards,
Tobias

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Re: Problem with Toshiba L300 wireless interface

2009-12-13T07:00:20Z

On Sun, 13 Dec 2009 17:36:16 +1300
john <john@...> wrote:
> I have a Toshiba L300 (bought in NZ) and the wireless has never worked
> under OpenSUSE 11.0.

I recommend to upgrade to 11.2 .

> 1. lspci reveals that the wireless chipset is Atheros AR242x (not the
> AR5210 etc expected).
> It is located at 03:00.0 and the numeric stamp for the AR242x is
> 168c:001c
> 2. The device (wifi0, or ath0, or wlan0) never gets created.
> 3. Might ACPI be contributing to the problem?
> 4. Is the AR242x designation a maverick?

No. this is OK [1]
168c 001c AR242x 802.11abg NIC (PCI Express)
[1] http://pci-ids.ucw.cz/read/PC/168c/001c

> Can anyone shine light on this?

If the problem persists after upgrading to 11.2 would it be
possible to report bug on bugzilla.novell.com ?

Cheers,
--
-vlado
Vladimir Botka

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list

Problem with Toshiba L300 wireless interface

2009-12-12T20:36:16Z

This may not be the appropriate list but ...

I have a Toshiba L300 (bought in NZ) and the wireless has never worked
under OpenSUSE 11.0.
After googling about the problem, I followed the advice of one site and
installed madwifi modules using Yast2 from the madwifi OpenSUSE 11.0
repository, and I blacklisted the ath5k module.

dmesg reveals:
ath_hal: module license 'Proprietary' taints kernel.
ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413)

PCI: Setting latency timer of device 0000:03:00.0 to 64
wifi%d: unable to attach hardware: 'Hardware revision not supported'
(HAL status 13)

ACPI: PCI interrupt for device 0000:03:00.0 disabled

Comments:
1. lspci reveals that the wireless chipset is Atheros AR242x (not the
AR5210 etc expected).
It is located at 03:00.0 and the numeric stamp for the AR242x is
168c:001c
2. The device (wifi0, or ath0, or wlan0) never gets created.
3. Might ACPI be contributing to the problem?
4. Is the AR242x designation a maverick?

Can anyone shine light on this?

John O'Gorman

_______________________________________________
NetworkManager-list mailing list
NetworkManager-list@...
http://mail.gnome.org/mailman/listinfo/networkmanager-list