> Which version is this?

> Is the problem still reproducible?

root@t440:/home/user# dpkg -l systemd udev linux-image-amd64;cat
/etc/systemd/network/70-wifi.link;dmesg|tail -n 31
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name              Version      Architecture Description
+++-=================-============-============-===================================
ii  linux-image-amd64 4.19+105     amd64        Linux for 64-bit PCs
(meta-package)
ii  systemd           241-5        amd64        system and service manager
ii  udev              241-5        amd64        /dev/ and hotplug
management daemon
[Match]
MACAddress=c4:3d:c7:74:f9:9b

[Link]
Name=wifi0
[   59.833725] usb 1-1: new high-speed USB device number 5 using xhci_hcd
[   59.990838] usb 1-1: New USB device found, idVendor=0846,
idProduct=4260, bcdDevice= 2.00
[   59.990844] usb 1-1: New USB device strings: Mfr=1, Product=2,
SerialNumber=3
[   59.990847] usb 1-1: Product: NETGEAR WG111v3
[   59.990850] usb 1-1: Manufacturer: Manufacturer_NETGEAR
[   59.990852] usb 1-1: SerialNumber: C43DC774F99B
[   60.768528] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[   60.769098] ieee80211 phy1: hwaddr c4:3d:c7:74:f9:9b, RTL8187BvE V0 +
rtl8225z2, rfkill mask 2
[   60.786783] rtl8187: Customer ID is 0x00
[   60.787395] rtl8187: wireless switch is on
[   60.787442] usbcore: registered new interface driver rtl8187
[   60.804006] rtl8187 1-1:1.0 wlxc43dc774f99b: renamed from wlan0
[   60.850461] IPv6: ADDRCONF(NETDEV_UP): wlxc43dc774f99b: link is not ready
[   63.193129] IPv6: ADDRCONF(NETDEV_UP): wlxc43dc774f99b: link is not ready
[   66.147517] IPv6: ADDRCONF(NETDEV_UP): wlxc43dc774f99b: link is not ready
[   66.224888] IPv6: ADDRCONF(NETDEV_UP): wlxc43dc774f99b: link is not ready
[  162.299965] IPv6: ADDRCONF(NETDEV_UP): wlxc43dc774f99b: link is not ready
[  164.571920] wlxc43dc774f99b: authenticate with 8c:3b:ad:cb:08:6e
[  164.909574] wlxc43dc774f99b: send auth to 8c:3b:ad:cb:08:6e (try 1/3)
[  164.911514] wlxc43dc774f99b: authenticated
[  169.910445] wlxc43dc774f99b: aborting authentication with
8c:3b:ad:cb:08:6e by local choice (Reason: 3=DEAUTH_LEAVING)
[  172.471431] wlxc43dc774f99b: authenticate with 8c:3b:ad:cb:08:6e
[  172.797357] wlxc43dc774f99b: send auth to 8c:3b:ad:cb:08:6e (try 1/3)
[  172.799288] wlxc43dc774f99b: authenticated
[  177.801182] wlxc43dc774f99b: aborting authentication with
8c:3b:ad:cb:08:6e by local choice (Reason: 3=DEAUTH_LEAVING)
[  180.740423] wlxc43dc774f99b: authenticate with 8c:3b:ad:cb:08:6e
[  181.081228] wlxc43dc774f99b: send auth to 8c:3b:ad:cb:08:6e (try 1/3)
[  181.085033] wlxc43dc774f99b: authenticated
[  186.082430] wlxc43dc774f99b: aborting authentication with
8c:3b:ad:cb:08:6e by local choice (Reason: 3=DEAUTH_LEAVING)
[  187.168136] IPv6: ADDRCONF(NETDEV_UP): wlxc43dc774f99b: link is not ready
[  190.079680] IPv6: ADDRCONF(NETDEV_UP): wlxc43dc774f99b: link is not ready

this is after creating the above file, runing update-initramfs -u and
rebooting.

I only use this as a backup adapter, rarely.. so I haven't tested it since
Stretch, but the issue on this particular adapter is still reproducible on
Buster.

I could ask the user with the Ralink device to try this as well, if/when I
see them again in #debian if you think that would be helpful, however they
are less experienced and had a rough go of simply adding the net.ifnames=0
to /etc/default/grub and disabling the predictable names that way.

I am going to assume for the time being, whatever is causing the problem
with the more recent issue that user had with the ralink driver based
device is the same issue I am able to reproduce with the rtl8186 device I
have.

I will also note that we've had a user in the channel and systemd channel
as well for days now with issues creating vlan devices where there seem to
be renaming issues that could be related here.. as you can see I made that
link file, asked systemd to rename that device to wifi0 and yet it shows in
dmesg that it was renamed from wlan0 to the wlxc43dc774f99b which seems to
indicate there is some kind of issue with the renaming of interfaces.

If you have any other ideas I'm willing to help run this down, and if you
rather deal with this in real-time on IRC, I'm on both Freenode and OFTC as
'rant' and we could just post the findings here afterward. I personally
prefer IRC and don't pay much attention to email, but I try check it when I
have open issues on the BTS. :D

Reply via email to