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 <sub...@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
