A DAB/Internet radio (made by Karcher in Germany) broadcasts an SSID (details). It cannot be disabled and neither the SSID nor the MAC address can be changed.
Can someone explain why this is necessary?
Almost certainly leftover reference-firmware laziness, not an actual requirement. A lot of cheap WiFi-radio modules ship with a default setup-AP mode meant for initial onboarding via a companion app, and a lot of OEMs never gate it behind a real first-boot-only flag, so it just stays broadcasting forever.
Since you can’t disable it or change the MAC, containment beats fixing it: block that MAC at your AP/controller so it can’t associate with anything, or isolate it if your AP supports MAC-based assignment. Doesn’t stop it broadcasting, but stops it being useful to anything nearby.
Doesn’t stop it broadcasting, but stops it being useful to anything nearby.
Any SSID broadcast is useful to Google and Apple spies (read: simple phone patrons) who feed the SSID to the mothership which is then used for mapping. There are security risks by that alone even if it’s blocked from my LAN, which I detail in these threads:
Apart from tracking my residency, I boycott both Google and Apple, so I object to feeding them in the slightest even when it’s innocuous to me. The map data enhances their location products and feeds their advertising surviellance machines.
Anyway, I appreciate your insight. I assumed it was a proactive act by Karcher and would not have thought that they were naive or lazy w.r.t. something baked-in upstream from them.
Usually for initial setup. Many applicances will have your phone join that network to apply the permanent wifi details.
The fact that it would continue to may just be shoddy design.
So IIUC, you’re saying it’s for a phone to configure the appliance? The reason being that the appliance’s UI is not convenient enough, I presume?
In the case at hand, the Karcher DAB radio has no iOS or AOS app. So AFAICT it would only be feasible if the radio also had a built-in web server and a captive portal. But I get no captive portal when connecting.
I suppose another theory is that if the radio has a cloud uplink, perhaps it would then push a captive portal to redirect to a centralised server which then remotely configures the device. I would not trust it enough to give it an uplink so I can’t test this theory.
It doesn’t need an app to set up over Wi-Fi, that’s one advantage of this technique. It works like this:
- Device acts as access point: either open, WPS or showing the password/QR code on screen
- Connect phone (or computer etc. with browser) to the access point
- The phone will try to connect to a known domain (for example http://connectivitycheck.gstatic.com/ on stock Android) to determine if the AP has Internet access. If this doesn’t work, go to an HTTP-only site: http://neverssl.com/
- The device will hijack the unencrypted HTTP request and redirect to http://192.168.1.1/setup.html or whatever (this will be detected by the phone as “captive portal” and you get a “Sign in to Wi-Fi network” notification (the phone believes it may then access the internet because some Wi-Fi hotspots do this)
- You input your home network’s credentials into the webpage so you don’t have to dial them in with the volume knob and tiny buttons
- The device disables its setup hotspot (if only one Wi-Fi radio is available) and tries to connect to the provided network (usually there’s a timeout so the process restarts on failure)
This is very common, I made an ESP32 device whose setup works like this. If you need to make an open Wi-Fi network for whatever reason, you can name it “HP Deskjet Pro 4800” and it’s very unlikely someone searching for public Wi-Fi will try to connect
Ummm… does it? It depends on Wi-Fi for operation, so why would it have another Wi-Fi radio to relay the signal? Other than initial setup of course.
