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

[Michal Kazior]

On 27 August 2014 08:46, Avery Pennarun <apenwarr at gmail.com> wrote:
> On Tue, Aug 19, 2014 at 3:01 AM, Michal Kazior <michal.kazior at tieto.com> wrote:
>> On 19 August 2014 08:30, Kalle Valo <kvalo at qca.qualcomm.com> wrote:
>>> 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
>
> Followup: I tried the above patch and it "works", though with some problems.
>
> To check channel reliability, I ran my isoping tool:
> https://gfiber.googlesource.com/vendor/google/platform/+/master/cmds/isoping.c
>
> On the client:
>    isoping -q
> On the AP:
>    isoping -r33 <ipaddr-of-client>
>
> This sends a packet in each direction every 10ms and prints the time
> delay for each packet as well as the total packet loss.
>
> I have my AP running on channel 149 with 80 MHz width and things work
> fine (typical measured delay is <1ms).  Then I run this on the ath10k
> AP:
>
> iw wlan1 scan freq 5180 flush ap-force passive | grep KNOWN_SSID_ON_CHANNEL_36
>
> The result is:
> - isoping reports zero packets lost (very consistent)
> - packets in each direction are delayed by some amount *less* than
> 100ms.  (It looks to be about 40-50ms but sometimes less.)
> - the passive channel scan *sometimes* sees the KNOWN_SSID beacons
> (roughly 50% of the time)
>
> When I stop hostapd, the passive channel scan succeeds about 100% of the time.
>
> Removing the 'passive' parameter also makes it work, even without
> killing hostapd.  Of course this sends unwanted Probe packets on the
> channel.
>
> With an ath9k AP instead of an ath10k, it works correctly: isoping
> reports no loss, a roughly 100ms delay (within its precision), and
> passive scanning works about 100% of the time.
>
> Any guesses about why the offchannel time would be too short on ath10k?

Try setting up a larger beacon interval, e.g. 300ms.


> I haven't investigated whether the packets are enqueued or simply
> retransmitted after it returns to the channel, but in any case,
> userspace and TCP don't see packet loss, so it's fine with me.
>
> This is the ath10k driver from 3.15rc1 and firmware 10.1.467.2-1.

I think 10.2 handles scanning in AP mode more reliably so I'd suggest
you try it out. You might need to cherry pick the 10.2 support for
your 3.15rc1 (https://github.com/kvalo/ath/commit/24c88f7807fb7c723690474d0a5d3441468185d9).


Michał