Re: WPA status 2006-01-08

2006-01-10 Thread Robert Love
On Mon, 2006-01-09 at 20:04 -0500, Dan Williams wrote:

 But unfortunately we do have some regressions right now, and we've got
 to look at how to fix those.  If we do go driver-specific in
 NetworkManager, then there really will be a Flag Day where we turn off
 that support and force drivers to be WEXT compliant.  If distros don't
 like that, they can either fix the drivers or patch NM (Fedora
 included).  I'd like that day to be as soon as realistically possible.

I am for considering driver-specific support, but I agree 100% we want
to move toward a pure WEXT-based solution, sooner rather than later.

I guess we should see what we fix by going driver-specific with
wpa_supplicant.  How easy is the changeover?

Robert Love


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


Re: WPA status 2006-01-08

2006-01-10 Thread Dan Williams
On Tue, 2006-01-10 at 11:52 -0500, Robert Love wrote:
 On Mon, 2006-01-09 at 20:04 -0500, Dan Williams wrote:
 
  But unfortunately we do have some regressions right now, and we've got
  to look at how to fix those.  If we do go driver-specific in
  NetworkManager, then there really will be a Flag Day where we turn off
  that support and force drivers to be WEXT compliant.  If distros don't
  like that, they can either fix the drivers or patch NM (Fedora
  included).  I'd like that day to be as soon as realistically possible.
 
 I am for considering driver-specific support, but I agree 100% we want
 to move toward a pure WEXT-based solution, sooner rather than later.
 
 I guess we should see what we fix by going driver-specific with
 wpa_supplicant.  How easy is the changeover?

We find drivers that need special-casing, and change the arguments to
wpa_supplicant.  Essentially, we should default to wext, grab
nm_device_get_driver(), and if it needs special-casing, convert that to
the wpa_supplicant driver name.

Dan

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


Re: WPA status 2006-01-08

2006-01-09 Thread Nikolaus Filus
Hi,


On Sunday 08 January 2006 22:48, Dan Williams wrote:
 *) Your driver probably doesn't support WPA quite enough; you'll need a
 driver that does WEXT-18 or higher.  This means that it needs to set
 the enc_capa bits on return from the SIOCGIWRANGE call, which only
 hostap seems to do right now.

 The attached patch works for ipw2100, but only because it can already
 do WPA.  It was simply not telling NM that it could.  Other drivers may
 need substantial changes to work with WEXT-18's enhanced encryption
 API. Drivers that _may_ work with few changes: ipw2100, ipw2200, atmel,
 prism54.  Drivers that need lots of fixup: orinoco, airo, bcm43xx.


as a ipw2200 user may I forward this to ipw-devel list, or are you working 
somehow together with intel (or other) driver guys?!

Thanks for your excellent work.



Nikolaus

-- 
out of signatures
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: WPA status 2006-01-08

2006-01-09 Thread Dan Williams
On Mon, 2006-01-09 at 10:58 +0100, Nikolaus Filus wrote:
 Hi,
 
 
 On Sunday 08 January 2006 22:48, Dan Williams wrote:
  *) Your driver probably doesn't support WPA quite enough; you'll need a
  driver that does WEXT-18 or higher.  This means that it needs to set
  the enc_capa bits on return from the SIOCGIWRANGE call, which only
  hostap seems to do right now.
 
  The attached patch works for ipw2100, but only because it can already
  do WPA.  It was simply not telling NM that it could.  Other drivers may
  need substantial changes to work with WEXT-18's enhanced encryption
  API. Drivers that _may_ work with few changes: ipw2100, ipw2200, atmel,
  prism54.  Drivers that need lots of fixup: orinoco, airo, bcm43xx.
 
 
 as a ipw2200 user may I forward this to ipw-devel list, or are you working 
 somehow together with intel (or other) driver guys?!

I'll forward the patch to both ipw and kernel (netdev) devel lists.

Dan

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


Re: WPA status 2006-01-08

2006-01-09 Thread Dan Williams
On Mon, 2006-01-09 at 10:55 -0500, Robert Love wrote:
 On Sun, 2006-01-08 at 16:48 -0500, Dan Williams wrote:
 
  *) Your driver probably doesn't support WPA quite enough; you'll need a
  driver that does WEXT-18 or higher.  This means that it needs to set the
  enc_capa bits on return from the SIOCGIWRANGE call, which only hostap
  seems to do right now.
 
 So ... should we need these updates to use WPA, or for the driver to
 work at all?

Just to use WPA.  All cards should support WEP already since you don't
need fancy calls to do that...  Unless wpa_supplicant is trying to be
clever.

In the case of ipw2100, NM checks the range-enc_capa field for WPA
support bits, but WEP isn't determined from there.  If there are
problems with wpa_supplicant and WEP, then we definitely need to chase
those down.

Dan

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


Re: WPA status 2006-01-08

2006-01-09 Thread Robert Love
On Mon, 2006-01-09 at 11:11 -0500, Dan Williams wrote:

 Just to use WPA.  All cards should support WEP already since you don't
 need fancy calls to do that...  Unless wpa_supplicant is trying to be
 clever.

Seems to be.  SIOCSIWAUTH not being supported shuts the whole process
down.  This is an Atheros.

Robert Love


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


Re: WPA status 2006-01-08

2006-01-09 Thread Robert Love
On Mon, 2006-01-09 at 11:16 -0500, Robert Love wrote:

 Seems to be.  SIOCSIWAUTH not being supported shuts the whole process
 down.  This is an Atheros.

Alright, got it working.  Nice!

I still see a boatload of SIOCSIWAUTH Operation not supported errors.
But, whatever.

Is 0.4.7 + your patch sufficient for WPA?  Or do we need something even
newer?

Robert Love


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


Re: WPA status 2006-01-08

2006-01-09 Thread Dan Williams
On Mon, 2006-01-09 at 11:31 -0500, Robert Love wrote:
 On Mon, 2006-01-09 at 11:16 -0500, Robert Love wrote:
 
  Seems to be.  SIOCSIWAUTH not being supported shuts the whole process
  down.  This is an Atheros.
 
 Alright, got it working.  Nice!
 
 I still see a boatload of SIOCSIWAUTH Operation not supported errors.
 But, whatever.
 
 Is 0.4.7 + your patch sufficient for WPA?  Or do we need something even
 newer?

I think 0.4.7 is OK, I'm using HEAD but looking at the changelog there's
not much that should affect functionality since before Christmas at
least.  I think at the very least we should make sure 0.4.7 works
correctly for us, and patch it if we need to.

Dan

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


Re: WPA status 2006-01-08

2006-01-09 Thread Robert Love
On Mon, 2006-01-09 at 11:46 -0500, Dan Williams wrote:

 I think 0.4.7 is OK, I'm using HEAD but looking at the changelog there's
 not much that should affect functionality since before Christmas at
 least.  I think at the very least we should make sure 0.4.7 works
 correctly for us, and patch it if we need to.

wpa_supplicant 0.4.7 + your patch works fine for non-WPA.  I'll try WPA
in a bit -- not sure if it will work out-of-the-box with madwifi-ng.

Have you / will you submit your patch upstream to wpa_supplicant?

Robert Love


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


Re: WPA status 2006-01-08

2006-01-09 Thread Dan Williams
On Mon, 2006-01-09 at 12:02 -0500, Robert Love wrote:
 On Mon, 2006-01-09 at 11:46 -0500, Dan Williams wrote:
 
  I think 0.4.7 is OK, I'm using HEAD but looking at the changelog there's
  not much that should affect functionality since before Christmas at
  least.  I think at the very least we should make sure 0.4.7 works
  correctly for us, and patch it if we need to.
 
 wpa_supplicant 0.4.7 + your patch works fine for non-WPA.  I'll try WPA
 in a bit -- not sure if it will work out-of-the-box with madwifi-ng.
 
 Have you / will you submit your patch upstream to wpa_supplicant?

Sent the patch to Jouni and [EMAIL PROTECTED] last night.

dan

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


Re: WPA status 2006-01-08

2006-01-09 Thread Dan Williams
On Mon, 2006-01-09 at 10:55 -0500, Robert Love wrote:
 On Sun, 2006-01-08 at 16:48 -0500, Dan Williams wrote:
 
  *) Your driver probably doesn't support WPA quite enough; you'll need a
  driver that does WEXT-18 or higher.  This means that it needs to set the
  enc_capa bits on return from the SIOCGIWRANGE call, which only hostap
  seems to do right now.
 
 So ... should we need these updates to use WPA, or for the driver to
 work at all?
 
 I get errors about SIOCSIWAUTH not supported.

Note that while wpa_supplicant supports using driver-specific methods
for WPA and other settings, we want to push all drivers towards
conforming to the WEXT spec on this one.  That means support for
SIOCSIWAUTH and SIOCSIWENCODEEXT.  We _may_ have to allow
driver-specific support in the mean time, but I'd rather not do that if
at all possible.  (for instance, atmel doesn't seem to work right now
for normal WEP)

Dan


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


Re: WPA status 2006-01-08

2006-01-09 Thread Robert Love
On Mon, 2006-01-09 at 12:18 -0500, Dan Williams wrote:

 Note that while wpa_supplicant supports using driver-specific methods
 for WPA and other settings, we want to push all drivers towards
 conforming to the WEXT spec on this one.  That means support for
 SIOCSIWAUTH and SIOCSIWENCODEEXT.  We _may_ have to allow
 driver-specific support in the mean time, but I'd rather not do that if
 at all possible.  (for instance, atmel doesn't seem to work right now
 for normal WEP)

We are going to need to go through the various drivers and see how they
fair.  We are probably going to neeed driver-specific support.

Robert Love


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


Re: WPA status 2006-01-08

2006-01-09 Thread Dan Williams
On Mon, 2006-01-09 at 12:27 -0500, Robert Love wrote:
 On Mon, 2006-01-09 at 12:18 -0500, Dan Williams wrote:
 
  Note that while wpa_supplicant supports using driver-specific methods
  for WPA and other settings, we want to push all drivers towards
  conforming to the WEXT spec on this one.  That means support for
  SIOCSIWAUTH and SIOCSIWENCODEEXT.  We _may_ have to allow
  driver-specific support in the mean time, but I'd rather not do that if
  at all possible.  (for instance, atmel doesn't seem to work right now
  for normal WEP)
 
 We are going to need to go through the various drivers and see how they
 fair.  We are probably going to neeed driver-specific support.

Even if that's the case, we're going to need to push those drivers
towards WEXT compliance, such that they do what they need to do with the
wpa_supplicant wext driver.  I'm much more amenable to making sure
they all work with WEP  wpa_supplicant first, and taking more time with
WPA.

For example, the atmel driver for wpa_supplicant doesn't work on the
in-kernel atmel driver _at__all_, probably because it expects
atmelwlandriver.sf.net rather than the in-kernel one.  I'm looking at
fixing that up for WEP-only at the moment.

But unfortunately we do have some regressions right now, and we've got
to look at how to fix those.  If we do go driver-specific in
NetworkManager, then there really will be a Flag Day where we turn off
that support and force drivers to be WEXT compliant.  If distros don't
like that, they can either fix the drivers or patch NM (Fedora
included).  I'd like that day to be as soon as realistically possible.

Dan

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


WPA status 2006-01-08

2006-01-08 Thread Dan Williams
This will be likely be the last WPA-related status update email, which
means that the job is mostly done :)

Major Changes since Jan 3rd
---

1) Starting from example code from Kay Sievers (thanks!), I've written
the supplicant manager code.  Instead of writing a config file, we
connect to the supplicant's control sockets.  It's cleaner this way.

2) WPA-related options have been enabled in the Gnome applet

3) Minor WPA-related bugs have been fixed in both the Gnome applet and
NetworkManager itself


What's left to be done?
---

1) Bug fixes

2) Whack drivers into shape

That's about it.  If you've got a relatively recent wpa_supplicant (say,
from the last couple weeks or so), and you've got a WPA-capable card 
driver (see below *), you should be set for WPA Personal (WPA1)
Preshared-Key connections.  I've tested them, and it works.

I'd like to clean things up, get stuff working reliably, then move on to
adding WPA2-PSK/CCMP connections (ie, using AES).  After than, we start
doing 802.1x authentication, RADIUS, and possibly LEAP.  Oh, and
Bluetooth DUN, now that I have a Bluetooth phone.

Cheers,
Dan


*) Your driver probably doesn't support WPA quite enough; you'll need a
driver that does WEXT-18 or higher.  This means that it needs to set the
enc_capa bits on return from the SIOCGIWRANGE call, which only hostap
seems to do right now.

The attached patch works for ipw2100, but only because it can already do
WPA.  It was simply not telling NM that it could.  Other drivers may
need substantial changes to work with WEXT-18's enhanced encryption API.
Drivers that _may_ work with few changes: ipw2100, ipw2200, atmel,
prism54.  Drivers that need lots of fixup: orinoco, airo, bcm43xx.

--- ipw2100.c.nowpa	2006-01-08 14:04:00.0 -0500
+++ ipw2100.c	2006-01-08 15:47:37.0 -0500
@@ -7236,7 +7236,7 @@
 
 	/* Set the Wireless Extension versions */
 	range-we_version_compiled = WIRELESS_EXT;
-	range-we_version_source = 16;
+	range-we_version_source = 18;
 
 //  range-retry_capa;  /* What retry options are supported */
 //  range-retry_flags; /* How to decode max/min retry limit */
@@ -7262,6 +7262,11 @@
 	}
 	range-num_frequency = val;
 
+#if WIRELESS_EXT  17
+	range-enc_capa = IW_ENC_CAPA_WPA | IW_ENC_CAPA_WPA2 |
+		IW_ENC_CAPA_CIPHER_TKIP | IW_ENC_CAPA_CIPHER_CCMP;
+#endif /* WIRELESS_EXT  17 */
+
 	IPW_DEBUG_WX(GET Range\n);
 
 	return 0;
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: WPA status 2006-01-08

2006-01-08 Thread Robert Love
On Sun, 2006-01-08 at 16:48 -0500, Dan Williams wrote:

 That's about it.  If you've got a relatively recent wpa_supplicant (say,
 from the last couple weeks or so), and you've got a WPA-capable card 
 driver (see below *), you should be set for WPA Personal (WPA1)
 Preshared-Key connections.  I've tested them, and it works.
 
 I'd like to clean things up, get stuff working reliably, then move on to
 adding WPA2-PSK/CCMP connections (ie, using AES).  After than, we start
 doing 802.1x authentication, RADIUS, and possibly LEAP.  Oh, and
 Bluetooth DUN, now that I have a Bluetooth phone.

We should all tip our hat to Dan.  Excellent work!

Robert Love


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


Re: WPA status 2006-01-08

2006-01-08 Thread Derek Frye
Congratulations, this is what many people are waiting for! I'd test, but 
haven't a wpa-ready driver (bcm43xx).


Thanks!
--Derek
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: WPA status 2006-01-03

2006-01-05 Thread Dan Williams
On Thu, 2006-01-05 at 10:24 -0500, Robert Love wrote:
 On Tue, 2006-01-03 at 17:19 -0500, Dan Williams wrote:
 
  What's left to be done?
  ---
 
 'Connect to Other Network' and 'Create New Network' do not work.  Is
 this known or ... ?
 
 The latter prints a warning: tried to manually connect to network 'foo'
 without providing security information!'
 
 And then, in both cases, basically nothing happens.

Hmm, bug :)

Dan

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


Re: WPA status 2006-01-03

2006-01-05 Thread Robert Love
On Thu, 2006-01-05 at 12:21 -0500, Dan Williams wrote:

 They should be hooked up, I got it all working before Christmas and
 before I started the NMDevice refactor.

Hrm.

  Also - are we converting old-style gconf/keyring data?
 
 Yes, since around the 23 Dec 2005 or so.  Can you try running the applet
 with --sm-disable and see if it prints anything out when you try Other
 wireless network ?

Sure thing.

It does not print anything.  The daemon prints:

NetworkManager: debug info[1136482380.660630]  (): Forcing AP 
'wolf'
NetworkManager: WARNING (): 
nm_device_802_11_wireless_get_activation_ap: tried to manually connect to 
network 'wolf' without providing security information!
NetworkManager: information   User Switch: 
/org/freedesktop/NetworkManager/Devices/ath0 / wolf
NetworkManager: information   Deactivating device ath0.
NetworkManager: nm_act_request_new: assertion `ap != NULL' failed
NetworkManager: nm_policy_schedule_device_activation: assertion `req != 
NULL' failed

Meanwhile, doing Create New Network, shows no response in the daemon,
but the applet prints:

** Message: information   Creating network 'molly' on device 
'/org/freedesktop/NetworkManager/Devices/ath0'.

In either case, nothing actually happens.  The applet looks the same and
the daemon initiates no change.

Robert Love


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


Re: WPA status 2006-01-03

2006-01-05 Thread Robert Love
On Thu, 2006-01-05 at 12:32 -0500, Robert Love wrote:

 In either case, nothing actually happens.  The applet looks the same and
 the daemon initiates no change.

The problem is nm-dbus-nm.c :: line 260, where we call
nm_device_802_11_wireless_get_activation_ap().

security is NULL, but the function wants a non-NULL security in the case
of a non-scanned network.

It looks like nm_dbus_nm_set_active_device() should be creating a
security context?

But ... if I try to connect to an AP with encryption via Connect to
Other, I get:

NetworkManager: nm_ap_security_new_deserialize: assertion 
`dbus_message_iter_get_arg_type (iter) == DBUS_TYPE_INT32' failed
NetworkManager: WARNING  (): nm-dbus-nm.c:254 
(nm_dbus_nm_set_active_device): Invalid argument (wireless security info).

Does that point to something obvious?

You aren't seeing the same behavior?

Robert Love


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


WPA status 2006-01-03

2006-01-03 Thread Dan Williams
Another WPA-related update.

Major Changes since Dec 22
--

1) NMDevice has been refactored and GObject-ified.  Wired and wireless
are now subclasses.  This should make a Bluetooth DUN device quite a bit
easier to write, for example.  Anyone?

2) The applet respects capabilities for both access points and devices

3) Normalization of how generic wireless ciphers in libnm-util return
hashed key information


What's left to be done?
---

o Hook up WPA options in the applet
o Create a supplicant_manager object that controls invocations of
wpa_supplicant
o Write out correct wpa_supplicant config file and ask the
NMAPSecurity objects to write out their security information
o Connect to wpa_supplicant's control socket to monitor association
status

Again, we don't actually do WPA yet.  The NMDevice refactor was
necessary to constrain the parts of the code that utilize
wpa_supplicant.  These changes should now be localized in the 802.11
wireless device subclass, nm-device-802-11-wireless.c.

Dan



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


Re: WPA status 2006-01-03

2006-01-03 Thread Kay Sievers
On Tue, Jan 03, 2006 at 05:19:29PM -0500, Dan Williams wrote:
 Another WPA-related update.
 
 Major Changes since Dec 22
 --
 
 1) NMDevice has been refactored and GObject-ified.  Wired and wireless
 are now subclasses.  This should make a Bluetooth DUN device quite a bit
 easier to write, for example.  Anyone?
 
 2) The applet respects capabilities for both access points and devices
 
 3) Normalization of how generic wireless ciphers in libnm-util return
 hashed key information
 
 
 What's left to be done?
 ---
 
 o Hook up WPA options in the applet
 o Create a supplicant_manager object that controls invocations of
 wpa_supplicant
 o Write out correct wpa_supplicant config file and ask the
 NMAPSecurity objects to write out their security information
 o Connect to wpa_supplicant's control socket to monitor association
 status

Dan, can you comment on:
  http://mail.gnome.org/archives/networkmanager-list/2005-December/msg00193.html

and let me know, what you think we need more than this. The code
should work for setting up WPA PSK from NM and listen to wpa_supplicant
events from NM.

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


WPA status

2005-12-15 Thread Wendell MacKenzie
Any ETA on when builds will be available for this to try that won't
crash my machine?

Regards,
Wendell
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: WPA status

2005-12-15 Thread Dan Williams
On Thu, 2005-12-15 at 16:32 -0500, Wendell MacKenzie wrote:
 Any ETA on when builds will be available for this to try that won't
 crash my machine?

Realistically, after Christmas.

Dan

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


Re: networkmanager wpa status?

2005-06-23 Thread Tim Warberg
 Work is proceeding slowly, but should be ramping up soon in the next
 couple of weeks.  Its something we need to have.

 That said, having looked a bunch at wpa_supplicant again, I'm no longer
 convinced that it should be standalone.  I'm just not sure, but it
 depends on how much the upstream maintainer _dis_likes patches that
 would give the ability to turn wpa_supplicant into a library.  He's
 stated that he doesn't see a reason to do so in the past, but perhaps
 we've just got more convincing to do.

Can certainly see your point of view as it would make it much easier
to use wpa_supplicant including status tracking. But if were going to
begin from scratch perhaps Open1x (http://www.open1x.org) should
have a chance. Maybe they're more into the library idea.
One big downside to Open1x is configuration. Last time i looked the
configuration needed for WPA seemed allot more difficult than
wpa_supplicant. Also I think it will take more development hours to do
than wpa_supplicant. Only guessing thou. The extra work might be worth
it because then NM would be able to do 802.1x wired as well as
wireless.

Lastly if quick development is of great importance I'm probably not
the one for the job. I have zero library development experience. Thou
I will gladly help as much as i can and as fast as I can ;).

-- 
Tim Warberg
Email: twarberg at gmail.com
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list


Re: networkmanager wpa status?

2005-06-23 Thread Tim Warberg
Forget what i wrote about Open1x. Just had another look, wish i did
this before i wrote the mail, it seems that Open1x only does WPA with
Radius. Guess were sticking with wpa_supplicant.

-- 
Tim Warberg
Email: twarberg at gmail.com
___
NetworkManager-list mailing list
NetworkManager-list@gnome.org
http://mail.gnome.org/mailman/listinfo/networkmanager-list