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

Marcel Holtmann
2009-04-23T13:16:20Z

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