Bug#933967: Predictable interface names results in forced deauth of certain usb wifi adapters

[Michael Biebl]

Control: tags -1 + moreinfo

Am 05.08.19 um 17:32 schrieb Kathryn Tolsen:
> package: systemd

Which version is this?

> I had first observed this issue with Stretch and my Netgear WG111v3
> (RTL8168B chipset) using the rtl8168 driver over a year ago, and had a
> rough time running down the culprit and had discovered that disabling
> predictable ifnames with net.ifnames=0 resolved the issue.
> 
> Last night in #debian on freenode, a user came in with issues with a
> completely different device using a different driver and the problem had
> seemed familiar, and I recommended disabling the predictable ifnames,
> and it resolved their issue as well.
> 
> Information from this recent issue on Buster is as follows:
> 
> lsusb:
> Bus 001 Device 008: ID 148f:5372 Ralink Technology, Corp. RT5372
> Wireless Adapter
> 
> dmesg:
> ieee80211 phy1: rt2x00lib_request_firmware: Info - Loading firmware file
> 'rt2870.bin'
> rt2800usb 1-1:1.0: firmware: direct-loading firmware rt2870.bin
> ieee80211 phy1: rt2x00lib_request_firmware: Info - Firmware detected -
> version: 0.36
> 
> usb 1-1: new high-speed USB device number 8 using xhci_hcd
> usb 1-1: New USB device found, idVendor=148f, idProduct=5372, bcdDevice=
> 1.01
> usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-1: Product: 802.11 n WLAN
> usb 1-1: Manufacturer: Ralink
> 
> wlx9cefd5fdf30b: authenticate with 90:4c:81:01:76:00
> wlx9cefd5fdf30b: send auth to 90:4c:81:01:76:00 (try 1/3)
> wlx9cefd5fdf30b: authenticated
> wlx9cefd5fdf30b: authenticate with 90:4c:81:01:76:00
> wlx9cefd5fdf30b: send auth to 90:4c:81:01:76:00 (try 1/3)
> wlx9cefd5fdf30b: authenticated
> wlx9cefd5fdf30b: authenticate with 90:4c:81:01:76:00
> wlx9cefd5fdf30b: send auth to 90:4c:81:01:76:00 (try 1/3)
> wlx9cefd5fdf30b: authenticated
> wlx9cefd5fdf30b: aborting authentication with 90:4c:81:01:76:00 by local
> choice (Reason: 3=DEAUTH_LEAVING)
> IPv6: ADDRCONF(NETDEV_UP): wlx9cefd5fdf30b: link is not ready
> IPv6: ADDRCONF(NETDEV_UP): wlx9cefd5fdf30b: link is not ready
> 
> I am not sure where the problem lies.. in the kernel, firmware, systemd,
> udev.. idk.. but I'd had the same symptoms before with the Netgear
> adapter and rtl8168 where it would list APs attempt to connect,
> authenticate then forcibly deauth citing Reason 3, DEAUTH_LEAVING and
> say the link was not ready.. 
> 
> I had spent hours trying to figure it out when I came across an obscure
> post online that suggested it was a firmware bug related to predictable
> ifnames, and after disabling them and that resolving my issue I had
> ignored it as an obscure bug not likely to affect many users. 
> 
> Now however I am realizing that whatever this issue is, its far more
> widespread than I thought and is possibly more central and less related
> to specific adapters. Since we are now using systemd/udev predictable
> ifnames by default I figured this was something we need to run down. 
> 
> If I can provide any more information on the subject, please let me know
> as I do still have the Netgear WG111v3 adapter that I know causes this
> issue.

I've never seen this issue before. This smells like a driver problem to me.
Is the problem the long interface name or the fact that the interface
has been renamed?

Could you create a file /etc/systemd/network/70-wifi.link containing:
[Match]
MACAddress=90:4c:81:01:76:00

[Link]
Name=wifi0


(run update-initramfs -u and reboot)
Is the problem still reproducible then?
What if you make the Name= longer bit by bit
wifi01, wifi012, wifi0123 etc.








-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20190806/c0c0b3a9/attachment-0001.sig>