(Sorry for back-to-back replies, hadn't noticed this when I wrote the previous mail)
David Laight wrote on Mon, Dec 02, 2024 at 08:17:59AM +0000:
So we hit the exact inverse problem with this patch: our device ships an LTE modem which exposes a cdc-ethernet interface that had always been named usb0, and with this patch it started being named eth1, breaking too many hardcoded things expecting the name to be usb0 and making our devices unable to connect to the internet after updating the kernel.
Erm does that mean your modem has a locally administered MAC address? It really shouldn't.
Unfortunately, that's what it gives us: # ip a show dev eth1 4: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 02:80:72:78:15:10 brd ff:ff:ff:ff:ff:ff
# udevadm info /sys/class/net/eth1 P: /devices/platform/soc/2100000.bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1:1.0/net/eth1 E: DEVPATH=/devices/platform/soc/2100000.bus/2184200.usb/ci_hdrc.1/usb2/2-1/2-1:1.0/net/eth1 E: ID_BUS=usb E: ID_MM_CANDIDATE=1 E: ID_MODEL=GTO E: ID_MODEL_ENC=GTO E: ID_MODEL_ID=00a0 E: ID_NET_NAME_MAC=enx028072781510 E: ID_REVISION=0307 E: ID_SERIAL=Gemalto_GTO_101578728002 E: ID_SERIAL_SHORT=101578728002 E: ID_TYPE=generic E: ID_USB_DRIVER=cdc_ether E: ID_USB_INTERFACES=:020600:0a0000:020201: E: ID_USB_INTERFACE_NUM=00 E: ID_VENDOR=Gemalto E: ID_VENDOR_ENC=Gemalto E: ID_VENDOR_ID=1e2d E: IFINDEX=4 E: INTERFACE=eth1 E: NM_UNMANAGED=1 E: SUBSYSTEM=net E: USEC_INITIALIZED=23339186
(that mac is stable accross reboots)
afaiu, this modem generates a pointtopoint ethernet device and then routes packets sent there to LTE.
I've just checked what my phone does when I do USB tethering and it's pretty similar, the mac is also a local 02:xx mac (02:36:05) which is also not in OUI lookup tables. (the only difference is, I plugged it on my laptop which runs systemd, so it got named enx023605xxxxxx and none of this matters..)
+++ b/drivers/net/usb/usbnet.c @@ -1767,7 +1767,8 @@ usbnet_probe (struct usb_interface *udev, const struct usb_device_id *prod) // can rename the link if it knows better. if ((dev->driver_info->flags & FLAG_ETHER) != 0 && ((dev->driver_info->flags & FLAG_POINTTOPOINT) == 0 ||
(net->dev_addr [0] & 0x02) == 0))
/* somebody touched it*/!is_zero_ether_addr(net->dev_addr)))... or actually now I'm looking at it again, perhaps is the check just backwards, or am I getting this wrong? previous check was rename if (mac[0] & 0x2 == 0), which reads to me as "nobody set the 2nd bit" new check now renames if !is_zero, so renames if it was set, which is the opposite?...
The 2nd bit (aka mac[0] & 2) is the 'locally administered' bit. The intention of the standard was that all manufacturers would get a valid 14-bit OUI and the EEPROM (or equivalent) would contain an addresses with that bit clear, such addresses should be globally unique. Alternatively the local network administrator could assign an address with that bit set, required by protocols like DECnet.
This has never actually been strictly true, a few manufacturers used 'locally administered addresses' (02:cf:1f:xx:xx:xx comes to mind) and systems typically allow any (non-broadcast) be set.
So basing any decision on whether a MAC address is local or global is always going to be confusing.
Thank you for the explanation, I now understand the old check better -- point to point devices that are a local MAC addresses (0x2 set) would get to keep the usb0 name.
The new check however no longer cares about the address globality, and just basically always renames the interface if the driver provided a mac ?
If that is what was intended, I am fine with this, but I think these local ppp usb interfaces are rather common in the cheap modem world.
Linux will allocate a random (locally administered) address if none is found - usually due to a corrupt eeprom.
Thanks,