Your message dated Sat, 9 Nov 2019 02:28:46 +0100
with message-id <1bf2ccb2-44d4-b6f6-dd99-5c5ae9c66...@debian.org>
and subject line Re: More information, testing using .link files to rename iface
has caused the Debian Bug report #933967,
regarding Predictable interface names results in forced deauth of certain usb
wifi adapters
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
933967: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933967
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
package: systemd
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.
--- End Message ---
--- Begin Message ---
On Sat, 5 Oct 2019 02:28:21 +0200 Michael Biebl <bi...@debian.org> wrote:
> >> Hm, you probably need to blacklist
> >> /lib/udev/rules.d/73-usb-net-by-mac.rules. You can do that by creating a
> >> file /etc/udev/rules.d/73-usb-net-by-mac.rules pointing at /dev/null
> >>
> >> After that (and running update-initramfs -u), 70-wifi.link should become
> >> active and you should be able to test, if incrementally increasing the
> >> length of the iface name at some point triggers the problem.
> >>
> >
> >
> > Any news here?
> >
> > Unfortunately I seem to lack the hardware to reproduce the issue so it
> > would be great for someone affected by this to try and help help.
>
>
> Another friendly ping.
>
> Without further investigation and someone willing to help debug this
> there is not a lot we can do.
Closing at this point, as we don't have enough information to further
investigate this issue.
Regards,
Michael
--
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
--- End Message ---
