On Tue, Dec 01, 2015 at 11:48:32AM +0200, Kalle Valo wrote: > Arend van Spriel <arend@xxxxxxxxxxxx> writes: > > It solves a problem for us, but admittedly it is not something that is > > very usable by user-space apps. So I guess what you are suggesting > > here is to come up with a nl80211 api for this. On the mailing list > > (or hostap list) the topic pops up from time to time so there are > > people who would like to have such a knob to play with. Still would > > like to keep the module parameter although its use may change when > > nl80211 api is added. > > I don't know what is the best approach, that's why I would like to hear > opinions from others. Personally I don't like the idea of adding 802.11 > level configuration options to module parameters, but on the other hand > I don't have any strong opinions about this. I would like to see this as a new attribute to NL80211_CMD_CONNECT to provide parameters for offloaded (driver and/or firmware) BSS selection and roaming. If there is a driver that uses roaming offload with NL80211_CMD_ASSOCIATE, the same attribute could be used there (but I'm not sure how exact such offloading would work in practice since I'd expect both authentication and (re)association to be offloaded). > I guess we have two different designs, one where the roaming logic is in > firmware and other where wpasupplicant is responsible for this. (And I > assume that brcfmac belongs to the former group.) Ideally it would be > nice that we would have a same configuration knob for both but I don't > know if that's really feasible. Both of these would work as long as wpa_supplicant has means for providing such configuration to the driver in a generic manner. That NL80211_CMD_CONNECT extension with a new optional attribute would be such a generic design. -- Jouni Malinen PGP id EFC895FA -- 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
