Support for scan while in AP mode, and offchannel while in AP mode

[Michal Kazior]

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
>>> scanning?
>>
>> 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:

http://git.openwrt.org/?p=openwrt.git;a=blob;f=package/kernel/mac80211/patches/310-ap_scan.patch;h=23ecd370300f13c25983bbbeaa7d718c3e250997;hb=HEAD

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).


Michał