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
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
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
Sven Eckelmann <[email protected]> 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
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