control: fixed -1 6.30.223.271-16 Dear Diego,
Finally all your patches reached bullseye (stable to be) and buster (backports). :-) On Tue, Oct 20, 2020 at 2:21 AM Diego Escalante Urrelo <die...@gnome.org> wrote: > > 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 think upstream maintainer is not active, and the binary blob hasn't been updated for years. Anyway you can try to reach them. > > > 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. 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
