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

==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. The D-Link DWA-130 usb wifi adapter is able to see the
nearby wifi routers and to connect to the internet via any local wifi router for which I have the appropriate 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)