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
From: Matthias May <hidden> Date: 2021-10-12 07:30:33
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
Hi Matthias,
Thanks for your fast and detailed answer.
Could imagine my goal is something not allowed, or at least not the
standard way. However, I still wonder what other devices do for
achieving connection. Thought that this is just a limitation of the
ath9k, but maybe they do something like you suggest.
From your hints, I'd look into:
[*] wonder why probing on DFS channels would be illegal?
My understanding was that this is prohibited only if there was no
beacon received from the AP before.
But if the client receives a beacon from the AP (no matter if it
contains a SSID or not) this shows that the channel is "clear" from
any radar signal, and that the client is allowed to send.
Is my understanding wrong?
[**] would inspect the passive scanning code of ath9k, to see what my
possibilities are to implement the above. Could you indicate some code
to look into? I could not find it easily. Eventually, is some layer
above ath9k also influencing the passive scanning?
Regards,
Koppany
On Tue, Oct 12, 2021 at 10:30 AM Matthias May [off-list ref] wrote:
On 10/11/21 12:46 PM, Máthé Koppány wrote:
quoted
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
From: Matthias May <hidden> Date: 2021-10-13 20:33:04
On 13/10/2021 15:50, Máthé Koppány wrote:
Hi Matthias,
Thanks for your fast and detailed answer.
Could imagine my goal is something not allowed, or at least not the
standard way. However, I still wonder what other devices do for
achieving connection. Thought that this is just a limitation of the
ath9k, but maybe they do something like you suggest.
From your hints, I'd look into:
[*] wonder why probing on DFS channels would be illegal?
My understanding was that this is prohibited only if there was no
beacon received from the AP before.
But if the client receives a beacon from the AP (no matter if it
contains a SSID or not) this shows that the channel is "clear" from
any radar signal, and that the client is allowed to send.
Is my understanding wrong?
[**] would inspect the passive scanning code of ath9k, to see what my
possibilities are to implement the above. Could you indicate some code
to look into? I could not find it easily. Eventually, is some layer
above ath9k also influencing the passive scanning?
Regards,
Koppany
On Tue, Oct 12, 2021 at 10:30 AM Matthias May [off-list ref] wrote:
quoted
On 10/11/21 12:46 PM, Máthé Koppány wrote:
quoted
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
4.2.6.1.4 DFS operation
Slave devices:
a) A slave device shall not transmit before receiving an appropriate enabling signal from an associated master device.
Simply receiving beacons is not enough.
You have to be *associated* to a master device (AP) to be allowed to probe actively.
We implemented option 2 (custom beacon IE) for our devices, because we control both sides of the connection.
This doesn't work with 3rd party devices, but that is not an issue for us. Anyone with a sniffer can see the custom
SSID, we use it mostly to reduce the number of random mobile phones from connecting. It's not a feature that provides
any security whatsoever anyway, but more for convenience.
As to why some of the newer devices are able to connect:
IMO they they either perform radar detection, or are illegal.
Performing radar detection as a slave device has the downside, that if you detect radar, this frequency is blocked for
the NOP time (30 minutes), even if there are other master devices that would tell you otherwise.
BR
Matthias