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.

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

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 acquired Cypress Semiconductor last year: https://www.infineon.com/cms/en/about-infineon/press/press-releases/2020/INFXX202004-049.html

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

Here's a link I got from Peter: https://www.eetimes.com/broadcom-sells-wireless-iot-biz-this-time-to-synaptics/

His summary was: Its complicated

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

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.

I'll see about putting together a quickdoc as a stop gap based on https://pagure.io/fedora-workstation/issue/116#comment-705174

See also: https://ask.fedoraproject.org/t/fedora-34-broadcom-wl/13965

We discussed this at this week's WG meeting (22 March).

• There was some talk about having Fedora media writer fetch the needed firmware and making it available on the install media. However, that will be a lot of work.
• The situation regarding making the firmware redistributable remains unclear, and we continue to lack contacts with the manufacturers. Could we possibly make contact through RaspberryPi?
• In the absence of having a way to install the firmware, we discussed improving error reporting and user documentation, hence @chrismurphy 's previous comment.

• There was some talk about having Fedora media writer fetch the needed firmware and making it available on the install media. However, that will be a lot of work.

The problem here is where does it fetch them from, who manages it and tests all the devices?

• The situation regarding making the firmware redistributable remains unclear, and we continue to lack contacts with the manufacturers. Could we possibly make contact through RaspberryPi?

I have some contacts with vendors, in one case it looks like the people have moved on and I need to try and find who replaced them, in another case the vendor is not currently interested in supporting firmware in linux-firmware and I am working to convince them of the value here. Unfortunately this process isn't particularly able to be open so unfortunately here I am being intentionally vague. The RPi Foundation is not a route to solving any of these problems.

• In the absence of having a way to install the firmware, we discussed improving error reporting and user documentation, hence @chrismurphy 's previous comment.

I'd like to present some name-and-shame dialog where we apologize to the user for nonfunctional wifi, name the corporate entities responsible for the breakage, and provide contact info so that users can complain. The responsible corporate entities are (a) whoever is still selling Broadcom wifi to OEMs, and (b) the OEM that sold the problematic end user device.

The RPi Foundation is not a route to solving any of these problems.

My thinking is that RPi is big enough that they can simply threaten to stop buying problematic hardware if the firmware is not opened up. Is that incorrect?

If they continue shipping bad hardware, then they'll simply fall under case (b) above. It's 2022, this is not acceptable, user sentiment is 100% our side... we do not have to play nice with bad vendors anymore.

I'd like to present some name-and-shame dialog where we apologize to the user for nonfunctional wifi, name the corporate entities responsible for the breakage, and provide contact info so that users can complain. The responsible corporate entities are (a) whoever is still selling Broadcom wifi to OEMs, and (b) the OEM that sold the problematic end user device.

It's really not that simple, there's 3 companies that provide the IP and it's actually quite difficult to identify it at that level, and then there's third parties that make out of the box modules to make it easier to integrate into designs, then there's the final equipment manufacturer that may have a NVRAM config that isn't shipped. Depending on the device it could be a combination of all 3 that are at fault.

The RPi Foundation is not a route to solving any of these problems.

My thinking is that RPi is big enough that they can simply threaten to stop buying problematic hardware if the firmware is not opened up. Is that incorrect?

They don't care, they won't do that, and they have solved the problem for their specific hardware and have shown no indication (and yes I have spoken with people there that are high up) that they care about it. They also only ship the HW from one of the 3 manufacturers which is the one I already have the best relationship with.

If they continue shipping bad hardware, then they'll simply fall under case (b) above. It's 2022, this is not acceptable, user sentiment is 100% our side... we do not have to play nice with bad vendors anymore.

We're a rounding error on their sales, do you think they'll actually care?

Unless something significantly changes, this is always going to be a "honey over vinegar" approach to resolve the problem. Making nice and persuading them to feel good about doing it will be a lot more successful than complaining and shaming them in public.

We touched on this issue during yesterday's WG meeting. The outstanding action is to update the docs - that's still on @chrismurphy's list.

Hi Chris, reminder that you have the action item here.

I'm going to make an executive decision and just close this issue. I don't think we need to track documentation of Broadcom wireless problems because few users will find the documentation.

Of course, it would still be good to do.

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.

Realistically, something like this is the only possible action we could take that would actually help users affected by missing wi-fi support, but I don't think the Working Group was enthusiastic about such an approach.

I think that the bare minimum here would be an error message when there's a missing driver (ideally in the installer or live media), and some documentation to say what the status of the support for this hardware is.

Do we have those things?

No, we don't. Really would have liked to see that. Let's reopen for reconsideration, I suppose. I'm not sure how exactly this would work, but it would make the user experience much better.

I don't have affected hardware anymore (well, it's in a box in storage in another city). If the scope of the problem is narrow enough to mostly solve it with documentation, we should solicit help from the community. At least with the hardware I had, installing the non-redistributable firmware blob is enough to get things sorta working, albeit with very limited support for 802.11abg, excluding n and 5Ghz. To get n and 5Ghz, I must install the proprietary driver from RPM Fusion. This too is somewhat hardware dependent.

OK, so we have multiple action items here:

• First, we need a design for how this prompt would look like. Allan, are you willing to add this to your backlog of design tasks?
• In parallel, we can compile some documentation, although I'm not sure that it would need to be Fedora-specific, so perhaps we could have some cross-GNOME location for this.
• Then we'd need to implement the design with a link to the documentation

I'm not sure how much energy we realistically have remaining for this. It would require volunteers at every step of the way. But if people want to work on this, it would certainly be very beneficial to users with affected hardware.

Unfortunately I'm not sure there's sufficient energy in the Working Group to continue tracking this issue. Unless somebody volunteers to manage this issue, I will close it soon.

OK, let's close this then.