search

raspberrypi / bookworm-feedback

12 stars 1 forks source link

Predictable network names broken for ASIX USB ethernet in kernel 6.6.20 #239

Open gitbls opened 3 months ago

gitbls commented 3 months ago

According to this post it worked prior to 6.6, but it doesn't now. Steps:

Mar 20 16:53:30 pt kernel: usb 4-1.2: new SuperSpeed USB device number 4 using xhci-hcd
Mar 20 16:53:30 pt kernel: usb 4-1.2: New USB device found, idVendor=0b95, idProduct=1790, bcdDevice= 1.00
Mar 20 16:53:30 pt kernel: usb 4-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mar 20 16:53:30 pt kernel: usb 4-1.2: Product: AX88179
Mar 20 16:53:30 pt kernel: usb 4-1.2: Manufacturer: ASIX Elec. Corp.
Mar 20 16:53:30 pt kernel: usb 4-1.2: SerialNumber: 0000000000093B
Mar 20 16:53:30 pt mtp-probe[3343]: checking bus 4, device 4: "/sys/devices/platform/axi/1000120000.pcie/1f00300000.usb/xhci-hcd.1/usb4/4-1/4-1.2"
Mar 20 16:53:30 pt mtp-probe[3343]: bus: 4, device: 4 was not an MTP device
Mar 20 16:53:30 pt NetworkManager[771]: <info>  [1710978810.3314] manager: (eth1): new Ethernet device (/org/freedesktop/NetworkManager/Devices/3)
Mar 20 16:53:30 pt kernel: ax88179_178a 4-1.2:1.0 eth1: register 'ax88179_178a' at usb-xhci-hcd.1-1.2, ASIX AX88179 USB 3.0 Gigabit Ethernet, 5a:42:73:19:ee:e6
Mar 20 16:53:30 pt kernel: usbcore: registered new interface driver ax88179_178a
Mar 20 16:53:30 pt mtp-probe[3347]: checking bus 4, device 4: "/sys/devices/platform/axi/1000120000.pcie/1f00300000.usb/xhci-hcd.1/usb4/4-1/4-1.2"
Mar 20 16:53:30 pt mtp-probe[3347]: bus: 4, device: 4 was not an MTP device
Mar 20 16:53:30 pt NetworkManager[771]: <info>  [1710978810.4256] device (eth1): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external')
Mar 20 16:53:31 pt NetworkManager[771]: <info>  [1710978811.1753] settings: (eth1): created default wired connection 'Wired connection 1'
Mar 20 16:53:56 pt kernel: usb 4-1.2: USB disconnect, device number 4
Mar 20 16:53:56 pt kernel: ax88179_178a 4-1.2:1.0 eth1: unregister 'ax88179_178a' usb-xhci-hcd.1-1.2, ASIX AX88179 USB 3.0 Gigabit Ethernet
Mar 20 16:53:56 pt NetworkManager[771]: <info>  [1710978836.1728] device (eth1): state change: unavailable -> unmanaged (reason 'removed', sys-iface-state: 'removed')
Mar 20 16:54:03 pt systemd-logind[709]: The system will reboot now!
lowflyerUK commented 3 months ago

FWIW on my P14B fully updated Lite, 64bit:

udevadm info /sys/class/net/eth0 does not have an entry for ID_NET_NAME_MAC for my ax88179_178a USB ethernet interface - whereas my r8152 has ID_NET_NAME_MAC=enx70886bXXXXXX

udevadm info /sys/class/net/eth0 --attribute-walk gives ATTR{addr_assign_type}=="1" for ax88179_178a - whereas r8152 gives ATTR{addr_assign_type}=="0". kernel docs say that addr_assign_type equals 1 means that the MAC address is randomly generated (which in this case it isn't). addr_assign_type equals 0 means permanent address.

lurch commented 3 months ago

the MAC address is randomly generated (which in this case it isn't)

I see in @gitbls 's logs that he gets a different MAC address for his ASIX AX88179 USB 3.0 Gigabit Ethernet each time - 5a:42:73:19:ee:e6 and c2:cb:e8:61:e8:94 ?

gitbls commented 3 months ago

the MAC address is randomly generated (which in this case it isn't)

I see in @gitbls 's logs that he gets a different MAC address for his ASIX AX88179 USB 3.0 Gigabit Ethernet each time - 5a:42:73:19:ee:e6 and c2:cb:e8:61:e8:94 ?

I hadn't noticed that. Why would that happen for the ASIX but not for the built-in ethernet? I have not modified /etc/NetworkManager/NetworkManager.conf which has [device]\n wifi.scan-rand-mac-address=no

And, does this weigh on why the predictable network name is not applied? If so, how?

lowflyerUK commented 3 months ago

That's interesting. Mine is not random. It has been the same for many years using previous versions of RaspiOS and it has alos been the same every boot in the last few days using the latest version.

lurch commented 3 months ago

Is it possible that some versions of this USB dongle have a ROM (and thus a fixed MAC address) but other versions don't have a ROM, and so expect to get a randomly-generated MAC address? Just a wild guess...

gitbls commented 3 months ago

Is it possible that some versions of this USB dongle have a ROM (and thus a fixed MAC address) but other versions don't have a ROM, and so expect to get a randomly-generated MAC address? Just a wild guess...

Maybe. But the particular adapter I'm using (a Cable Matters USB 3.0 device) is several years old, and always gets the same MAC address on, for example, Windows. Its MAC address is included in my DHCP server and always gets the same IP address.

lurch commented 3 months ago

Huh, so the MAC address seen by your DHCP server is different to the MAC address that gets displayed in your kernel logs? @pelwell Should this issue be moved to the linux repo?

gitbls commented 3 months ago

Huh, so the MAC address seen by your DHCP server is different to the MAC address that gets displayed in your kernel logs? @pelwell Should this issue be moved to the linux repo?

TBH I didn't connect the ASIX to the network when I did the above test. I can do further testing today, LMK what would be most helpful in sorting this.

lowflyerUK commented 3 months ago

Just to be clear, my ASIX interface gives the same MAC address to the DHCP server as it is displayed in the kernel logs.

If it helps, the reason that I noticed the issue was that my router failed after the upgrade to kernel 6.6.20 (from 6.1). My old and trusted udev rule that gave a predictable name failed for the first time: SUBSYSTEM=="net", ACTION!="remove", ATTR{address}=="12:34:56:78:9A:BC:DE", NAME="myNET" On investigating I found that the official predictable names system also failed.

pelwell commented 3 months ago

Strange. With an RTL8153-based USB Gigabit Ethernet Adapter and predictable names enabled I get:

end0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
...
enx????????????: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
...

That's with the latest apt kernel:

Linux raspberrypi 6.6.20+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-07) aarch64 GNU/Linux

But it is a full (non-Lite) image.

pelwell commented 3 months ago

And do you have any idea why your udev rule failed, if your MAC address hasn't changed?

gitbls commented 3 months ago

Strange. With an RTL8153-based USB Gigabit Ethernet Adapter and predictable names enabled I get:

end0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
...
enx????????????: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
...

That's with the latest apt kernel:

Linux raspberrypi 6.6.20+rpt-rpi-2712 #1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-07) aarch64 GNU/Linux

But it is a full (non-Lite) image.

I'll put up a "with desktop" version and try the ASIX with it.

6by9 commented 3 months ago

I have an AX88179 here, and can confirm that I get eth0 rather than a predictable name. The genet interface is end0 as expected.

2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
...
3: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN group default qlen 1000

MAC address is consistent. x86 Ubuntu 20.04 on a 5.15 kernel is giving predictable names. I can't test a more recent kernel on x86 easily.

gitbls commented 3 months ago

Ah, just tested a vanilla "with desktop". Same behaviour (eth0 rather than predictable name), but still seeing the MAC address change from 26:4d:96:45:c3:8c (before setting predictable names) to a0:ce:c8:03:80:a9 after setting predictable and rebooting.

BTW, neglected to mention previously, a0:ce:c8:03:80:a9 is the device's actual MAC address (it's taped onto the device 🤣), so weird that it changes in the non-predictable case.

lowflyerUK commented 3 months ago

My r8152 card also gives the expected predictable name enxXXXXXXXXXXX. My issue is only with my ax88179_178a USB ethernet adapters.

No, I don't have any idea why my udev rule fails. It never gets my name at boot or when the USB is hot-plugged in. However it does get my name if I run sudo udevadm -d trigger --action="add"

I have had a look with sudo udevadm monitor -p when plugging in the ax88179_178a compared to the r8152. Apart from noting that eventually the r8152 comes up with a KERNEL move from old name /devices/../../net/eth1 to /devices/../../net/myNET and the ax88179_178a doesn't.

Looking at udevadm info /sys/class/net/eth0 --attribute-walk (the ax88179_178a came up as eth0 this time), I see ATTR{addr_assign_type}=="1" But with the r8152 I always get ATTR{addr_assign_type}=="0" It would be sensible not to use the MAC to form the enx style name if the device states the address is random!

My ax88179_178a always comes up at boot with the same MAC address. I have never observed any different MAC address.

6by9 commented 3 months ago

I'm testing previous kernel releases to try and pin it down. 6.3 and 6.4 give predictable names on a Pi4.

6by9 commented 3 months ago

6.5.13 is also OK. 6.6.21 fails. For completeness, 6.8.1 also fails.

And the best bit is that there appear to be no direct changes to the AX88179 driver in 6.6, so it's looking to be a framework change with unintended consequences.

6by9 commented 3 months ago

Cause found.

usbnet_probe is setting addr_assign_type to _RANDOM. ax88179_reset comes along later, and calls ax88179_get_mac_addr to set the address, but never clears the flag.

I'd missed one backported commit (https://github.com/raspberrypi/linux/commit/d7a319889498a1542470dd461c8e9022f3ef75f4 in 6.6, https://github.com/raspberrypi/linux/commit/d2689b6a86b9d23574bd4b654bf770b6034e2c7e in 6.8) which removes an extra call to ax88179_reset from bind. That call would have set the MAC address, and hence avoided usbnet_probe setting the RANDOM flag in the first place.

We can revert that locally, but it needs reporting upstream.

gitbls commented 3 months ago

You guys rock!

lowflyerUK commented 3 months ago

@6by9 You are a genius! But I expect you already know that! Thanks.

6by9 commented 3 months ago

Thanks Phil for reverting. I'll sort out reporting it upstream tomorrow.

6by9 commented 3 months ago

Reported upstream and acknowledged. They're looking into the proper fix. https://lore.kernel.org/netdev/20240325121756.456684-1-jtornosm@redhat.com/T/#t

gitbls commented 3 months ago

Thx for the update, @6by9

6by9 commented 3 months ago

Fix proposed upstream - https://lore.kernel.org/netdev/20240326092459.GG403975@kernel.org/T/ As it's cc'ed stable, it should get backported automagically to 6.6.

pjgoodall commented 3 weeks ago

I believe have a related problem on Proxmox

I have a Startech USB32000SPT USB 3.0 to Dual Port Gigabit Ethernet Adapter, which a year ago installed correctly on my system. It has an ASIX - AX88179A chip. When I try to configure it, it does not get predictable network names, and the two ports are given identical MAC addresses.

On the same system I have a single port usb nic with the same chip, which has been onboard for 12 months or so. It runs correctly and retains the predictable network name, and uses the MAC address printed on its case.

12 months ag - the double nic configured itself correctly with the manufacturer's MAC addresses.