I'd like help reporting an anomaly/bug with wifi and NetworkManager under Buster
Hello all,
I've discovered a small bug in linux (wifi?) networking, but I haven't been able to report it because I don't seem to know the correct package to report the bug against.
I bought an older, "obsolete" usb wifi adapter (D-Link DWA-130, Rev. F) after reading of the difficulties using up-to-date wifi adapters and after confirming more or less that this one ought to work with firmware and driver available in the firmware-ralink package.
I installed the usb wifi adapter and firmware-misc-nonfree on a desktop computer running Buster. The computer could then see several nearby wifi routers, including my own, but it COULD NOT connect to any of them, even with the access passwords.
The computer uses NetworkManager to manage the wifi connenction.
==Troubleshooting:==
I installed the same D-Link adapter on another computer (same make and model) running Jessie, along with the firmware-ralink package (as it was called under Jessie) and it all works fine together, again using NetworkManager to manage the wifi connection. The D-Link DWA-130 usb wifi adapter is able to see the nearby wifi routers and to connect to the internet with the appropriate router password.
I found a workaround (detailed below) to allow this usb wifi adapter to work under Buster. Wishing to be a good FOSS citizen, I filed a bug report against the firmware-misc-nonfree (firmware-ralink) package (that was my best guess for the location of the problem).
The contents of the bug report and a follow-up message with more detail are here:
========== BUG REPORT FILED: =========== (contains details of the workaround mentioned above)
To: Debian Bug Tracking System <submit@bugs.debian.org>
Subject: firmware-ralink: none
X-Debbugs-Cc: none
Package: firmware-ralink
Version: 20180825+dfsg-1
Severity: normal
Dear Maintainer,
Under Debian Buster, a usb wi-fi adapter D-link DWA-130, rev. F1 can display available wifi services but could not connect
to any of them. An "ip link" command shows:
wlx74dada1c2b5d: <NO-CARRIER, BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
link/ether 74:da:da:1c:2b:5d brd ff:ff:ff:ff:ff:ff
The same D-link usb wifi adapter installed on a same make and model computer but running under Debian Jessie works without problem, able to connect to any chosen wifi service.
On that Debian Jessie system, ip link shows:
wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
link/ether 74:da:da:1c:2b:5d brd ff:ff:ff:ff:ff:ff
I noted the difference in the generated device name between Buster and Jessie.
=== Workaround: ===
I am able to make the D-link usb wifi adapter work under Debian Buster by creating the file
/lib/udev/rules.d/70-wifi.rules
which contains this single line (address comes from device name "wlx74dada1c2b5d"):
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="74:da:da:1c:2b:5d", NAME="wlan0"
After rebooting the Debian Buster system with that file in place, the D-link usb wifi adapter works, and "ip link" shows the now shorter device name, "wlan0":
wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group default qlen 1000
link/ether 74:da:da:1c:2b:5d brd ff:ff:ff:ff:ff:ff
The workaround solution comes from:
https://askubuntu.com/questions/826325/how-to-revert-usb-wifi-interface-name-from-wlxxxxxxxxxxxxx-to-wlanx
The discussion in that thread mentions a (Ubuntu studio) kernel having a low latency, wondering whether the long device name is the source of the problem?
I have not tried forcing names other than "wlan0" to determine whether it is "wlan0" that is magical or whether other names would work.
I would expect the D-link usb wifi adapter to work under Debian Buster without this workaround, as the adapter works fine under Jessie.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages firmware-ralink depends on:
ii firmware-misc-nonfree 20180825+dfsg-1
firmware-ralink recommends no packages.
firmware-ralink suggests no packages.
-- no debconf information
============== END of BUG REPORT FILED ================
===== ADDITIONAL INFORMATION SENT TO BUG LIST =========
Concerning bug 914920, sorry, the subject line ought to be something like "firmware rt2870 cannot connect until device name is shortened"
Here's more information about the firmware being
loaded when the system detects the D-link DWA-130 usb wifi adapter.
$ "dmesg | grep rt" excerpts:
[ 7.617423] ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5392, rev 0223 detected
[ 7.632788] ieee80211 phy0: rt2x00_set_rf: Info - RF chipset 5372 detected
[ 7.683411] usbcore: registered new interface driver rt2800usb
[ 241.595520] ieee80211 phy0: rt2x00lib_request_firmware: Info - Loading firmware file 'rt2870.bin'
[ 241.602284] rt2800usb 2-2:1.0: firmware: direct-loading firmware rt2870.bin
[ 241.602293] ieee80211 phy0: rt2x00lib_request_firmware: Info - Firmware detected - version: 0.36
===== END ADDITIONAL INFORMATION SENT TO BUG LIST =========
After a day or so, the maintainer of the package firmware-ralink closed the bug report, saying "This has nothing to do with firmware-ralink. Neither the firmware nor the driver cares what the device name is."
OK, fine, but how should I now proceed at this point?
I'd like to help the community correct what seems to be a problem somewhere in the linux networking system, possibly specific to wifi, but I have NO IDEA what package to mention when filing a new bug report if it wouldn't be firmware-misc-nonfree.
Thanks for any advice!
-- Craig
Reply to: