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

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

[Avery Pennarun]

Hi,

In the ath9k and several other drivers, commands like the following
work while in AP mode:

  iw wlan0 scan -u ap-force passive
and
  iw wlan0 offchannel 2452  100

On ath10k (using a driver from v3.15-rc1 as of April 13th), these tell
me the operation is not supported.

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.

Thanks,

Avery

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Kalle Valo]

Avery Pennarun <apenwarr@gmail.com> writes:

> In the ath9k and several other drivers, commands like the following
> work while in AP mode:
>
>   iw wlan0 scan -u ap-force passive
> and
>   iw wlan0 offchannel 2452  100
>
> On ath10k (using a driver from v3.15-rc1 as of April 13th), these tell
> me the operation is not supported.

Yeah, mac80211 only supports this with sw_scan but ath10k uses hw_scan.
From ieee80211_alloc_hw():

	if (!ops->hw_scan)
		wiphy->features |= NL80211_FEATURE_LOW_PRIORITY_SCAN |
				   NL80211_FEATURE_AP_SCAN;

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

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Avery Pennarun]

On Tue, Aug 19, 2014 at 1:50 AM, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Avery Pennarun <apenwarr@gmail.com> writes:
>> In the ath9k and several other drivers, commands like the following
>> work while in AP mode:
>>
>>   iw wlan0 scan -u ap-force passive
>> and
>>   iw wlan0 offchannel 2452  100
>>
>> On ath10k (using a driver from v3.15-rc1 as of April 13th), these tell
>> me the operation is not supported.
>
> Yeah, mac80211 only supports this with sw_scan but ath10k uses hw_scan.
> From ieee80211_alloc_hw():
>
>         if (!ops->hw_scan)
>                 wiphy->features |= NL80211_FEATURE_LOW_PRIORITY_SCAN |
>                                    NL80211_FEATURE_AP_SCAN;
>
>> 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.

Thanks,

Avery

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Kalle Valo]

Avery Pennarun <apenwarr@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?

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Michal Kazior]

On 19 August 2014 04:26, Avery Pennarun <apenwarr@gmail.com> wrote:
> Hi,
>
> In the ath9k and several other drivers, commands like the following
> work while in AP mode:
>
>   iw wlan0 scan -u ap-force passive
> and

Hmm.. I recall seeing a hack for that in OpenWRT codebase. I'd have to
double check that.


>   iw wlan0 offchannel 2452  100

This actually works* for me.

* the remain on channel is completed prematurely by firmware probably
due to beaconing. Perhaps changing internal scan priority could help.


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Michal Kazior]

On 19 August 2014 08:07, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Avery Pennarun <apenwarr@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)?


Michał

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Kalle Valo]

Michal Kazior <michal.kazior@tieto.com> writes:

> On 19 August 2014 08:07, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>> Avery Pennarun <apenwarr@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.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Michal Kazior]

On 19 August 2014 08:30, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
> Michal Kazior <michal.kazior@tieto.com> writes:
>
>> On 19 August 2014 08:07, Kalle Valo <kvalo@qca.qualcomm.com> wrote:
>>> Avery Pennarun <apenwarr@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ł

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Adrian Chadd]

Hi,

Yes. The whole point is that the firmware knows about the vdev and you
set the channel on that. The intention is that there's multiple vdevs
and if they're on different channels (eg STA + P2P, or STA + STA) then
the firmware can handle channel changing, sending sleep notifications
to the AP, buffering frames (well, pointers to frame data) so things
don't get dropped, etc.

I vaguely recall there being feature requests to do scanning in AP
mode. It's a dirty hack, because yes you end up having packet loss
during the scan for reasons I don't have to describe here, but you
don't want it to be so bad that clients disassociate from you or end
up having holes in the A-MPDU sequence space..


-a

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Avery Pennarun]

On Tue, Aug 19, 2014 at 11:23 AM, Adrian Chadd <adrian@freebsd.org> wrote:
> Yes. The whole point is that the firmware knows about the vdev and you
> set the channel on that. The intention is that there's multiple vdevs
> and if they're on different channels (eg STA + P2P, or STA + STA) then
> the firmware can handle channel changing, sending sleep notifications
> to the AP, buffering frames (well, pointers to frame data) so things
> don't get dropped, etc.
>
> I vaguely recall there being feature requests to do scanning in AP
> mode. It's a dirty hack, because yes you end up having packet loss
> during the scan for reasons I don't have to describe here, but you
> don't want it to be so bad that clients disassociate from you or end
> up having holes in the A-MPDU sequence space..

For my own purposes - scanning while the AP is running - the dirtiness
doesn't bother me *too* much.  Ideally I would like to request a
super-low-priority scan that only goes offchannel for short periods
but could take several (or even many) seconds to complete.  I gather
this is what the 'lowpri' option to 'iw ... scan' is for.

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Adrian Chadd]

Yeah, but you have to be careful to not drop any queued frames or
associated station state. Hence why it's done as a separate vdev,
rather than being done under software channel change control.


-a

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Avery Pennarun]

On Tue, Aug 19, 2014 at 5:56 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> Yeah, but you have to be careful to not drop any queued frames or
> associated station state. Hence why it's done as a separate vdev,
> rather than being done under software channel change control.

That makes sense.  So how doomed am I if I want this feature? :)

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: 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@tieto.com> wrote:
> On 19 August 2014 08:30, Kalle Valo <kvalo@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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Michal Kazior]

On 27 August 2014 08:46, Avery Pennarun <apenwarr@gmail.com> wrote:
> On Tue, Aug 19, 2014 at 3:01 AM, Michal Kazior <michal.kazior@tieto.com> wrote:
>> On 19 August 2014 08:30, Kalle Valo <kvalo@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ł

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

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

[Avery Pennarun]

On Wed, Aug 27, 2014 at 2:55 AM, Michal Kazior <michal.kazior@tieto.com> wrote:
> Avery wrote:
>> Any guesses about why the offchannel time would be too short on ath10k?
>
> Try setting up a larger beacon interval, e.g. 300ms.

wireshark confirmed that the beacon interval was changed, but
offchannel time was weirdly still about 50ms.

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

Looks like the 10.2 firmware does indeed fix this problem.  Offchannel
time is now more like 130ms, no packet loss, and the scan reliably
sees beacons on the other channel.

The first time I booted with the new firmware, my AP seemed to
silently not be working.  Restarting hostapd fixed it.  I'll start
another thread if this recurs.

Thanks!

Avery

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k