Hi,

I've been working on a few improvements to this driver, trying
(hopelessly) to fix the disconnect issues on my particular card + router
combination. Although my original goal has failed miserably, I was able
to figure out a couple of other fixes for common issues with this card.

I have pushed a branch to salsa, which includes the following fixes:
 * Make power management commands actually work (the driver ignores
 turning PM off)
 * Correctly read the value of TX power (the notorious "200dBm" bug)
 * Correctly refuse MAC address changing (fixes network-manager
 disconnects because of "random / custom mac address"
 * Cleanup a few compiler warnings, and cfg80211 API usage

The branch is here:
https://salsa.debian.org/diegoe-guest/broadcom-sta/-/commits/diegoe_debian

While working on the above I also figured that I might as well try to
create a proof of concept "new upstream" without all the cruft from the
10 years of kernel versions conditionals:
https://salsa.debian.org/diegoe-guest/broadcom-sta/-/commits/frankenwl

My "frankenwl" branch is functionally the same as the above
"diegoe_debian" branch, but it certainly makes it less convoluted to try
and find problems in the code going forward. That said, I wasn't sure
what would be the best way to proceed, or if it was a smart thing to do
anyway. I guess this package is on "life support" on most distros, so I
doubt there would be a objections on creating a shared new upstream (but
I'm not familiar with the packaging of this driver in Debian, or other
distros).

I also tried, naively, to contact cypress/broadcom to inquiry about a
newer firmware blob dump, or just a new code dump. Of course, no
response. I think it's worth highlighting that the kernel bcmf80211
driver is very similar to the broadcom-sta code, which lead me to
believe that it can work with the cards supported only by broadcom-sta,
we just need the firmware blob and plug the loose ends. Anyway, this is
probably never going to happen, unless someone figures out how to
extract the (say, in my case) BCM4360 software-side firmware blob from
the linux or mac or windows driver.

Anyway, I wanted to share this work here so it's considered for
inclusion for the upcoming Debian stable. At the very least this solves
a few nitpicks (power settings, tx set/get) that degrade the user
experience and a serious issue (mac address failures) that usually gets
new users stuck and confused (random NM disconnections).

I'm also aware that cards supported by this driver are "old" but most
computers trapped in the broadcom-sta driver are perfectly functional
today and will be for a few more years. In my particular case I'm
running a macbookpro11,1 (2013) which works flawlessly except for the
wifi! (Hah!) -- And I understand most other macbookpro models from
around 2013 share this or similar Broadcom cards that use this driver.
All those machines should be perfectly functional with Debian right now,
and for a few more years.

Hope to hear your feedback, I'm glad to cleanup this branch as you see
fit to get it merged into the package.

Diego

Dear Diego,

Thanks for your patches!
Please see my comments below.

Thanks again for your great work!
I haven't reviewed the patches yet, but I built a deb package and
tried to install, and found it works well on my macbook.
Maybe I can upload a version to experimental later.

Since the upstream seems not active for quite a few years, so I think
it's totally fine if you want to fork.
And if you do so, I'm happy to update debian package to follow your
forked git repo.

Yes, I understand and agree with you.

Yes, I also have two mac devices that use this driver.
Thanks for your effort to make the driver better.

Cheers,

Hey Roger,

Apologies for the radio silence. I just saw that this email ended up
in the spam folder :(.

Thanks for your comments and eagerness to welcome and test this, I'm
really glad that more people will find this useful :) :)

Some comments:

Do you think it would be worth it to reach out to maintainers at a few
main distros and see if there's any interest to collaborate on this?
When I was trying to figure out the issues with my card (see below) I
noticed that most distros either copy+paste patches, or brew their own
slightly different versions.

I wonder if you have run into the connection timeouts/unstable wifi
issues that many other users run into? I have been trying to debug why
and when this issue happens, but perhaps you might have any clue or
anecdote that might help figure this out.

The issue seems to appear when using certain (seemingly old) APs that
do not implement anything newer than 802.11n -- meaning that anything
with 802.11ac is usually free of the issue. The problem manifests as
sudden very high latency, and sometimes lost ARP/identity towards the
AP. I have been unable to debug the issue, but I have reasonably
eliminated WMM, power saving (both PCI/card and 802.11 protocol),
b/g/n, and a few other suspects.

From my own testing it would seem that the firmware blob in the card
(or the blob uploaded by the driver) simply stops reporting new
packets, either queuing them, or simply dropping them silently, which
on user space manifests as progressively higher latency and eventual
lost of connectivity until resync/reconnection happens, or the
firmware behaves again. I don't have the proper network hardware to
test the router side, so I can't 100% confirm what's going on.

AFAIK, these cards have a hybrid firmware model where there's a ROM
firmware in the card, but by design you have/can upload a RAM firmware
that allows the OEM/IHV to upload new features or fix bugs. Fairly
standard, I understand. But my current hypothesis is that the
particular card I have is an slightly custom module by Apple that has
certain buggy behaviors that get corrected with the RAM firmware made
by Apple. To give some support to this hypothesis, my current card +
AP combo exhibited the same buggy behavior under OSX. However, this
buggy behavior got fixed on OSX a few months after the last ever
release of broadcom-sta for Linux. My hypothesis is that whatever bug
that this ROM firmware has with slow or old APs (whether a Broadcom or
Apple integration bug), got fixed by Apple or Broadcom in an updated
RAM firmware, but said fix missed the window of the last ever
broadcom-sta.

Anyway, my current understanding is that we can't fix the described
problem with the "open" part of the driver. It is the firmware part
that is the problem, so unless someone learns or knows how to extract
the firmware from the binary blob in OSX/Windows, and then use that in
Linux, or something like that, then the use case of "old weird AP +
this card" is broken under Linux (under some undetermined
circumstances).

Rant over. Thought I would share the above info anyway, in case you
might have any clue or anecdote that could help figure this out.

control: fixed -1 6.30.223.271-16

Dear Diego,

Finally all your patches reached bullseye (stable to be) and buster
(backports). :-)

I think upstream maintainer is not active, and the binary blob hasn't
been updated for years.
Anyway you can try to reach them.

You patches already improved the driver quite much.
I do meet some packet drops sometimes, but not very often.

It'd be appreciated if you can improve this driver more.

Cheers,
Roger