Squeezebox Radio - any way to set WiFi BSSID? ( Maybe related to instabilities? )

[stsichler]

On the Radio, is it possible to bind to a specific WLAN not only by SSID, but also by BSSID?

Background of my question:
Since some days I'm debugging WLAN instabilities of one of my RasPi3 running RasPi OS (based on bookworm).
It took me a while to find out that the Network Manager sometimes tries to connect to the wrong WiFi network, thereby of course failing each time.
But each time, this increases a "fail count" which it associates with the name/SSID of my Router WiFi (which is the correct WiFi). This, after some random time, finally causes the Network Manager to stop any further connection attempts to my Router WiFi.

Deeper looking into the problem revealed that the Network Manager messes up my WiFi with a Wifi nearby having a hidden SSID.
As far as I can see, the WiFi with hidden SSID sends out a (presumably bogus) SSID of \0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00.

I don't know why the Network Manager messes up this Wifi with my Router Wifi having a real Name / SSID, but I was ultimately able to fix this problem by connecting by BSSID/SSID combination instead of only SSID!

Today, I realized that by Radio also lost connection to the WiFi of my router again, so maybe it has similar reasons???

[stsichler]

Okay, I found out myself how to add a BSSID to the /etc/wpa_supplcant.conf. It looks like this now:

ctrl_interface=/var/run/wpa_supplicant
update_config=1

network={
    ssid="SolarSystem"
    bssid=3C:84:6A:AA:35:3D
    scan_ssid=1
    psk="*********"
    proto=RSN
    key_mgmt=WPA-PSK
}

Very surprisingly, I actually see the behavior that I suspected before in the log:

Oct  9 16:57:59 udhcpc[784]: Sending discover...
Oct  9 16:58:01 kernel: [   23.691183] channel hint set to 2422
Oct  9 16:58:01 kernel: [   23.703619] AR6000 disconnected
Oct  9 16:58:01 kernel: [   23.754389] AR6000 connected event on freq 2422 with bssid a0:b1:be:10:59:2f  listenInterval=1000, beaconInterval = 100, beaconIeLen = 26 assocReqLen=45 assocRespLen =22
Oct  9 16:58:01 kernel: [   23.769664] Network: Infrastructure
Oct  9 16:58:01 kernel: [   23.791957] AR6000 disconnected from a0:b1:be:10:59:2f 
Oct  9 16:58:01 kernel: [   23.851857] AR6000 WMI - setting BSS filter to 'all' (1 - all beacons forwarded) - and ieMask to 0
Oct  9 16:58:01 root: wpa_action eth1 DISCONNECTED
Oct  9 16:58:01 kernel: [   23.902212] channel hint set to 2422
Oct  9 16:58:01 kernel: [   23.925334] AR6000 disconnected
Oct  9 16:58:01 kernel: [   23.994555] AR6000 connected event on freq 2422 with bssid 3c:84:6a:aa:35:3d  listenInterval=1000, beaconInterval = 100, beaconIeLen = 22 assocReqLen=64 assocRespLen =104
Oct  9 16:58:01 kernel: [   24.009912] Network: Infrastructure
Oct  9 16:58:01 root: wpa_action eth1 CONNECTED

The Wifi with BSSID a0:b1:be:10:59:2f is the bogus WiFi, whereas the 3c:84:6a:aa:35:3d is my Router WiFi "SolarSystem".
So the AR6000 really seems to try to connect to the wrong WiFi in the first place!!!! Wow!

(Note that unfortunately, the bogus WiFi with invalid/hidden BSSID is on the same channel as my WiFi)

[mw9]

Deeper looking into the problem revealed that the Network Manager messes up my WiFi with a Wifi nearby having a hidden SSID. As far as I can see, the WiFi with hidden SSID sends out a (presumably bogus) SSID of \0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00\0x00.

Not bogus. A hidden SSID.

Presumably bssid a0:b1:be:10:59:2f is the AP in question. Perhaps it emanates from your router in response to the Radio's probe request ?

scan_ssid=1 is relevant. See this change:

ralph-irving/squeezeos-squeezeplay@ff096b2

I'm not sure of the details of how this all works, though.

[mw9]

Not bogus. A hidden SSID.

I may have misunderstood you.

Are you thinking that you may have an Evil Neighbour attempting to masquerade as your own AP ?

Setting scan_ssid=0 will prevent SSID specific directed probe requests from being sent out. So you rely on your AP advertisement beacons including the SSID to be able to discover it. Perhaps that will help, perhaps it won’t.

I think that setting bssid=3C:84:6A:AA:35:3D constrains usage of that network section to this specific BSSID. So no way it could have authenticated to bssid a0:b1:be:10:59:2f.

Does iwlist eth1 scanning throw any light on what’s in the air ?

Turn off all your wireless devices, and try it again. Maybe you will see something.

[stsichler]

In fact, I recently got to know exactly where the bogus WiFi comes from: It's a device that I bought some weeks ago, an Aquarium LED Controller, based on an ESP8266.
The controller is in a combined STA/AP Mode (which I didn't know before), with its STA linked up to my Router WiFi (3C:84:6A:AA:35:3D), but simultaneously providing its own AP WiFi (a0:b1:be:10:59:2f) with hidden SSID on the same channel.

I suspect that the ESP8266 / controller firmware does some weird things with the SSID of its AP.
What completely puzzles me:

My Laptop, my RasPi3 and my Router itself list that WiFi with SSID all zeros:

> iw wlan0 scan
BSS a0:b1:be:10:59:2f(on phy1-ap0)
	TSF: 306646630963 usec (3d, 13:10:46)
	freq: 2422
	beacon interval: 100 TUs
	capability: ESS (0x0011)
	signal: -38.00 dBm
	last seen: 810 ms ago
	SSID: \x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
	RSN:	 * Version: 1
		 * Group cipher: TKIP
		 * Pairwise ciphers: CCMP TKIP
		 * Authentication suites: PSK
		 * Capabilities: 1-PTKSA-RC 1-GTKSA-RC (0x0000)

whereas the Squeezebox Radio lists it as "SolarSystem", which is the SSID of my Router AP WiFi (with 3C:84:6A:AA:35:3D) !

> iwlist eth1 scanning
          Cell 03 - Address: A0:B1:BE:10:59:2F
                    ESSID:"SolarSystem"
                    Mode:Master
                    Frequency:2.422 GHz (Channel 3)
                    Quality=42/94  Signal level=-53 dBm  Noise level=-95 dBm
                    Encryption key:on
                    Bit Rates:5.5 Mb/s; 11 Mb/s; 1 Mb/s; 2 Mb/s; 6 Mb/s
                              12 Mb/s; 24 Mb/s; 48 Mb/s; 54 Mb/s; 9 Mb/s
                              18 Mb/s; 36 Mb/s
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (2) : CCMP TKIP
                        Authentication Suites (1) : PSK
                    Protocol:IEEE 802.11g
                    Extra:bcn_int=100

I find it very interesting that this WiFi causes the SB Radio to eventually drop out of my router's WiFi, because maybe we have similar situations in other areas with high WiFi density, perhaps explaining one or the other sudden mysterious loss of Wifi connection of the SB Radio.

Btw. I also already contacted the developer of the Aquarium LED Controller and told him that I believe that the AP WiFi of his device seems to do some weird things...

[mw9]

Sounds like it might be trying to act as a WiFi extender, because it using your AP’s SSID. But just a wild speculation. And doesn’t make much sense, really.

I imagine that it responded to a directed probe request from the Radio (I.e. the Radio’s probe includes the SSID it is looking for). Whereas the scan results on your laptop etc. are (likely) just passive scans, and the device seems to have been configured to hide its SSID.

Try scan_ssid=0 to test that hypothesis. The Radio should, then, just do passive scans. (I think).

Or start actually capturing and deciphering on-air packets to see what is really going on. 😊

Thus far, I am not convinced that this is a Radio WiFi problem. It will be interesting to see what you learn. Defects in the Aquarium device firmware ? Surely not !

[stsichler]

Defects in the Aquarium device firmware ? Surely not !

Oh yes, I'm sure that this is actually a defect in the Aquarium device firmware in the first place, because, as I initially wrote, I was initially pointed to this problem by my RasPi3 that is randomly losing connection to my Router Wifi, because it also accidentally tries to connect to this bogus WiFi.
The only way of stopping him to do so is specifying the BSSID in addition to the SSID in the Network Settings.

[stsichler]

Hm. My Radio again disconnected from the Router WiFi. :-/

Looking through the Kernel logs, it is flooded with these lines:

[65316.761583] AR6000 connected event on freq 2422 with bssid a0:b1:be:10:59:2f  listenInterval=1000, beaconInterval = 100, beaconIeLen = 26 assocReqLen=45 assocRespLen =22
[65316.776872] Network: Infrastructure
[65316.818784] AR6000 disconnected from a0:b1:be:10:59:2f 
[65316.848471] AR6000 WMI - setting BSS filter to 'all' (1 - all beacons forwarded) - and ieMask to 0
[65326.849055] AR6000 disconnected
[65326.976765] AR6000 WMI - setting BSS filter to 'all' (1 - all beacons forwarded) - and ieMask to 0
[65327.327948] channel hint set to 2422
[65327.345526] AR6000 disconnected

So, it still repeatedly connects to the wrong WiFi, although my wpa_supplicant config lists bssid=3c:84:6a:aa:35:3d.
What does this repeated WMI - setting BSS filter to 'all' message mean?

EDIT: The "Enable all BSS filters" Option in Wifi Robostness Menu is off. (fw 9.0.1 r17050)

[stsichler]

Try scan_ssid=0 to test that hypothesis. The Radio should, then, just do passive scans. (I think).

Setting scan_ssid=0 in /etc/wpa_supplicant.conf seems to neither prevent connection to the bogus WiFi nor changes anything in WiFi Scanning process by iwlist eth1 scanning. Still the same results.

[mw9]

OK, we’re beyond my knowledge level. Wi-Fi connection set up can be “quite complex” if one doesn’t know the intricacies, and I don’t know enough of them to make any informed diagnosis about what’s going on. I’d probably want to look at the traffic in detail to point me in the right direction.

However we do know that your RasPi3 also has difficulties with this device, so this not obviously a “Squeezebox Radio only” problem.

To be honest, from what you say, I’m not sure that I would want this device in any way active in my vicinity right now. What is it doing ? Might it be up to no good ? Who is it talking to ? I may be over-cautious, perhaps there is an innocent and obvious explanation. I simply don’t know.

[mw9]

What does this repeated WMI - setting BSS filter to 'all' message mean?

EDIT: The "Enable all BSS filters" Option in Wifi Robostness Menu is off. (fw 9.0.1 r17050)

Nothing, really, other than it shows us what wpa-supplicant is actually doing, and shows why the “Enable all BSS filters” Option is probably pretty much useless. 😊

The message will be quietened down in the next CF release.

[stsichler]

To be honest, from what you say, I’m not sure that I would want this device in any way active in my vicinity right now. What is it doing ? Might it be up to no good ? Who is it talking to ? I may be over-cautious, perhaps there is an innocent and obvious explanation. I simply don’t know.

I'm in contact with the Aquarium device developer already. It's really just a bug related to the ESP8266 WiFi API, so I have no security concerns.

For the RasPi3, the problem can be solved by binding WiFi to my Routers BSSID, but for the Squeezebox Radio, this seems not to work.
I still see connection attempts of the Radio to the bogus WiFi, although I added bssid=3c:84:6a:aa:35:3d in the wpa_suuplicant.conf.

This is what actually puzzles me and that is the reason for me opening this issue here.

[mw9]

For the RasPi3, the problem can be solved by binding WiFi to my Routers BSSID, but for the Squeezebox Radio, this seems not to work. I still see connection attempts of the Radio to the bogus WiFi, although I added bssid=3c:84:6a:aa:35:3d in the wpa_suuplicant.conf.

This is what actually puzzles me and that is the reason for me opening this issue here.

I think to answer that,one must know the sequence of WiFi events that have actually taken place on each system. What one might see in the Radio's log and what one might see in the RasPi3's log do not tell us that in detail, and perhaps they just log stuff differently.

The phrase "This seems not to work" is, perhaps, carrying some, perhaps not quite right, assumptions and interpretations about what actually happens under the hood. Did I understand correctly that the Radio did associate with the correct AP ? Perhaps something has worked as it should ?

I do not know the full sequence of WiFi events, nor the intricacies/details of how wpa_supplicant, the AR6000 driver, and the RasPi3 driver work, or what they choose to log. I won't speculate further. 😄

Good luck !

[stsichler]

What does this repeated WMI - setting BSS filter to 'all' message mean?
EDIT: The "Enable all BSS filters" Option in Wifi Robostness Menu is off. (fw 9.0.1 r17050)

Nothing, really, other than it shows us what wpa-supplicant is actually doing, and shows why the “Enable all BSS filters” Option is probably pretty much useless. 😊

Note that a call to /lib/atheros/wmiconfig -i eth1 --filter=none results in the message

AR6000 WMI - setting BSS filter to 'none' (0 - no beacons forwarded) - and ieMask to 0

So, I think that --filter=all is the default and the /etc/init.d/wlan needs adaption.

EDIT: also iwlist eth1 scanning resets it to --filter=all.

[mw9]

So, I think that --filter=all is the default and the /etc/init.d/wlan needs adaption.

EDIT: also iwlist eth1 scanning resets it to --filter=all.

I think one would need to trawl back through various forum posts/findings to know why this particular wlan adaptation may have been found to be helpful to some users.

I forget what the firmware start up default actually is. Perhaps one might find out by loading the driver without actually starting wpa_supplicant.

But, as you will have noticed, any such setting in wlan is of very short duration, as the normal probing, etc., activity swiftly resets it to all. It’s been a while since I looked.

There was, once, an older version of the ar6000.ko driver (found out in the wild) that actually seems to “honour” such a setting. I’ve parked it to one side for now, it might become useful one day.

[stsichler]

Setting scan_ssid=0 will prevent SSID specific directed probe requests from being sent out. So you rely on your AP advertisement beacons including the SSID to be able to discover it. Perhaps that will help, perhaps it won’t.

I think that setting bssid=3C:84:6A:AA:35:3D constrains usage of that network section to this specific BSSID. So no way it could have authenticated to bssid a0:b1:be:10:59:2f.

Does iwlist eth1 scanning throw any light on what’s in the air ?

Some news here:

> iwlist eth1 scanning with parameter last shows the scan results of the last automatic background scan meanwhile WiFi is connected.
Previously calling > /lib/atheros/wmiconfig -i eth1 --scan --scanctrlflags 1 1 0 1 1 1 disables active scan.

With this configuration, the scan results suddenly list the bogus WiFi without SSID:

(...)
          Cell 07 - Address: A0:B1:BE:10:59:2F
                    ESSID:""
                    Mode:Master
                    Frequency:2.422 GHz (Channel 3)
                    Quality=39/94  Signal level=-56 dBm  Noise level=-95 dBm
                    Encryption key:on
                    Bit Rates:5.5 Mb/s; 11 Mb/s; 1 Mb/s; 2 Mb/s; 6 Mb/s
                              12 Mb/s; 24 Mb/s; 48 Mb/s; 54 Mb/s; 9 Mb/s
                              18 Mb/s; 36 Mb/s
                    IE: IEEE 802.11i/WPA2 Version 1
                        Group Cipher : TKIP
                        Pairwise Ciphers (2) : CCMP TKIP
                        Authentication Suites (1) : PSK
                    Protocol:IEEE 802.11g
                    Extra:bcn_int=100
(...)

So, I think, the Aquarium Device erroneously reacts on probe requests of my Router's SSID "SolarSystem", as suspected by you, @mw9.
This is possible, because that SSID name is configured in its Network Stack for its STA mode WiFi and seems to be mixed up by the firmware somehow with its AP mode Wifi.

This explains why the Radio is randomly connecting to that bogus Wifi, eventually leading to a complete loss of WiFi connection, after some presumably internal connection error counts have reached some limit.