Using wpa_supplicant in D-Bus mode with nl80211 driver

Using wpa_supplicant in D-Bus mode with nl80211 driver

[Marcel Holtmann]

Hi Jouni,

I am trying to use wpa_supplicant in D-Bus mode with the nl80211 driver
instead of WEXT. I don't seem to be able to control the from the command
line and the -D option doesn't take.

Providing DBus service 'fi.epitest.hostap.WPASupplicant'.
Initializing interface 'wlan0' conf 'N/A' driver 'default' ctrl_interface 'N/A' bridge 'N/A'
Interface wlan0 set UP - waiting a second for the driver to complete initialization
SIOCGIWRANGE: WE(compiled)=22 WE(source)=21 enc_capa=0xf
  capabilities: key_mgmt 0xf enc 0xf flags 0x0

Can we fix this somehow? I really wanna get rid of using WEXT.

Regards

Marcel

Re: Using wpa_supplicant in D-Bus mode with nl80211 driver

[Jouni Malinen]

On Wed, Apr 22, 2009 at 05:52:57PM +0100, Marcel Holtmann wrote:

> I am trying to use wpa_supplicant in D-Bus mode with the nl80211 driver
> instead of WEXT. I don't seem to be able to control the from the command
> line and the -D option doesn't take.

I would assume you are doing this with NM. You could either change it to
register the interface (this is not from -D option, but from the D-Bus
message) with the nl80211 driver or try to build wpa_supplicant without
WEXT support (which would make the nl80211 wrapper the default one). I
don't think either of these are yet acceptable as a generic solution,
but making NM request driver "nl80211,wext" could be a suitable first
step when moving to wpa_supplicant 0.7.x (this makes wpa_supplicant
first try with nl80211 and if needed, fall back to WEXT).

> Can we fix this somehow? I really wanna get rid of using WEXT.

There still one remaining WEXT operation even with driver_nl80211.c in
wpa_supplicant, so we are not yet there, but there is work going on in
getting that added to nl80211 after which point -Dnl80211 (or
-Dnl80211,wext for more likely distro use) should allow this goal to be
met.

-- 
Jouni Malinen                                            PGP id EFC895FA

Re: Using wpa_supplicant in D-Bus mode with nl80211 driver

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 609 bytes --]

On Wed, 2009-04-22 at 20:08 +0300, Jouni Malinen wrote:

> > Can we fix this somehow? I really wanna get rid of using WEXT.
> 
> There still one remaining WEXT operation even with driver_nl80211.c in
> wpa_supplicant, so we are not yet there, but there is work going on in
> getting that added to nl80211 after which point -Dnl80211 (or
> -Dnl80211,wext for more likely distro use) should allow this goal to be
> met.

We also need that message when we abort authentication after three tries
because otherwise wpa-supplicant just hangs there doing nothing and
mac80211 does so too :)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Using wpa_supplicant in D-Bus mode with nl80211 driver

[Marcel Holtmann]

Hi Jouni,

> > I am trying to use wpa_supplicant in D-Bus mode with the nl80211 driver
> > instead of WEXT. I don't seem to be able to control the from the command
> > line and the -D option doesn't take.
> 
> I would assume you are doing this with NM. You could either change it to
> register the interface (this is not from -D option, but from the D-Bus
> message) with the nl80211 driver or try to build wpa_supplicant without
> WEXT support (which would make the nl80211 wrapper the default one). I
> don't think either of these are yet acceptable as a generic solution,
> but making NM request driver "nl80211,wext" could be a suitable first
> step when moving to wpa_supplicant 0.7.x (this makes wpa_supplicant
> first try with nl80211 and if needed, fall back to WEXT).

I am doing manual testing and with ConnMan. However I would prefer to
have a global driver setting "nl80211,wext" that I can give on the
command line and that will then chosen as default if the addInterface
method doesn't give a driver. I really don't need a per interface
setting here.

> > Can we fix this somehow? I really wanna get rid of using WEXT.
> 
> There still one remaining WEXT operation even with driver_nl80211.c in
> wpa_supplicant, so we are not yet there, but there is work going on in
> getting that added to nl80211 after which point -Dnl80211 (or
> -Dnl80211,wext for more likely distro use) should allow this goal to be
> met.

Fair enough, but we are getting there and when testing, I like to be
using as much nl80211 as possible.

Regards

Marcel

Re: Using wpa_supplicant in D-Bus mode with nl80211 driver

[Dan Williams]

On Wed, 2009-04-22 at 19:55 +0100, Marcel Holtmann wrote:
> Hi Jouni,
> 
> > > I am trying to use wpa_supplicant in D-Bus mode with the nl80211 driver
> > > instead of WEXT. I don't seem to be able to control the from the command
> > > line and the -D option doesn't take.
> > 
> > I would assume you are doing this with NM. You could either change it to
> > register the interface (this is not from -D option, but from the D-Bus
> > message) with the nl80211 driver or try to build wpa_supplicant without
> > WEXT support (which would make the nl80211 wrapper the default one). I
> > don't think either of these are yet acceptable as a generic solution,
> > but making NM request driver "nl80211,wext" could be a suitable first
> > step when moving to wpa_supplicant 0.7.x (this makes wpa_supplicant
> > first try with nl80211 and if needed, fall back to WEXT).
> 
> I am doing manual testing and with ConnMan. However I would prefer to
> have a global driver setting "nl80211,wext" that I can give on the
> command line and that will then chosen as default if the addInterface
> method doesn't give a driver. I really don't need a per interface
> setting here.

Um, you can specify a driver for the interface you add in the dbus call
for addInterface.  Add a "driver" key to your dict with the driver you
want in the value.  Is there a bug with that?

Dan

> > > Can we fix this somehow? I really wanna get rid of using WEXT.
> > 
> > There still one remaining WEXT operation even with driver_nl80211.c in
> > wpa_supplicant, so we are not yet there, but there is work going on in
> > getting that added to nl80211 after which point -Dnl80211 (or
> > -Dnl80211,wext for more likely distro use) should allow this goal to be
> > met.
> 
> Fair enough, but we are getting there and when testing, I like to be
> using as much nl80211 as possible.
> 
> Regards
> 
> Marcel
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Using wpa_supplicant in D-Bus mode with nl80211 driver

[Marcel Holtmann]

Hi Dan,

> > > > I am trying to use wpa_supplicant in D-Bus mode with the nl80211 driver
> > > > instead of WEXT. I don't seem to be able to control the from the command
> > > > line and the -D option doesn't take.
> > > 
> > > I would assume you are doing this with NM. You could either change it to
> > > register the interface (this is not from -D option, but from the D-Bus
> > > message) with the nl80211 driver or try to build wpa_supplicant without
> > > WEXT support (which would make the nl80211 wrapper the default one). I
> > > don't think either of these are yet acceptable as a generic solution,
> > > but making NM request driver "nl80211,wext" could be a suitable first
> > > step when moving to wpa_supplicant 0.7.x (this makes wpa_supplicant
> > > first try with nl80211 and if needed, fall back to WEXT).
> > 
> > I am doing manual testing and with ConnMan. However I would prefer to
> > have a global driver setting "nl80211,wext" that I can give on the
> > command line and that will then chosen as default if the addInterface
> > method doesn't give a driver. I really don't need a per interface
> > setting here.
> 
> Um, you can specify a driver for the interface you add in the dbus call
> for addInterface.  Add a "driver" key to your dict with the driver you
> want in the value.  Is there a bug with that?

I know that I can do that. I was just looking for a global configuration
switch to default to nl80211,wext via D-Bus system activation and not
via changing the code.

Regards

Marcel

Re: Using wpa_supplicant in D-Bus mode with nl80211 driver

[Dan Williams]

On Thu, 2009-04-23 at 09:39 +0100, Marcel Holtmann wrote:
> Hi Dan,
> 
> > > > > I am trying to use wpa_supplicant in D-Bus mode with the nl80211 driver
> > > > > instead of WEXT. I don't seem to be able to control the from the command
> > > > > line and the -D option doesn't take.
> > > > 
> > > > I would assume you are doing this with NM. You could either change it to
> > > > register the interface (this is not from -D option, but from the D-Bus
> > > > message) with the nl80211 driver or try to build wpa_supplicant without
> > > > WEXT support (which would make the nl80211 wrapper the default one). I
> > > > don't think either of these are yet acceptable as a generic solution,
> > > > but making NM request driver "nl80211,wext" could be a suitable first
> > > > step when moving to wpa_supplicant 0.7.x (this makes wpa_supplicant
> > > > first try with nl80211 and if needed, fall back to WEXT).
> > > 
> > > I am doing manual testing and with ConnMan. However I would prefer to
> > > have a global driver setting "nl80211,wext" that I can give on the
> > > command line and that will then chosen as default if the addInterface
> > > method doesn't give a driver. I really don't need a per interface
> > > setting here.
> > 
> > Um, you can specify a driver for the interface you add in the dbus call
> > for addInterface.  Add a "driver" key to your dict with the driver you
> > want in the value.  Is there a bug with that?
> 
> I know that I can do that. I was just looking for a global configuration
> switch to default to nl80211,wext via D-Bus system activation and not
> via changing the code.

Even with system activation you still need to call addInterface, which
can take the driver.  I still don't quite understand what you're getting
at here, I guess...  When you say "not change code" you mean in the
process that's calling wpa_supplicant?

Dan

Re: Using wpa_supplicant in D-Bus mode with nl80211 driver

[Marcel Holtmann]

Hi Dan,

> > > > > > I am trying to use wpa_supplicant in D-Bus mode with the nl80211 driver
> > > > > > instead of WEXT. I don't seem to be able to control the from the command
> > > > > > line and the -D option doesn't take.
> > > > > 
> > > > > I would assume you are doing this with NM. You could either change it to
> > > > > register the interface (this is not from -D option, but from the D-Bus
> > > > > message) with the nl80211 driver or try to build wpa_supplicant without
> > > > > WEXT support (which would make the nl80211 wrapper the default one). I
> > > > > don't think either of these are yet acceptable as a generic solution,
> > > > > but making NM request driver "nl80211,wext" could be a suitable first
> > > > > step when moving to wpa_supplicant 0.7.x (this makes wpa_supplicant
> > > > > first try with nl80211 and if needed, fall back to WEXT).
> > > > 
> > > > I am doing manual testing and with ConnMan. However I would prefer to
> > > > have a global driver setting "nl80211,wext" that I can give on the
> > > > command line and that will then chosen as default if the addInterface
> > > > method doesn't give a driver. I really don't need a per interface
> > > > setting here.
> > > 
> > > Um, you can specify a driver for the interface you add in the dbus call
> > > for addInterface.  Add a "driver" key to your dict with the driver you
> > > want in the value.  Is there a bug with that?
> > 
> > I know that I can do that. I was just looking for a global configuration
> > switch to default to nl80211,wext via D-Bus system activation and not
> > via changing the code.
> 
> Even with system activation you still need to call addInterface, which
> can take the driver.  I still don't quite understand what you're getting
> at here, I guess...  When you say "not change code" you mean in the
> process that's calling wpa_supplicant?

that is exactly what I mean. So to switch NM to use nl80211 you would
have to change the NM code. I prefer to have this a command line option
so people can turn it back to wext in case something breaks. Or a vendor
driver for that matter (not that I care about these).

Regards

Marcel

Re: Using wpa_supplicant in D-Bus mode with nl80211 driver

[Dan Williams]

On Thu, 2009-04-23 at 12:15 +0100, Marcel Holtmann wrote:
> Hi Dan,
> 
> > > > > > > I am trying to use wpa_supplicant in D-Bus mode with the nl80211 driver
> > > > > > > instead of WEXT. I don't seem to be able to control the from the command
> > > > > > > line and the -D option doesn't take.
> > > > > > 
> > > > > > I would assume you are doing this with NM. You could either change it to
> > > > > > register the interface (this is not from -D option, but from the D-Bus
> > > > > > message) with the nl80211 driver or try to build wpa_supplicant without
> > > > > > WEXT support (which would make the nl80211 wrapper the default one). I
> > > > > > don't think either of these are yet acceptable as a generic solution,
> > > > > > but making NM request driver "nl80211,wext" could be a suitable first
> > > > > > step when moving to wpa_supplicant 0.7.x (this makes wpa_supplicant
> > > > > > first try with nl80211 and if needed, fall back to WEXT).
> > > > > 
> > > > > I am doing manual testing and with ConnMan. However I would prefer to
> > > > > have a global driver setting "nl80211,wext" that I can give on the
> > > > > command line and that will then chosen as default if the addInterface
> > > > > method doesn't give a driver. I really don't need a per interface
> > > > > setting here.
> > > > 
> > > > Um, you can specify a driver for the interface you add in the dbus call
> > > > for addInterface.  Add a "driver" key to your dict with the driver you
> > > > want in the value.  Is there a bug with that?
> > > 
> > > I know that I can do that. I was just looking for a global configuration
> > > switch to default to nl80211,wext via D-Bus system activation and not
> > > via changing the code.
> > 
> > Even with system activation you still need to call addInterface, which
> > can take the driver.  I still don't quite understand what you're getting
> > at here, I guess...  When you say "not change code" you mean in the
> > process that's calling wpa_supplicant?
> 
> that is exactly what I mean. So to switch NM to use nl80211 you would
> have to change the NM code. I prefer to have this a command line option
> so people can turn it back to wext in case something breaks. Or a vendor
> driver for that matter (not that I care about these).

That's exactly why it's hardcoded, so people can't change it just on a
whim, and break their stuff.  It's great and desired to try nl80211 to,
as a developer, test it out and make sure it works with nl80211 (and fix
supplicant bugs that come up) but, of course, that shouldn't be done for
end-users.

The real fix here is to do what Johannes and I were talking about two
nights ago; provide udev-based driver hints for those drivers supporting
nl80211, or else have NM inspect the driver directly with netlink and
determine whether it supports nl80211, and then direct wpa_supplicant to
use nl80211 instead of wext.  I'll take a patch to do that, because I
want to kill wext as much as you do.

But hacking that stuff in without doing it the right way is only
suitable for development, and given that, I'd be against any sort of
change to wpa_supplicant as you've proposed.

Dan

Re: Using wpa_supplicant in D-Bus mode with nl80211 driver

[Marcel Holtmann]

Hi Dan,

> > > > > > > > I am trying to use wpa_supplicant in D-Bus mode with the nl80211 driver
> > > > > > > > instead of WEXT. I don't seem to be able to control the from the command
> > > > > > > > line and the -D option doesn't take.
> > > > > > > 
> > > > > > > I would assume you are doing this with NM. You could either change it to
> > > > > > > register the interface (this is not from -D option, but from the D-Bus
> > > > > > > message) with the nl80211 driver or try to build wpa_supplicant without
> > > > > > > WEXT support (which would make the nl80211 wrapper the default one). I
> > > > > > > don't think either of these are yet acceptable as a generic solution,
> > > > > > > but making NM request driver "nl80211,wext" could be a suitable first
> > > > > > > step when moving to wpa_supplicant 0.7.x (this makes wpa_supplicant
> > > > > > > first try with nl80211 and if needed, fall back to WEXT).
> > > > > > 
> > > > > > I am doing manual testing and with ConnMan. However I would prefer to
> > > > > > have a global driver setting "nl80211,wext" that I can give on the
> > > > > > command line and that will then chosen as default if the addInterface
> > > > > > method doesn't give a driver. I really don't need a per interface
> > > > > > setting here.
> > > > > 
> > > > > Um, you can specify a driver for the interface you add in the dbus call
> > > > > for addInterface.  Add a "driver" key to your dict with the driver you
> > > > > want in the value.  Is there a bug with that?
> > > > 
> > > > I know that I can do that. I was just looking for a global configuration
> > > > switch to default to nl80211,wext via D-Bus system activation and not
> > > > via changing the code.
> > > 
> > > Even with system activation you still need to call addInterface, which
> > > can take the driver.  I still don't quite understand what you're getting
> > > at here, I guess...  When you say "not change code" you mean in the
> > > process that's calling wpa_supplicant?
> > 
> > that is exactly what I mean. So to switch NM to use nl80211 you would
> > have to change the NM code. I prefer to have this a command line option
> > so people can turn it back to wext in case something breaks. Or a vendor
> > driver for that matter (not that I care about these).
> 
> That's exactly why it's hardcoded, so people can't change it just on a
> whim, and break their stuff.  It's great and desired to try nl80211 to,
> as a developer, test it out and make sure it works with nl80211 (and fix
> supplicant bugs that come up) but, of course, that shouldn't be done for
> end-users.
> 
> The real fix here is to do what Johannes and I were talking about two
> nights ago; provide udev-based driver hints for those drivers supporting
> nl80211, or else have NM inspect the driver directly with netlink and
> determine whether it supports nl80211, and then direct wpa_supplicant to
> use nl80211 instead of wext.  I'll take a patch to do that, because I
> want to kill wext as much as you do.
> 
> But hacking that stuff in without doing it the right way is only
> suitable for development, and given that, I'd be against any sort of
> change to wpa_supplicant as you've proposed.

the latest version of wpa_supplicant can specific a list of drivers like
nl80211,wext so it effectively falls back to wext if nl80211 decides
this doesn't work or is not present. Should we not just add driver
quirks/blacklist into wpa_supplicant then?

Regards

Marcel

Re: Using wpa_supplicant in D-Bus mode with nl80211 driver

[Dan Williams]

On Thu, 2009-04-23 at 14:16 +0100, Marcel Holtmann wrote:
> Hi Dan,
> 
> > > > > > > > > I am trying to use wpa_supplicant in D-Bus mode with the nl80211 driver
> > > > > > > > > instead of WEXT. I don't seem to be able to control the from the command
> > > > > > > > > line and the -D option doesn't take.
> > > > > > > > 
> > > > > > > > I would assume you are doing this with NM. You could either change it to
> > > > > > > > register the interface (this is not from -D option, but from the D-Bus
> > > > > > > > message) with the nl80211 driver or try to build wpa_supplicant without
> > > > > > > > WEXT support (which would make the nl80211 wrapper the default one). I
> > > > > > > > don't think either of these are yet acceptable as a generic solution,
> > > > > > > > but making NM request driver "nl80211,wext" could be a suitable first
> > > > > > > > step when moving to wpa_supplicant 0.7.x (this makes wpa_supplicant
> > > > > > > > first try with nl80211 and if needed, fall back to WEXT).
> > > > > > > 
> > > > > > > I am doing manual testing and with ConnMan. However I would prefer to
> > > > > > > have a global driver setting "nl80211,wext" that I can give on the
> > > > > > > command line and that will then chosen as default if the addInterface
> > > > > > > method doesn't give a driver. I really don't need a per interface
> > > > > > > setting here.
> > > > > > 
> > > > > > Um, you can specify a driver for the interface you add in the dbus call
> > > > > > for addInterface.  Add a "driver" key to your dict with the driver you
> > > > > > want in the value.  Is there a bug with that?
> > > > > 
> > > > > I know that I can do that. I was just looking for a global configuration
> > > > > switch to default to nl80211,wext via D-Bus system activation and not
> > > > > via changing the code.
> > > > 
> > > > Even with system activation you still need to call addInterface, which
> > > > can take the driver.  I still don't quite understand what you're getting
> > > > at here, I guess...  When you say "not change code" you mean in the
> > > > process that's calling wpa_supplicant?
> > > 
> > > that is exactly what I mean. So to switch NM to use nl80211 you would
> > > have to change the NM code. I prefer to have this a command line option
> > > so people can turn it back to wext in case something breaks. Or a vendor
> > > driver for that matter (not that I care about these).
> > 
> > That's exactly why it's hardcoded, so people can't change it just on a
> > whim, and break their stuff.  It's great and desired to try nl80211 to,
> > as a developer, test it out and make sure it works with nl80211 (and fix
> > supplicant bugs that come up) but, of course, that shouldn't be done for
> > end-users.
> > 
> > The real fix here is to do what Johannes and I were talking about two
> > nights ago; provide udev-based driver hints for those drivers supporting
> > nl80211, or else have NM inspect the driver directly with netlink and
> > determine whether it supports nl80211, and then direct wpa_supplicant to
> > use nl80211 instead of wext.  I'll take a patch to do that, because I
> > want to kill wext as much as you do.
> > 
> > But hacking that stuff in without doing it the right way is only
> > suitable for development, and given that, I'd be against any sort of
> > change to wpa_supplicant as you've proposed.
> 
> the latest version of wpa_supplicant can specific a list of drivers like
> nl80211,wext so it effectively falls back to wext if nl80211 decides
> this doesn't work or is not present. Should we not just add driver
> quirks/blacklist into wpa_supplicant then?

I fail to see how fallbacks are helpful here, it seems to me that it
will simply make it completely unknown which driver is being used at the
time without getting debugging logs from the supplicant.  Frankly, I'd
rather know *exactly* what driver NM is requesting the supplicant use,
so I know exactly what to expect.

And if there are quirks, the supplicant driver needs to get fixed.  Not
worked around.  Fixed.  Otherwise the supplicant gets littered with
workarounds, making unmaintainable and fragile code.

Dan