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?
signature.asc
Description: OpenPGP digital signature
