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

[Avery Pennarun]

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?

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.

Suggestions?

Thanks,

Avery