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
