Search Linux Wireless

Re: [PATCH 2/2] ath10k: mac: enable WIPHY_FLAG_CHANNEL_CHANGE_ON_BEACON on ath10k

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/13/2023 10:20 PM, Kalle Valo wrote:
Kalle Valo <kvalo@xxxxxxxxxx> writes:

Abhishek Kumar <kuabhs@xxxxxxxxxxxx> wrote:

Enabling this flag, ensures that reg_call_notifier is called
on beacon hints from handle_reg_beacon in cfg80211. This call
propagates the channel property changes to ath10k driver, thus
changing the channel property from passive scan to active scan
based on beacon hints.
Once the channels are rightly changed from passive to active,the
connection to hidden SSID does not fail.

Signed-off-by: Abhishek Kumar <kuabhs@xxxxxxxxxxxx>

There's no Tested-on tag, on which hardware/firmware did you test this?

This flag is now enabled on ALL ath10k supported hardware: SNOC, PCI, SDIO and
maybe soon USB. I'm just wondering can we trust that this doesn't break
anything.

Jeff, what are your thoughts on this? I'm worried how different ath10k
firmwares can be and if this breaks something.


Since the 1/2 patch is already in pull-request: wireless-next-2023-10-06 I went through the logic of that again. It would have been nice if that actually described how it fixes the problem. What actually causes a channel to change from passive to active?

Note the existing logic prior to the 1/2 patch already updates the wiphy and userspace with the updated channel flags, so it seems reasonable to also update the driver

However, this led me down the rabbit hole of trying to figure out what happens if a beacon hint causes us to change a channel from passive to active, but then that AP goes away. What, if anything, causes the channel to revert back to passive? I'm not immediately seeing that logic anywhere.

My concern is that we have an AP with a hidden SSID on a DFS channel, and as a result of a beacon hint we switch that channel to active scan. But then later that AP detects radar and vacates the channel. Then we potentially have stations doing active scan on a DFS channel with an active radar.

Hopefully this is all handled, and it just isn't obvious in my admittedly very quick 10 minute scan of the code.

And as far as the 2/2 patch, note this logic is all dependent upon reg_is_world_roaming(wiphy) returning true, so ath10k impact would really depend upon the board regulatory settings, whether configured for a fixed regulatory domain/country code or configured for world roaming.

/jeff





[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux