A bit more on Bookworm and WiFi problens

Oct 27, 2024 Last reply: 1 year ago 20 Replies

A power cut this a.m had my Pi zero W reconnecting to the wrong wifi.



Which forced me to delve into the depths of network manager as evinced by nmcli. Network manager is the new way to manage networks, and like systemd, its all changed for the sake of it



You probably can edit the files directly - mine were in /etc/NetworkManager/system-connections, but it's safer to use nmcli tools


You can set a priority if you have more than one wifi SSID.



sudo nmcli c modify <connection name> connection.autoconnect-priority 1



You can also force it to use 5Ghz or 2.4Ghz or let it decide



sudo nmcli c modify <connection name> 802-11-wireless.band "bg"



or



sudo nmcli c modify <connection name> 802-11-wireless.band "a"


"bg" is 2.4GHz, "a" is 5GHz.



It may well be that bookworm has changed the implicit defaults in network manager.



It is well worth dumping the connections with



sudo nmcli connection show <connection name>



To work out what the connection names are, use



sudo nmcli c show



I think - but am not sure - that you can set more stuff through the command line than through the GUI interface to network manager



yes. I didnt find it as good as either the straight CLI or the GUI

After a bit more fumbling two new wrinkles emerged. One was a report of wifi being turned off by rfkill. This happened once before, and re-setting the locale options seemed to fix it. This time re-establishing the locale had no detectable effect.

After a bit more fumbling it appears that the wifi connects readily when the wired ethernet is also connected. Maybe that's significant, but exactly how isn't apparent to me.

Thanks for posting the hints on using nmcli!

bob prohaska

I have the same IP address assigned to both the wired and wireless interfaces on my laptop, on my house DHCP server. That lets me switch from one to the other more seamlessly, and even use both at once.

The bookworm wifi saga continues. After a software update that resulted in a black screen (fixed by rebooting from microSD, which inexplicably mounted root from USB) the machine started booting from USB but couldn't start the internal wifi.

After connecting a usb-wifi dongle and rebooting, first the usb-wifi interface came up unprompted and then the internal wifi came up a moment later. Now both interfaces are up and working using 2417 MHz channel 2 but different IPs.

So, it looks like the behavior of the internal wifi is dependent on both wired ethernet and USB ethernet connectivity.

If anybody has thoughts on what I'm doing wrong please post. This is becoming very confusing, unless it's just teething trouble with bookworm.

Thanks for reading,

bob prohaska

More likely the boot failure was from labwc being installed

I had that.

Hadn't fully made the USB drive bootable.

That an upgrade can fail is not so astonishing 8-0

However, I expected the root device to be microSD, consistent with rpi2,-3 and -4. The desktop shown was on the microSD, but root was mounted from USB.

Having the entire problem go away after a single reboot with a month-older image was also rather confusing.

The Pi5 is still up, connected with both wifi interfaces and seemingly working just fine after a day, no microSD involved at all.

Thanks for reading!

bob prohaska

[Snip]

Hold on, the Zero W and the Zero 2 both only have 2.4GHz WiFi

The 2.4/5 GHz Pi's are the 3B+, 4B and 5.

---druck

It should not be, but I'm confused you mention USB-WiFi in one paragraph and USB-Ethernet in another.

Did you start with a fresh Bookworm image? What have you installed since? What other hardware is connected? Are you using an official power supply?

---druck

Apolgies for the mixup. I meant to report that the behavior of the internal wifi seems to be affected by both use of wired ethernet and use of usb wifi. The internal wifi connected spontaneously after connecting either a wired ethernet cable or a usb-wifi dongle. Alas, that behavior is not repeatable. In the present config the usb-wifi dongle connects, I can't get the internal wifi to connect though it does detect the access point.

There does seem to be a large discrepancy between wlan0 and wlan1 signal strength: wlan1 reports 93-96%, internal wlan0 only 79%. Prior to the recent upgrades (but still bookworm) wlan0 reporting more than about 70% gave a decent connection.

Initialy, yes. It was customized on microSD, moved to a USB hard disk using Raspberry Pi Imager.

Nothing apart from supplied upgrades, but I am using wayland, which has been described as troublesome.

One powered hub, running the added usb-wifi dongle (old Ralink RT5370) plus an old Dell keyboard and mouse..

No, but the Pi5 reads 5.07 volts at the GPIO header.

As this saga plays out the USB-Wifi dongle seems to work quite well. Maybe it's all down to the better signal strength. Because the problem appeared shortly after an OS upgrade I tended to blame that. Perhaps I'm mistaken.

bob prohaska

I think you have snipped a bit of context.

It was network manager that you could force to be on the correct frequency & the OP has indeed got that option, I merely referred to the zeros since that is what I have as examples of how to use network manager to do all the crap wpa_supplicant used to do.

I am still fighting a similar issue in that one of my pis will not sort its dns out until its been sorted out so to speak.

The common factor is a service that wont work until connectivity that it should provide itself is already established.

I wonder if the wifi software needs access to something before it will wake up.

I cant see why of course.

I see something about "NetworkManager-wait-online..." failing to start during boot up. It doesn't fail consistently, and I don't see any obvious difference in system behavior either way.

After idling overnight dmesg reports a flood of [76285.418728] brcmfmac: brcmf_set_channel: set chanspec 0xd022 fail, reason -52 [76285.526747] brcmfmac: brcmf_set_channel: set chanspec 0xd026 fail, reason -52 [76285.630745] brcmfmac: brcmf_set_channel: set chanspec 0xd02a fail, reason -52 [76285.734787] brcmfmac: brcmf_set_channel: set chanspec 0xd02e fail, reason -52 as if something's stuck in a loop.

Wifi by way of the usb-wifi dongle is up, wavemon reports freq: 2417 MHz [survey freq: 2462 MHz], channel: 2 (width: 20 MHz (no HT)) for the connected interface.

The internal interface reports 87% signal strength from the configured access point but the search has apparently stopped at 5825 MHz channel

165 which can't work since it's a 2.4 GHz access point.

The network drop-down menu sees my access point through both interfaces but won't let me try to connect the internal without turning wifi off and back on (can't test further because I'm typing this over the wifi link).

Thanks for reading!

bob prohaska

Went back as far as I had available in the thread, and the two issues seem to have become entwined by then, which is a bit confusing.

---druck

That does sound like some of the Network Manager behaviour I've experienced on a couple of Linux Mint laptops.

The WiFi antenna on the motherboard is very small, as long as it's a normal sized USB WiFi stuck and not one of the tiny nub ones, it's antenna will be far bigger.

That's why I used dongles in the shed at the bottom of the garden for years with the Pi 1 and then 2, as the signal strength was better than a Pi 3 with built in WiFi, although the reliability of the dongles wasn't great. Incidentally I'm now using my first Asus router as an Ethernet to WiFi bridge, which connects to the house easily over 5GHz with it's large triple antenna.

So it's a vanilla install using NetWork Manager and not an upgrade from Bullseye as I've been doing to retain the old well working DHCPCD and WPA supplicant networking.

It can be, but not usually to networking.

Normally on Pi's I'd be looking at a hardware issue to do with the power supply and the amount of USB devices connected, but I think you are right in this case, and it's Network Manager getting confused about what interfaces are available.

---druck

Or perhaps what priority order they are to be selected in.

Perhaps its insisting on Ethernet before it brings up wifi etc etc.

The system seems agnostic between wired and wireless networking. From its initial setup internal WiFi was the only networking option. It worked for some months and then got flaky about one day after an OS update, but was still usable. Shortly after a subsequent update, the problems seemed to go away. Following yet another update the WiFi became unusable and I moved the host where it could be hard wired. That also put it much closer to my access point, whereupon both WiFi and wired networking functioned.

Since then I added the usb-wifi dongle and returned the host to its former location. The internal WiFi has connected on isolated occasions, but the WiFi dongle works reliably and reports much higher signal strength than the internal WiFi.

Suspicion first fell on the OS because of the initial appearance and correction of problems after OS upgrades. Then it shifted to interference from neighboring APs, which have about doubled in number but mostly use

5 GHz while mine's on 2.4 GHz. At this point it's unclear what's going on.

For now I'll plan to use a WiFi dongle on the Pi5 and watch what happens.

Thanks to all who've followed this thread!

bob prohaska

Just got a new usb-wifi adapter, a TP-Link AC1300 which works on both

2.4 and 5 GHz (the old dongle was 2.4 GHz only). It worked on the fly out of the box, No problems whatsoever. I wondered if access to 5 GHz bands might sidetrack the connection process, but not at all.

There is still a problem with NetworkManager-wait-online.service failing regardless of which dongle is used. No ill effect seems to result, but it is strange.

Thanks for reading,

bob prohaska

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required