The problem is that, when you reboot the PC, 13b1:0039 gets recognized as 13b1:0bdc, which prevents it from loading the brcmfmac kernel module... Because "0bdc" is not a real product. A tedious workaround was to physically unplug and replug it, since it gets identified as "0039" the second time (you can confirm this by running
Code: Select all
lsusb
After lots of troubleshooting, I found an automated way of doing this, without touching anything. The answer is based off of shodanex's reply to a similar issue: https://stackoverflow.com/q/442833
It involves explicitly telling the drivers to also be used with the device's incorrect ID.
# Steps to fix
Press Ctrl+Alt+T, or open your favorite terminal.
All the following commands must be run as sudo, but I got "permission denied" when running it as-is. So, run
Code: Select all
sudo -i
Because brcmfmac might not even be loaded, you may need to load it yourself. So type:
Code: Select all
modprobe brcmfmac
Now for the actual fix, let's tell brcmfmac to also use this wrong ID:
Code: Select all
echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id
This will make sure the device uses the brcmfmac module, even if its ID is incorrect. After a few seconds, the dongle should be recognized, allowing you to configure a WiFi network! You can do that through the GUI as usual or run
Code: Select all
nmtui
If everything went well, you should have a working internet connection
Now that we know it works, we can automate this by running a cronjob every time the system boots.
Run:
Code: Select all
crontab -e
Code: Select all
@reboot modprobe brcmfmac
@reboot echo 13b1 0bdc > /sys/bus/usb/drivers/brcmfmac/new_id
## More info
I tried a lot of things before coming up with this, and was about to give up on the issue. Luckily, someone else seems to have reported it: https://bugs.debian.org/cgi-bin/bugrepo ... ug=1001189
Of course, it's not a bug from Debian, as other distros have the same issue. It should be the kernel, but don't know if it's been reported upstream yet.
I hope this helps!