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

Michal Kazior michal.kazior at
Tue Aug 26 23:55:36 PDT 2014

On 27 August 2014 08:46, Avery Pennarun <apenwarr at> wrote:
> On Tue, Aug 19, 2014 at 3:01 AM, Michal Kazior <michal.kazior at> wrote:
>> On 19 August 2014 08:30, Kalle Valo <kvalo at> 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:
> Followup: I tried the above patch and it "works", though with some problems.
> To check channel reliability, I ran my isoping tool:
> 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 (


More information about the ath10k mailing list