Support for scan while in AP mode, and offchannel while in AP mode
michal.kazior at tieto.com
Tue Aug 19 00:01:35 PDT 2014
On 19 August 2014 08:30, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior at tieto.com> writes:
>> On 19 August 2014 08:07, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
>>> Avery Pennarun <apenwarr at gmail.com> writes:
>>>>>> Are there any plans to implement this feature? It's important in
>>>>>> order to implement automatic channel change in case of changes in the
>>>>>> interference environment.
>>>>> No plans at the moment. Does anyone know how much work would it be to
>>>>> change mac80211 to support this with hw_scan?
>>>> Is there any particular reason it can't just resort to a sw_scan for
>>>> this use case? What's the benefit of hw_scan? I'm surprised there
>>>> would be any particular CPU time taken for such a thing.
>>> For mobile devices hw_scan is important because the ability to allow the
>>> host CPU to sleep while scanning. For others I'm not that sure, maybe
>>> firmware can do timing better (less intrusive) than host based sw
>> sw_scan requires a driver to be able to "just change the channel".
>> Some device firmwares have no direct control over programmed hw
>> channel. Instead they have start/join/connect commands that implicitly
>> setup hw channel. ath10k is actually like that, isn't it (vdev start)?
> Yes, my understanding as well is that the ath10k firmware is like that.
> But I'm no firmware expert :)
> I assume that the 10.x firmware does support hw_scan when in AP mode and
> we would need to "just" change mac80211 to support that. But no idea how
> big task that actually is.
Yes it does. If we raise internal scan priority from low to at least
high then beaconing does not preempt scanning. I haven't checked how
well this works with traffic to/from connected stations though.
I've also found the OpenWRT hack I've mentioned earlier:
I wonder why NL80211_FEATURE_AP_SCAN was introduced in the first
place. Scanning on an AP vif requires NL80211_SCAN_FLAG_AP flag in the
scan request anyway. Both flags were introduced in the same patch.
ath10k probably needs just a way to tell mac80211 it supports AP scan
(or NL80211_FEATURE_AP_SCAN needs to go away).
More information about the ath10k