Spontaneous locale change on Bookworm

The disconnect repeated after about an hour. No further references to rfkill, but the boot messages grumble about NetworkManager....

bob@raspberrypi:~$ systemctl status NetworkManager-wait-online.service × NetworkManager-wait-online.service - Network Manager Wait Online Loaded: loaded (/lib/systemd/system/NetworkManager-wait-online.service; en>

Active: failed (Result: exit-code) since Sat 2024-09-21 09:52:43 PDT; 7min>

Docs: man:nm-online(1) Process: 866 ExecStart=/usr/bin/nm-online -s -q (code=exited, status=1/FAIL>

Main PID: 866 (code=exited, status=1/FAILURE) CPU: 33ms

It unclear to me if this is even relevant to the disconnect event, since at the moment wifi is connected and working.

Anybody got a suggestion? apt update reports all up to date....

Thanks for reading

bob prohaska

Well it may be completely irrelevant Bob, but my Pi Zero 2 W issues seem to have been solved by use of a bigger power supply. It may be that the wifi chip is the most sensitive to inadequate voltages.

The wifi dropout has repeated three or four times since the initial case. Usually it dropped after an hour or so of uptime and couldn't reconnect on its own, the Pi had to be rebooted. Haven't seen anything more about rfkill after the first incident. I put a voltmeter on the GPIO power pins, it looks steady at 5.09-5.10 volts. The meter isn't what I'd call a precision unit, but it's likely within 50 mV, so the voltage isn't obviously wrong.

Just a few minutes ago the WiFi dropped, then came back up on its own a couple or three minutes later. Wasn't watching the voltmeter, unfortunately. I'll keep an eye peeled more carefully, perhaps it can be caught in the act.

Thanks for writing,

bob prohaska

I would look for more detailed error messages from NetWorkManager with journalctl. It’s having trouble with something, you need to find out what.

It certainly is voltage sensitive on the RPi Pico W, although there I'm comparing 5V power with 3.7V.

David

Mmm. if you have a scope, also check for noise.

That is the sort of behaviour an 'on the edge' wifi subsystem displays.

My router has 'connection time' and 'reconnection time' set to 1 hour and 1 day.

I think that after the reconnection time is up, it wants a re-send of the secret keys.

That is, you will, by design, get disconnected every so often,. The issue is whether the reconnect succeeds.

Low voltage and/or local noise seem to be issues for the wifi chips in use.

I do have a 'scope, but learned something new in the meantime.

Overnight the connection dropped and would not reconnect. Watching wavemon showed cyclic behavior, trying 5 GHz, then 2.4 GHz, then giving up over several attempts. Opening the "edit connection" settings showed device to be blank. When I set it to wlan0 and hit "save" the connection immediately came up.

Wlan0 is the only possibility on this Pi: there's no cable conneted, so how the device setting could matter, if in fact it did, is unclear.

There are quite a few competing access points in the neighborhood, but mine is still the closest and, usually, the strongest. However, it's limited to 2.4 GHz only. Wavemon shows considerable time spent trying to establish a 5 GHz connecting before falling back to 2.4. Perhaps this is some kind of negotiating failure. I'm using a preset ssid with password, so there's no question of which AP to negotiate with. I haven't set DHCP to use a reserved MAC address simply because the Pi generally gets the same address anyway and I seldom run any services on this Pi that require access from the LAN.

Is there some way to force the Pi to not bother attempting a 5 GHz connection?

Thanks for reading,

bob prohaska

If I'm reading the man page correctly, the "failure" in NetworkManager is very likely that the network isn't coming up.

It must be admitted that systemctl's man page is somewhat opaque 8-)

Thanks for writing!

bob prohaska

Don’t guess. Check.

Not that I know of. I use different SSIDs for my 2.4 and 5 GHz WiFi, to be able to select the one I want for each device.

Where 5 GHz is marginal I also include the 2.4 GHz SSID in the wpa_supplicant.conf with a lower priority, so it will fail over to that.

---druck

Just rebooted, with the network device in Network Connections >

preconfigured > Device set to wlan0. Networking came up immediately, bob@raspberrypi:~$ systemctl status NetworkManager-wait-online.service ● NetworkManager-wait-online.service - Network Manager Wait Online Loaded: loaded (/lib/systemd/system/NetworkManager-wait-online.service; enabled; preset: enabled) Active: active (exited) since Mon 2024-09-23 09:12:57 PDT; 7min ago Docs: man:nm-online(1) Process: 858 ExecStart=/usr/bin/nm-online -s -q (code=exited, status=0/SUCCESS) Main PID: 858 (code=exited, status=0/SUCCESS) CPU: 27ms

Sep 23 09:12:49 raspberrypi systemd[1]: Starting NetworkManager-wait-online.service - Network Manager Wait Online... Sep 23 09:12:57 raspberrypi systemd[1]: Finished NetworkManager-wait-online.service - Network Manager Wait Online. bob@raspberrypi:~$

It's very hard to understand how explicitly setting wlan0 as the active interface could matter when that's the only interface with connectivity. But, for the moment, the visible problem is gone.

It should be said that I've had intermittent problems with WiFi for some time now. For a while it seemed to be interference-like, varying seemingly by time of day. After an update to Bookworm a couple weeks ago reported signal strength went up, (~80% to ~90%) but that didn't prevent disconnect problems. Now the disconnect issue seems to have abated.

Why is still unclear.

Thanks for writing!

bob prohaska

You didn’t check the logs with journalctl, as I suggested?

Lawrence D'Oliveiro snipped-for-privacy@nz.invalid wrote:

I don't know what to look for.

The problem seemed solved by explicitly requiring wlan0 in Network > Advanced Options > preconfigured > Device.

At your prompting I did run journalctl | grep -i wlan0 | grep -i failed which yielded a repeating pattern of messages ending with:

Sep 22 09:30:54 raspberrypi wpa_supplicant[823]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="d-link.zefox.net" auth_failures=1 duration=10 reason=CONN_FAILED Sep 22 09:31:11 raspberrypi wpa_supplicant[823]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="d-link.zefox.net" auth_failures=2 duration=20 reason=CONN_FAILED Sep 22 09:31:27 raspberrypi wpa_supplicant[823]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="d-link.zefox.net" auth_failures=1 duration=10 reason=CONN_FAILED Sep 22 09:31:44 raspberrypi wpa_supplicant[823]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="d-link.zefox.net" auth_failures=2 duration=20 reason=CONN_FAILED Sep 22 09:31:45 raspberrypi wpa_supplicant[823]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="d-link.zefox.net" auth_failures=1 duration=10 reason=CONN_FAILED Sep 22 09:32:02 raspberrypi wpa_supplicant[823]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="d-link.zefox.net" auth_failures=2 duration=20 reason=CONN_FAILED Sep 22 09:32:10 raspberrypi NetworkManager[821]: <info> [1727022730.2605] device (wlan0): state change: config -> failed (reason 'no-secrets', sys-iface-state: 'managed') Sep 22 09:32:10 raspberrypi NetworkManager[821]: <warn> [1727022730.2612] device (wlan0): Activation: failed for connection 'preconfigured' Sep 22 09:32:10 raspberrypi NetworkManager[821]: <info> [1727022730.2614] device (wlan0): state change: failed -> disconnected (reason 'none', sys-iface-state: 'managed') as the last block of text. No errors after roughly the time I changed the network settings to add Device wlan0, which was done mid-morning on the 22nd, I think.

Running journalctl | grep -i wlan0 | grep -i success produced much output, ending with Sep 22 09:35:14 raspberrypi NetworkManager[821]: <info> [1727022914.3489] device (wlan0): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. Connected to wireless network "d-link.zefox.net" Sep 22 09:35:14 raspberrypi NetworkManager[821]: <info> [1727022914.5427] device (wlan0): Activation: successful, device activated. Sep 23 09:12:57 raspberrypi NetworkManager[819]: <info> [1727107977.4602] device (wlan0): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. Connected to wireless network "d-link.zefox.net" Sep 23 09:12:57 raspberrypi NetworkManager[819]: <info> [1727107977.6547] device (wlan0): Activation: successful, device activated.

The timestamp gap from Sep 22 to Sep 23 matches the pause before I made the Device wlan0 change.

This isn't very clever use of journalctl, admittedly, and I don't really understand what it's showing me now.

Running journalctl | grep -i wlan0 | grep -i supplicant-failed produces just three lines: Sep 21 07:36:41 raspberrypi NetworkManager[826]: <info> [1726929401.0115] device (p2p-dev-wlan0): state change: disconnected -> unavailable (reason 'supplicant-failed', sys-iface-state: 'managed') Sep 21 07:38:51 raspberrypi NetworkManager[826]: <info> [1726929531.4462] device (p2p-dev-wlan0): state change: disconnected -> unavailable (reason 'supplicant-failed', sys-iface-state: 'managed') Sep 22 08:05:07 raspberrypi NetworkManager[821]: <info> [1727017507.7245] device (p2p-dev-wlan0): state change: disconnected -> unavailable (reason 'supplicant-failed', sys-iface-state: 'managed')

If any of this makes sense please clue me in. Meanwhile wifi seems to work, so I can get back to wrestling with your TLS exercises.

Thanks for all your help!

bob prohaska

That’s the sort of idea, yes. Though note that journalctl has its own filtering options, to save you generating a whole lot of output most of which you might be throwing away with the grep (might make a difference to speed of output, that’s all).

These are certainly mysterious, particularly as you have success messages both earlier and later than this.

Just a wild guess, but could you have two different networks with SSID “d-link.zefox.net”, with different authentication info? So what you are seeing is failures connecting to one and successes with the other?

Lawrence D'Oliveiro snipped-for-privacy@nz.invalid wrote:

Physically I don't see how that's possible, unless there's another access point within range using the same SSID set up by somebody else. My router has no documented ability to use more than one SSID and has been in use for several years, long before the Bookworm setup.

Putting wavemon in scan mode shows something like: ┌─Scan window──────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ │ │d-link.zefox.net 00:13:46:86:6D:0C 93%, -45 dBm, ch 2, 2417 MHz ESS │ │millerhome2 F0:72:EA:49:C6:4A 63%, -66 dBm, ch 6, 2437 MHz ESS, Radio Measure │ │ATT5Zavd8s 08:9B:B9:01:B7:14 63%, -66 dBm, ch 6, 2437 MHz 7 sta, 16% chan, Radio Measure, Spectrum Mgmt │ │ATTKXEBVbA DC:8D:8A:5A:D6:D4 64%, -65 dBm, ch 6, 2437 MHz 17% chan, Radio Measure, Spectrum Mgmt │ │<hidden ESSID> 7C:9A:54:FC:7E:7A 73%, -59 dBm, ch 6, 2437 MHz ESS, Radio Measure, Spectrum Mgmt │ │<hidden ESSID> 7C:9A:54:FC:7E:7E 73%, -59 dBm, ch 6, 2437 MHz ESS, Radio Measure, Spectrum Mgmt │ │cross 7C:9A:54:FC:7E:79 73%, -59 dBm, ch 6, 2437 MHz ESS, Radio Measure, Spectrum Mgmt │ │<hidden ESSID> 7C:9A:54:FC:7E:7C 74%, -58 dBm, ch 6, 2437 MHz ESS, Radio Measure, Spectrum Mgmt │ │millerhome2 F0:72:EA:49:C6:4D 41%, -81 dBm, ch 149, 5745 MHz ESS, Radio Measure │ │Xfinity Mobile 7C:9A:54:FC:7E:85 40%, -82 dBm, ch 157, 5785 MHz 1% chan, Radio Measure, Spectrum Mgmt │ │<hidden ESSID> 7C:9A:54:FC:7E:84 50%, -75 dBm, ch 157, 5785 MHz ESS, Radio Measure, Spectrum Mgmt │ │cross 7C:9A:54:FC:7E:81 50%, -75 dBm, ch 157, 5785 MHz ESS, Radio Measure, Spectrum Mgmt │ │<hidden ESSID> 7C:9A:54:FC:7E:86 51%, -74 dBm, ch 157, 5785 MHz ESS, Radio Measure, Spectrum Mgmt │

These entries change every few scans, and I don't know what the hidden ESSID entries represent.

Thanks for writing, and any insights!

bob prohaska

Men In Black outside your door in black Crown Vic cars?

Doubtful 8-)

A quick web search suggests it's some sort of deprecated security protocol. If wavemon can see them they aren't very well hidden. I suppose it would require an interloper to correctly guess both the SSID and the password. That's certainly harder than just guessing a password.

Still, for a long time (months) there's been a consistent pattern of my wifi getting flaky in the evening and then returning to "normal" the next day. That strongly suggested some kind of adjacent channel inteference when neighbors came home from work and started using their own wifi.

Seems to me it got better after going to Bookworm for a while, then after an upgrade it got much worse. The moment I set the network device to wifi explitly the connection came up and stayed up.

Having a single network device specified would skip any searching algorithms used to find a usable access point. If the search routine had some difficulty, that might explain at least part of the problem and the unexpected "solution".

Thanks for writing,

bob prohaska

Yes, throw away everything you've ever learnt on Linux, and bow to the will of Poettering.

Replies to /dev/null (or should that be SystemD:NULL) please.

---druck

Possibly, but could be things like Amazon Firesticks. I got quite concerned when a couple of hidden ESSIDs with fairly high strength on the channel I was using followed me around when I switched channels on the router. But I then tracked it down to the couple of Firesticks on the non smart TVs, I've no idea why they do this though.

---druck