Description of problem:I have an HP Probook 6550b with a Broadcom wifi card: $ inxi -SCGN System: Host: localhost Kernel: 6.6.61-desktop-1.mga9 arch: x86_64 bits: 64 Desktop: KDE Plasma v: 5.27.10 Distro: Mageia 9 CPU: Info: dual core model: Intel Core i3 M 350 bits: 64 type: MT MCP cache: L2: 512 KiB Speed (MHz): avg: 2261 min/max: 933/2266 cores: 1: 2261 2: 2261 3: 2261 4: 2261 Graphics: Device-1: Intel Core Processor Integrated Graphics driver: i915 v: kernel Display: x11 server: X.org v: 1.21.1.8 with: Xwayland v: 22.1.9 driver: X: loaded: intel,v4l dri: i965 gpu: i915 resolution: 1366x768~60Hz API: EGL v: 1.5 drivers: crocus,swrast platforms: gbm,x11,surfaceless,device API: OpenGL v: 2.1 vendor: intel mesa v: 24.2.7 renderer: Mesa Intel HD Graphics (ILK) API: Vulkan v: 1.3.231 drivers: llvmpipe surfaces: xcb,xlib Network: Device-1: Intel 82577LC Gigabit Network driver: e1000e Device-2: Broadcom BCM43224 802.11a/b/g/n driver: wl The wifi device will operate with either the broadcom-wl or the bcma drivers. In the past, I have used the wl driver because it seems to do a better job when the signal is on the weak side. I use network manager because it is easier for me to manage my VPNs if I want. The hardware has been idle for several months. When I booted it up today to get updates to bring it back to date, the wifi wouldn't connect at boot. Clicking on the NM icon in the taskbar informed me that there were no connections available. The first thing I tried in my investigation was to bring up our Network Center to see if it was detecting anything - and as soon as it came up NM made the connection on its own, and the applet showed all the available connections, like normal, and the connection was stable. A reboot had the same behavior. This hardware has three mga9 installs on it. I tried another install, with the same result. The third install is an i586 install using Xfce and the net_applet. That one connected normally. Going back to the primary install, I switched from the wl drver to the bcma driver, and rebooted. It seemed just a bit slower than normal, but the Plasma NM applet successfully established the wifi connection. So that's where I am now. I have switched the driver for the primary install to bcma. The secondary install, which I'm using to file this bug, is still using the wl driver, and it still has the issue. My primary suspect in this is the Plasma NM applet, as it was updated most recently - but I'm not ruling out an issue with the wl driver and the latest kernels. However, because I am in no way any kind of developer, please don't rule out that I may not know what I'm writing about.
Created attachment 14793 [details] journal captured shortly after making the connection by bringing up the Network Center
Sorry to have left you TJ. You know Broadcom is one of our Achilles' Heels, but should not be the cause here since once kicked into life, it works. Can you check anyway whether it has been updated? Do not know which is the relevant pkg name from: broadcom-bcma-config broadcom-ssb-config broadcom-wl-common dkms-broadcom-wl $ rpm -q --last BCdrivePackageName(s) plasma-applet-nm > My primary suspect in this is the Plasma NM applet, as it was updated most > recently Currently plasma-nm-5.27.10-1.2.mga9 Previous plasma-nm-5.27.5-1.mga9 You could try downgrading it: # urpmi --downgrade plasma-nm-5.27.5-1.mga9 Do you ever use a different desktop...? It is handy to have one for any problem which smells desktop specific.
CC: (none) => lewyssmith
Dkms -broadcom-wl is the driver, last updated by TMB in December 2022. Broadcom-wl-common contains some blacklist files to prevent the other drivers from conflicting. The other two also contain blacklisting files so that each is the only one active. I now suspect I may have a hardware issue with this old (2010!) laptop. The original Intel wifi hardware went bad a few years ago, and I replaced it with this one, used at the time, very cheap because it is/was old. It has worked OK, but today has been nothing but trouble, no matter which driver I use. It shows the wifi is connected, but it isn't communicating with the router now. Switching to a newer usb wifi dongle (not Broadcom) works perfectly. The laptop also has one speaker that is bad, and a few other minor issues, so I'm thinking it may be time for retirement, replacing it with something newer. I bought it in 2016, and it has served me well, but nothing lasts forever. Changing this to UNCONFIRMED, as I'm now not certain it's a Mageia problem at all, but then there's still a chance it may be.
Status: NEW => UNCONFIRMEDEver confirmed: 1 => 0
(In reply to Lewis Smith from comment #2) > > My primary suspect in this is the Plasma NM applet, as it was updated most > > recently > Currently plasma-nm-5.27.10-1.2.mga9 > Previous plasma-nm-5.27.5-1.mga9 > You could try downgrading it: > # urpmi --downgrade plasma-nm-5.27.5-1.mga9 This package name is wrong! It should be: 'plasma-applet-nm'. That shorter name is for the SRPM. So, if you hit the problem again using broadcom-wl, then please try downgrading the suspect package: # urpmi --downgrade plasma-applet-nm-5.27.5-1.mga9 Await your eventual feedback. Feel free to close the bug if you see fit.
Source RPM: (none) => plasma-nm-5.27.10-1.2.mga9.src.rpm
I installed task-xfce-minimal alongside with Plasma, and the network manager applet that goes with it, and rebooted into Xfce. It does the same thing, acts the very same way. So it probably isn't the Plasma applet. It could be Network Manager, but I wouldn't want to eliminate the broadcom-wl driver from the discussion. It could be that one of the network manager updates has revealed a problem with the wl driver. I searched for a reference to a newer build of dkms-broadcom-wl, but came up empty - except for one vague mention of something built for another distro. TMB updated this driver two years ago, when it wouldn't build/install the modules with the 6.1 series kernel. It seems strange to me that would have been no updates since then, so maybe I just don't know how to look.
Thanks for eliminating the Plasma applet. The fact that the broadcom-wl driver worked immediately at boot up to a few months ago, and has not been changed since, certainly suggests that intermediate updates have messed something. networkmanager has not changed. Are you able to try an earlier kernel (from Grub menu)? "The first thing I tried in my investigation was to bring up our Network Center to see if it was detecting anything - and as soon as it came up NM made the connection on its own" i.e. raisng the Network Center seems to kick into life the network. In the attached log (after launching netcentre), from 18:21:59 we see: [COMMAND=/usr/libexec/draknetcenter] draknetcenter[6859]: ### Program is starting ### 18:22:04 wpa_supplicant[1171]: wlo1: CTRL-EVENT-SCAN-FAILED 18:22:05 NetworkManager[1021]: auto-activating connection 'Andrews Farm' NetworkManager[1021]: <info> [1733008925.0597] device (wlo1): Activation: starting connection 'Andrews Farm' NetworkManager[1021]: <info> [1733008925.0600] device (wlo1): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'managed' NetworkManager[1021]: <info> [1733008925.0607] manager: NetworkManager state is now CONNECTING NetworkManager[1021]: <info> [1733008925.0616] device (wlo1): state change: prepare -> config (reason 'none', sys-iface-state: 'managed') .... 18:22:05 localhost.localdomain NetworkManager[1021]: <info> [1733008925.2763] device (wlo1): Activation: (wifi) Stage 2 of 5 (Device Configure) successful. Connected to wireless network "Andrews Farm" 'wl01' seems to be the relevant ID. There are a lot of: wpa_supplicant[1171]: wlo1: CTRL-EVENT-SCAN-FAILED ret=-22 messages before the sequence shown above. Is it worth producing a similar journal with the bcma driver which connects on its own - to make the tedious comparison of the two logs? (Useful to use --no-hostname to shorten lines)?
From Bug 33845 comment 52 (testing kernel 6.6.65-2) (In reply to Thomas Andrews from comment #51) > Same hardware as comment 50, different install using the broadcom-wl driver > for wifi: > > $ inxi -SN > System: > Host: localhost Kernel: 6.6.65-desktop-2.mga9 arch: x86_64 bits: 64 > Desktop: KDE Plasma v: 5.27.10 Distro: Mageia 9 > Network: > Device-1: Intel 82577LC Gigabit Network driver: e1000e > Device-2: Broadcom BCM43224 802.11a/b/g/n driver: wl > > No installation issues. The broadcom-wl driver appeared to build > successfully. > > However, after the reboot, Bug 33821 is still in effect. Network Manager > does not initialize/start the wifi connection, but all I have to do is run > the Network Center, and as soon as the gui appears, Network Manager > automagically establishes the connection to my network. Once started, there > are no issues with retaining or using the connection. It does this with > every boot. The install from comment 50 uses the open source bcma driver, > and doesn't show the issue. > > One caveat: This hardware is nearly 25 years old, and I no longer consider > it to be as reliable as I once did. That is why bug 33821 is labeled as > "unconfirmed." That said, when something shows up every time I log in, it's > usually not from a hardware issue. > > In any case I do not believe this is a kernel issue, and should not block > this update. the broadcom driver is built from a 3rd party broadcom-wl package, external to kernel, which arrives from a pretty old driver tarball (it's 2015) that wasn't officially updated anymore. Our package includes patches from here and there to build under newer kernel, but our packages stopped on december 2022. There is also a git source which collects further patches here https://github.com/antoineco/broadcom-wl/, from which the latest commit here https://github.com/antoineco/broadcom-wl/commit/f87141bb137db22fe17fc2fe42bfb39187220fc8 says "it's no longer maintained" and suiggests to seek for other alternative sources from either one of these: - Arch: https://gitlab.archlinux.org/archlinux/packaging/packages/broadcom-wl-dkms - Debian: https://salsa.debian.org/broadcom-sta-team/broadcom-sta - Fusion: https://pkgs.rpmfusion.org/cgit/nonfree/wl-kmod.git/ And maybe there are also other new tree in github. What is not completely clear here is whether your card can work with either bcma.ko, and wl.ko? If so why not use just bcma.ko? Which tool decided to use broadcom-wl instead? So wl.ko module is (or was) an alternative to bcma.ko supposed to work better? In the end maybe our broadcom-wl 3rd party package driver just need a revision incorporating the extra fixes available in the link above (so should have its own bug). And last but not least what are the device pci-id of your broadcom card (e.g. from lspcidrake -v)?
My response, and his response to mine: (In reply to Thomas Andrews from comment #54) > (In reply to Giuseppe Ghibò from comment #52) > > I don't wish to take this bug too far off on a tangent, but I will try to > give brief answers to your questions. > > > > the broadcom driver is built from a 3rd party broadcom-wl package, external > > to kernel, which arrives from a pretty old driver tarball (it's 2015) that > > wasn't officially updated anymore. Our package includes patches from here > > and there to build under newer kernel, but our packages stopped on december > > 2022. There is also a git source which collects further patches here > > https://github.com/antoineco/broadcom-wl/, from which the latest commit here > > https://github.com/antoineco/broadcom-wl/commit/ > > f87141bb137db22fe17fc2fe42bfb39187220fc8 says "it's no longer maintained" > > and suiggests to seek for other alternative sources from either one of these: > > > > - Arch: > > https://gitlab.archlinux.org/archlinux/packaging/packages/broadcom-wl-dkms > > - Debian: https://salsa.debian.org/broadcom-sta-team/broadcom-sta > > - Fusion: https://pkgs.rpmfusion.org/cgit/nonfree/wl-kmod.git/ > > > > And maybe there are also other new tree in github. > > > Yes, I remember our last change to the wl driver. It did not build for me > while testing the 6.1 series kernel. I reported that to TMB, he worked on > it, and it started building and working again. > > > What is not completely clear here is whether your card can work with either > > bcma.ko, and wl.ko? If so why not use just bcma.ko? Which tool decided to > > use broadcom-wl instead? So wl.ko module is (or was) an alternative to > > bcma.ko supposed to work better? > > > This answer is more involved. This laptop originally came with an Intel wifi > card. It went bad, and I replaced it with the broadcom card that I salvaged > from another 6550b. It has always worked with both bcma and wl drivers, but > there are issues related to each. > > Our Network Center has a bug with the bcma driver. When left on its own, it > selects a "driver" that doesn't work. The user has to select the correct > driver manually. See bug 31473 for a more detailed explanation, including > screen shots. Network Manager hasn't displayed this issue - yet. And, our > Network Center doesn't show the issue when the wl driver is installed. > > > In the end maybe our broadcom-wl 3rd party package driver just need a > > revision incorporating the extra fixes available in the link above (so > > should have its own bug). > > > I think that might be something to think about. Bug 33821 might serve for > that. Yes, exactly. As reminder I think we can move the infos here to that bug, to see if we can overhaul the broadcom-wl package adding the missed available patches (that would be also good for next kernel 6.12.x).
So Giuseppe believes the latest patches should be added to the broadcom-wl driver, because the latest build is two years old, was done for the 6.1 series kernel, and may need the patching to work with the upcoming 6.12 series kernels. And, one of those patches may fix this problem, too. Worth a shot. Changing the description of the bug, the status, and assigning it to Giuseppe. If any of that is in error, please correct it. It is not my intention to step on any toes.
Assignee: bugsquad => ghibomgxSummary: Network Manager Plasma applet does not connect to a broadcom-wl device at boot. Works OK with bcma driver => Network Manager applets do not connect to a broadcom-wl device at boot. Works OK with bcma driverSource RPM: plasma-nm-5.27.10-1.2.mga9.src.rpm => broadcom-wl-6.30.223.271-66.mga8.nonfree.src.rpmStatus: UNCONFIRMED => NEWEver confirmed: 0 => 1
(In reply to Lewis Smith from comment #6) > Thanks for eliminating the Plasma applet. > The fact that the broadcom-wl driver worked immediately at boot up to a few > months ago, and has not been changed since, certainly suggests that > intermediate updates have messed something. > networkmanager has not changed. > > Are you able to try an earlier kernel (from Grub menu)? > The oldest kernel I have on this install is 6.6.28, from April 2024. I believe it worked then, but quite frankly I can't be sure of that memory. But, whether it worked then or not, it doesn't work with it now. > "The first thing I tried in my investigation was to bring up our Network > Center to see if it was detecting anything - and as soon as it came up NM > made the connection on its own" > i.e. raisng the Network Center seems to kick into life the network. > Indeed. If I check the applet before getting things activated, Network Manager shows no available networks at all. AFTER running network center, it shows my network, and my neighbor's, if I happen to be near a window. It's as if network manager isn't initializing the device (sending firmware?) properly. > 'wl01' seems to be the relevant ID. There are a lot of: > wpa_supplicant[1171]: wlo1: CTRL-EVENT-SCAN-FAILED ret=-22 > messages before the sequence shown above. > Yes, "wl01" is the ID assigned to the wifi device by the wl driver. Has been right along. Wait... wpa_supplicant was updated fairly recently, might have included an rpmnew to change the config file, and I don't remember if I used it or did nothing... Hmmm... > Is it worth producing a similar journal with the bcma driver which connects > on its own - to make the tedious comparison of the two logs? (Useful to use > --no-hostname to shorten lines)? We'll let Giuseppe answer that question.
> One caveat: This hardware is nearly 25 years old, and I no longer consider > it to be as reliable as I once did. That is why bug 33821 is labeled as > "unconfirmed." That said, when something shows up every time I log in, it's > usually not from a hardware issue. Must be my math skills that aren't what they used to be. The hardware is nearly 15 years old, NOT 25. Sigh.
Still in effect for kernel 6.6.74 and kernel 6.6.77. No surprise there, as there has been no change in the driver yet. It still appears to build correctly, and acts as if the chip had not been initialized until our Network Center has been run. After that initialization, it works as it should. I have not seen any of the glitches reported in comment 3, but then I haven't used this laptop very much, either. I am using it rght now, in the same room as my router. When I saw the glitches, I was one floor above and two rooms away from it, so it could be that range was a temporary problem.