#116 Broadcom wireless
Opened 2 years ago by catanzaro. Modified 2 months ago

Currently when users install Fedora on laptops with Broadcom wireless, the user experience is very poor. Wifi doesn't work, and users have no indication why and no instructions as to what to do about it.

Ideally we would handle this a bit better. Given the constraint that we can't distribute the firmware, we should at least be able to detect that the firmware is missing and provide some manual installation instructions: go to such and such website on another computer, download the file, store it on a USB drive, etc. (Clearly I haven't done any research as to how this works.) I would also provide an aggressive message saying that wireless network access is restricted by Broadcom per Broadcom company policy and to please consider complaining, and display some executive contact information. If everyone installing Fedora with Broadcom wireless sees the executive contact information, and 1% of the users who see it act on it, who knows: might work. We can at least generate some bad news coverage for Broadcom and help Fedora users figure out how to get online.


Last time I looked at b43 stuff, it was complicated. Maybe six possibilities? My sample size is only one, but I tried two paths: b43-fwcutter+opensource driver, vs Broadcom proprietary driver (which I think is what's in RPM Fusion non-free but I'm not confident of that).

The b43-fwcutter path starts as an Easter egg hunt for a firmware blob, and ends with limited wifi: unsupported bands, unsupported speeds, unsupported interference mitigations, etc.

The proprietary driver path requires local compiling every time a new kernel is installed, but then the hardware is fully supported.

I uncertain how to make a recommendation; maybe throw it up on devel@ for discussion and at least get a larger sample of experiences?

Last time I looked at b43 stuff, it was complicated. Maybe six possibilities? My sample size is only one, but I tried two paths

These are the only two paths we should care about. The third path is trying to use the Windows driver but I don't think anybody does that anymore.

Broadcom proprietary driver (which I think is what's in RPM Fusion non-free but I'm not confident of that).

It is.

b43 while not perfect is acceptable for a lot of hardware and is by all measures better than having no wifi at all.

Ideally there would be some kind of warning before you install, as part of a hardware compatibility check...

Integrating instructions for how to install, or even linking to online documentation, makes me a bit nervous. Is this something we could test each release, to make sure that it still works and is accurate?

Example dmesg | grep b43
https://paste.centos.org/view/5666a7a7

That's the only warning I get, and anaconda doesn't look for this or report it.

Also the "must go to" URL is broken. That's hilariously bad.
https://bugzilla.kernel.org/show_bug.cgi?id=205819

There could be a testcase for this. e.g. you can see a list of test cases here for current release, and how they get organized and what milestone they're required for, or if they're optional (non-blocking). This gets the test case some visibility every release.
https://fedoraproject.org/wiki/Test_Results:Current_Installation_Test
https://fedoraproject.org/wiki/Category:Test_Cases

There can also be a scheduled test day. The gist is someone needs to drive the process by proposing it, having a plan for test day's goals. QA helps coordinate and announce it which steers the testers to this explicit test case, giving it even more visibility.
https://fedoraproject.org/wiki/QA/Test_Days

From kernel maintainers file:

B43 WIRELESS DRIVER
L:  linux-wireless@vger.kernel.org
L:  b43-dev@lists.infradead.org
W:  http://wireless.kernel.org/en/users/Drivers/b43
S:  Odd Fixes
F:  drivers/net/wireless/broadcom/b43/

B43LEGACY WIRELESS DRIVER
M:  Larry Finger <Larry.Finger@lwfinger.net>
L:  linux-wireless@vger.kernel.org
L:  b43-dev@lists.infradead.org
W:  http://wireless.kernel.org/en/users/Drivers/b43
S:  Maintained

The first one isn't maintained, the second one is legacy but claims to be maintained. That's confusing. And the URL is bogus, it 404s.

The kernel reported URL is still bogus 3 months after filing a bug about it, it also 404's.

The working site I found has no firmware files on the downloads page.
https://wireless.wiki.kernel.org/en/users/download

I can't figure out where the current firmware files are at all.

I asked on the kernel list about RPM Fusion singing Nvidia modules. A possible way forward with Nvidia and Broadcom, is to expand this issue into a how to make RPM Fusion easier to use, and use the proprietary kernel modules for these things.

If the computer has wired ethernet, this is the least resistant path

sudo dnf install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
sudo dnf install rpmfusion-nonfree-release-tainted
sudo dnf install b43-firmware

Draft USB stick alternative:

sudo dnf install b43-fwcutter
mkdir b43firmware
cd b43firmware
curl -O https://download1.rpmfusion.org/nonfree/fedora/tainted/$(rpm -E %fedora)/SRPMS/b/b43-firmware-6.30.163.46-7.fc33.src.rpm
rpm2cpio b43-firmware-6.30.163.46-7.fc33.src.rpm  | cpio -idmv
tar -xf broadcom-wl-6.30.163.46.tar.bz2
sudo b43-fwcutter -w /lib/firmware broadcom-wl-6.30.163.46.wl_apsta.o

I've tested both of the above on a Macbook Pro that has BCM4331 WiFi. And they both work. Ideally the USB method would be more like the first, something like having all the RPMs for the repos, the keys, and the b43-firmware package. But I'm not sure.

Metadata Update from @catanzaro:
- Issue tagged with: meeting-request

8 months ago

Metadata Update from @catanzaro:
- Issue untagged with: meeting-request
- Issue tagged with: meeting

8 months ago

Action: Matthias to ask Christian for an update on what we're able to do regarding Broadcom.

Metadata Update from @catanzaro:
- Issue untagged with: meeting

8 months ago

Metadata Update from @aday:
- Issue tagged with: pending-action

8 months ago

Metadata Update from @aday:
- Issue assigned to mclasen

7 months ago

Metadata Update from @ngompa:
- Issue tagged with: meeting

5 months ago

Updates I got:

cschaller:  mclasen, yeah I did, we even had some outreach via the partner manager at the time, but it ended up pretty fruitless
aruiz   hans did
cschalle    I assume Hans got nowhere too?
aruiz   bcm sold the wifi division to cypress,  not sure if they still sell any wireless chips as bcm

Infineon+Cypress do not offer Wi-Fi stuff for PCs anymore, only the IoT space: https://www.cypress.com/products/wireless-connectivity

So it may be easier now to get them to make the firmware redistributable with terms RH/Fedora can work with.

I've asked Alberto, but he says he doesn't have that level of detail yet to know if this is going to be relevant to him

So now it's Synaptics we need to talk to?

My guess is the old stuff is with Cypress and the new stuff is with Synaptics.

This shows the grid of what hardware is supported by the b43 open source driver. Many have either no or partial support. Even in the supported category, for example bcm4311 which I have, not only is 5GHz band not supported, but 802.11n is not supported. That now explains why I couldn't see local APs with the b43 driver (that laptop is 10 years old and qualifies as weird ancient junk). I think it'd still help he helpful to solve this for those with reasonably current hardware.

https://wireless.wiki.kernel.org/en/users/Drivers/b43

Metadata Update from @ngompa:
- Issue untagged with: meeting

4 months ago

We talked about this in last week's meeting:

ACTION: @mclasen to talk to @aruiz and @pbrobinson (cmurf, 16:17:45)

ACTION: @mclasen to talk to @aruiz and @pbrobinson (cmurf, 16:17:45)

Did this happen? Can we get an update?

My guess is the old stuff is with Cypress and the new stuff is with Synaptics.

It's even worse than that as all three companies Broadcom/Infineon/Synaptics produce WiFi/BT modules based on the same IP.

Broadcom sold the "IoT division" to Cypress while keeping their "high value customers" (AKA Apple, Dell and related), then a few years later they sold their "IoT division" to Synaptics while keeping their "high value customers" (sound familiar). Now I believe a lot of the high value customers have moved onto other vendors so outside of Apple I don't know how many newer laptops have Broadcom chips and which ones they are if any. The Broadcom IP which was in devices like the RPi-400 and Pinebook Pro is now part of Synaptics.

Cypress is now part of Infineon and I have a good relationship with them and thankfully the acquisition didn't break that. They now update the WiFi firmware for their parts quite regularly, we've had two releases since we came up wit the plan, they ship generic countries blob for the FW so the wifi will work, if not to the highest strength for country specific devices but it works and works pretty well. They're working to get the BT firmware upstream too but we're not quite there yet.

The Synaptics parts are still a work in progress. They don't believe their parts are used in Linux at all so it's a combination of education and trying to find the right person in the right division to educate. Their parts are becoming more common now the flip out of Broadcom is complete but they've also acquired a bunch of silicon IP from other companies of late including marvell so it all seems to be a little in flux.

So in summary the Infineon/Cypress parts are in reasonable shape and will move to good shortly. The Broadcom status is indeterminate as to whether we care. The Synaptics parts are a work in progress.

Thanks @pbrobinson!

it seems like there's a few different threads to this issue, which it would be worth teasing apart.

The first is @catanzaro 's original suggestion that we provide user feedback if wireless firmware is missing. I don't see anyone saying that that's a bad idea, though there are open questions regarding when to show that message, and whether we can point the user to useful instructions to manually install the firmware.

The second thread is where the majority of the discussion has been, and concerns improving the availability of the firmware for certain chips. Is there anything that the WG can do here?

The first is @catanzaro 's original suggestion that we provide user feedback if wireless firmware is missing. I don't see anyone saying that that's a bad idea, though there are open questions regarding when to show that message, and whether we can point the user to useful instructions to manually install the firmware.

I think that will be hard to do as in a number of different WiFi cases (I've also been working on issues with Realtek) it's very hard to know where to actually get the firmware, and in some case the firmware is actually there but not a device specific NVRAM.

Login to comment on this ticket.

Metadata