Re: I'd like help reporting an anomaly/bug with wifi and NetworkManager under Buster
On Mon, 3 Dec 2018 09:41:21 -0600
craig macdonald wrote:
> 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.
To provide more useful information, you need to test things using
simpler, lower level tools, such as ifconfig / iwconfig and ip, and
record the terminal output, and even more importantly, the messages
that appear in syslog.
> ==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).
...
> === 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 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."
That certainly sounds correct, although a more helpful / less busy
maintainer might have helped figure out where to reassign the bug.
> 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.
As above, more useful system output would be helpful in figuring out
where the problem lies.
In the non-working configuration, try to use iwconfig / ifconfig / ip
to connect to an access point and bring the interface up, and if it
doesn't work, post the output and logs (copy and paste the exact text
- don't summarize or paraphrase), and we'll see if we can figure out
what's going on.
And thanks for trying to report bugs!
Celejar
Re: I'd like help reporting an anomaly/bug with wifi and NetworkManager under Buster
Hi. Here, at debian-user, we reply to the list so the whole community would benefit from the answers. Writing to a list participant directly can be OK as long as something private is discussed. Which is clearly not the case here. On Mon, Dec 03, 2018 at 01:26:10PM -0600, craig macdonald wrote: > Hi again Reco. > > What would be the best way to "blacklist" > /lib/udev/rules.d/73-usb-net-by-mac.rules? Execute this as a root, verbatim: touch /etc/udev/rules.d/73-usb-net-by-mac.rules update-initramfs -k all -u Reco
Re: I'd like help reporting an anomaly/bug with wifi and NetworkManager under Buster
Hi. On Mon, Dec 03, 2018 at 09:41:21AM -0600, craig macdonald wrote: > 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. Actually you've discovered a Network Manager's inability to associate with AP. You shown nothing that proves something else. > The computer uses NetworkManager to manage the wifi connenction. What's more important is that: 1) The computer in question has udev which likes to rename network interface names to be 'Predictable'. udev can be considered a part of systemd, for the simplicity. 2) The wifi dongle in question is a USB device, so a rather dumb ruleset called 73-usb-net-by-mac.rules applies to it. 3) Network Manager likes to use randomly generated MAC for WiFi AP scanning, but it reverts to a 'native' MAC before actual AP association. 4) There are WiFi dongles which firmware does not allow you to change their MAC, but Ralink does not have this deficiency. Remove a single variable from this and it solves the problem: 1) Make a network interface name in question static. Any name that does not depends on MAC should do the trick. 2) Blacklist 73-usb-net-by-mac.rules. Does more harm than good anyway. 3) Remove Network Manager and use wpa_supplicant which *is* the cornerstone of Linux wireless networking. 4) Or use PCI Wifi, not USB one. > 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). ... > 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." The maintainer is correct. One should fix Network Manager, or udev rule, or convince systemd upstream to ditch this '(Un)Predictable Network Interface Names', but there's nothing to fix in either the firmware or the kernel. > OK, fine, but how should I now proceed at this point? See above. > I'd like to help the community correct what seems to be a problem somewhere > in the linux networking system, No that's not the problematic part if you mean the kernel. And there's nothing wrong in udev. And whoever wrote that AP-scanning part in Network Manager surely had the best intentions (users' privacy and the like). > possibly specific to wifi, Nope. Any USB-provided NIC can be 'broken' the same way. > but I have NO IDEA what package to mention Network Manager, of course. Unless you can prove (with a simple reproducible wpa_supplicant/iproute combo) otherwise. Reco
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
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: 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: 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: 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-wlx-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:
