Hi,
we'd like to support roaming in our firmware and currently have a mac80211
driver.
I know that we need to set the WIPHY_FLAG_SUPPORTS_FW_ROAMING but I'm not
sure if anything else needs to be signalled (called) in to mac80211?
I've seen calls to cfg80211_roamed_bss which gets the roamed indication out
to the user space but do we need to use this as well?
Can anyone explain?
Thanks
Mark
Hi,
The short answer to your question is: no.
> I know that we need to set the WIPHY_FLAG_SUPPORTS_FW_ROAMING but I'm not
> sure if anything else needs to be signalled (called) in to mac80211?
>
> I've seen calls to cfg80211_roamed_bss which gets the roamed indication out
> to the user space but do we need to use this as well?
>
> Can anyone explain?
The longer answer is that mac80211 doesn't use the connect API, it
implements the MLME itself. Roaming in firmware isn't just that, it's
much much more complex. Think of the AP station entry getting updated
(mac80211 would have to do this!), the new QoS/WMM parameters,
BSSID, ...
If you have roaming in your firmware, then you must have the MLME in the
firmware as well. Then, why are you using mac80211? Clearly not for the
MLME, but then what for instead? Maybe what you really want instead is
to do some (really really big!) refactoring on the datapath?
johannes
On 05/03/2013 02:56 PM, Johannes Berg wrote:
> Hi,
>
> The short answer to your question is: no.
>
>> I know that we need to set the WIPHY_FLAG_SUPPORTS_FW_ROAMING but I'm not
>> sure if anything else needs to be signalled (called) in to mac80211?
>>
>> I've seen calls to cfg80211_roamed_bss which gets the roamed indication out
>> to the user space but do we need to use this as well?
>>
>> Can anyone explain?
>
> The longer answer is that mac80211 doesn't use the connect API, it
> implements the MLME itself. Roaming in firmware isn't just that, it's
> much much more complex. Think of the AP station entry getting updated
> (mac80211 would have to do this!), the new QoS/WMM parameters,
> BSSID, ...
>
> If you have roaming in your firmware, then you must have the MLME in the
> firmware as well. Then, why are you using mac80211? Clearly not for the
> MLME, but then what for instead? Maybe what you really want instead is
> to do some (really really big!) refactoring on the datapath?
More general, a while ago we have been looking at mac80211 offloads to
see whether the brcmfmac driver could be (effectively) converted to a
mac80211 driver. The only possible conclusion was that a device with
MLME in firmware should have a cfg80211 based driver, but maybe some
daredevil would feel challenged to implement MLME firmware-offloading in
mac80211, but that is probably a 'really really big' task :-)
Regards,
Arend