Search Linux Wireless

Re: ath9k: unable to connect to hidden SSID on DFS channel

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

 



On 10/11/21 12:46 PM, Máthé Koppány wrote:
> Hello,
> 
> I have a project where I want to establish Wi-Fi connection to a
> hidden SSID, on DFS channel.
> 
> I am running wpa_supplicant 2.9 on a device with:
> "Linux 4.9.51-yocto-standard armv7l" and
> "Network controller: Qualcomm Atheros AR958x 802.11abgn Wireless
> Network Adapter (rev 01)"
> 
> Sounds an old project, I know, but want to bring this alive, if
> possible. Unfortunately, connection to a hidden SSID on DFS channel
> seems not working.
> 
> However, it works on a different, newer device, which has
> "Linux raspberrypi 5.10.17-v7l+ armv7l" and
> "PCI bridge: Broadcom Limited Device 2711 (rev 10)".
> 
> The wpa_supplicant on the two devices is mostly idem: same v2.9, same
> runtime configuration, almost all config variables (wpa_cli dump)
> match (not seen relevant difference). There might be compile option
> difference, but don't think they are relevant.
> The only thing I see is with driver flags, where the newer device
> supports flags like DFS_OFFLOAD, BSS_SELECTION, or
> 4WWAY_HANDSHAKE_PSK, but the older device does not offer these.
> 
> So I suspect the issue is due to some of the above missing features in
> my ath9k driver (have default driver provided by kernel).
> 
> Questions:
> - is it possible to enable the above driver flags/features for ath9k?
> If so, how to enable and are there patches for these?
> - any hint where to look in ath9k driver for passive scanning
> implementation? Is there another module/location where passive
> scanning is implemented?
> - any suggestions for a solution to my issue?
> 
> Thanks,
> Koppany
> 

Hi

Clients not being able to find hidden APs on DFS frequencies is not a bug, but by design.

Facts:
* When enabling hidden SSID on an AP, the SSID is not sent in the beacons.
* Clients (non-master devices) are not allowed to transmit on a DFS frequency unless an AP (master device) tells them it
is ok.

This means that a client can find new APs only by scanning passively.
Since the beacons do not contain the SSID, the client will never find the AP it is looking for.

Some ways around:
* Your client is a master and does radar detection (with all its downsides), thus it is allowed to probe actively
* You hack your beacons and add a custom SSID which allows the client to get the SSID passively (hack both sides)
* Your device behaves illegal and sends probe requests on DFS frequencies
* ???

BR
Matthias

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


[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