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 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
