mac80211: AQM and block_tx

mac80211: AQM and block_tx

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 641 bytes --]

Hi Toke,

we are currently testing DFS with ath10k and noticed that AQM seems to ignore 
cfg80211_csa_settings->block_tx. Problem is now that the channel switch is 
started on a detected radar

  echo 1 >/sys/kernel/debug/ieee80211/phy1/ath10k/dfs_simulate_radar

NL80211_ATTR_CH_SWITCH_BLOCK_TX is set for the channel switch by hostapd but 
the AP still sends QoS data to the client.

Was there a fix for such a problem which I might have missed? I've just worked 
around that by setting wake_tx_queue TO NULL in ath10k. This still must be 
verified but at least I didn't see any packets anymore on a monitor interface.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: mac80211: AQM and block_tx

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

On Donnerstag, 5. Juli 2018 10:47:11 CEST Sven Eckelmann wrote:
> Hi Toke,
> 
> we are currently testing DFS with ath10k and noticed that AQM seems to ignore 
> cfg80211_csa_settings->block_tx. Problem is now that the channel switch is 
> started on a detected radar
> 
>   echo 1 >/sys/kernel/debug/ieee80211/phy1/ath10k/dfs_simulate_radar
> 
> NL80211_ATTR_CH_SWITCH_BLOCK_TX is set for the channel switch by hostapd but 
> the AP still sends QoS data to the client.
> 
> Was there a fix for such a problem which I might have missed? I've just worked 
> around that by setting wake_tx_queue TO NULL in ath10k. This still must be 
> verified but at least I didn't see any packets anymore on a monitor interface.


Just as information, the ath10k Dakota devices went through DFS certification 
but the AQM had to be disabled. Otherwise we would have had problems with the 
FCC closing time.

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: mac80211: AQM and block_tx

[Toke Høiland-Jørgensen]

Sven Eckelmann <sven.eckelmann@openmesh.com> writes:

> On Donnerstag, 5. Juli 2018 10:47:11 CEST Sven Eckelmann wrote:
>> Hi Toke,
>> 
>> we are currently testing DFS with ath10k and noticed that AQM seems to ignore 
>> cfg80211_csa_settings->block_tx. Problem is now that the channel switch is 
>> started on a detected radar
>> 
>>   echo 1 >/sys/kernel/debug/ieee80211/phy1/ath10k/dfs_simulate_radar
>> 
>> NL80211_ATTR_CH_SWITCH_BLOCK_TX is set for the channel switch by hostapd but 
>> the AP still sends QoS data to the client.
>> 
>> Was there a fix for such a problem which I might have missed? I've just worked 
>> around that by setting wake_tx_queue TO NULL in ath10k. This still must be 
>> verified but at least I didn't see any packets anymore on a monitor interface.
>
>
> Just as information, the ath10k Dakota devices went through DFS
> certification

Cool! (I think? Not quite sure what the implications of passing / not
passing certification are?)

> but the AQM had to be disabled. Otherwise we would have had problems
> with the FCC closing time.

Hmm, too bad; but I guess this can be fixed :)

-Toke

Re: mac80211: AQM and block_tx

[Manikanta Pubbisetty]

On 7/10/2018 12:25 PM, Sven Eckelmann wrote:
> On Donnerstag, 5. Juli 2018 10:47:11 CEST Sven Eckelmann wrote:
>> Hi Toke,
>>
>> we are currently testing DFS with ath10k and noticed that AQM seems to ignore
>> cfg80211_csa_settings->block_tx. Problem is now that the channel switch is
>> started on a detected radar
>>
>>    echo 1 >/sys/kernel/debug/ieee80211/phy1/ath10k/dfs_simulate_radar
>>
>> NL80211_ATTR_CH_SWITCH_BLOCK_TX is set for the channel switch by hostapd but
>> the AP still sends QoS data to the client.
>>
>> Was there a fix for such a problem which I might have missed? I've just worked
>> around that by setting wake_tx_queue TO NULL in ath10k. This still must be
>> verified but at least I didn't see any packets anymore on a monitor interface.
>
> Just as information, the ath10k Dakota devices went through DFS certification
> but the AQM had to be disabled. Otherwise we would have had problems with the
> FCC closing time.

I am working on a patch which takes care of stopping the iTXQs after 
detecting a radar(covering other scenarios where stopping iTXQs is 
important)
and there by making sure packets are not transmitted.

The patch is still under discussion but it's worth trying the patch 
given below and see if it fixes the DFS channel closing time issue; you 
need not disable AQM while trying this patch.
https://patchwork.kernel.org/patch/10516887/

-Manikanta

Re: mac80211: AQM and block_tx

[Sven Eckelmann]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

On Dienstag, 10. Juli 2018 18:09:37 CEST Manikanta Pubbisetty wrote:
[...]
> I am working on a patch which takes care of stopping the iTXQs after 
> detecting a radar(covering other scenarios where stopping iTXQs is 
> important)
> and there by making sure packets are not transmitted.
[...]
> https://patchwork.kernel.org/patch/10516887/

Thanks for telling me about this patch. It indeed prevents the unwanted TX 
during CSA (and thanks for the explanation in the commit message about the 
underlying problem).

Kind regards,
	Sven

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]