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: On Thu, Oct 1, 2020 at 11:08 AM Roger Shimizu <r...@debian.org> wrote: > > 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). > > 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. > 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'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. > > Yes, I also have two mac devices that use this driver. > Thanks for your effort to make the driver better. 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.
