[SOLVED] renaming network device: 2 approaches/both failing

hwallace · 2022-09-27 23:01:58

I have a USB-ethernet adapter

lshw -class network
...
       bus info: usb@2:2.3
       logical name: enp0s20f0u2u3
       serial: ab:12:cd:34:ef:56
...

I want to rename this to usb01

I find there are two approaches: through udev directly, and through systemd

Neither is working.

Here's the udev setup

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="ab:12:cd:34:ef:56", NAME="usb01"

And the journal's logging for

journalctl -r -b -u systemd-udevd

    mtp-probe[1333]: bus: 2, device: 4 was not an MTP device
    mtp-probe[1333]: checking bus 2, device 4: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2.3"
    mtp-probe[1325]: bus: 2, device: 5 was not an MTP device
    mtp-probe[1325]: checking bus 2, device 5: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2.4"
    mtp-probe[1296]: bus: 2, device: 5 was not an MTP device
    mtp-probe[1296]: checking bus 2, device 5: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2.4"
    mtp-probe[1295]: bus: 2, device: 4 was not an MTP device
    mtp-probe[1295]: checking bus 2, device 4: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2.3"
    mtp-probe[635]: bus: 1, device: 4 was not an MTP device
    mtp-probe[636]: bus: 1, device: 5 was not an MTP device
    mtp-probe[636]: checking bus 1, device 5: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"
    mtp-probe[634]: bus: 1, device: 6 was not an MTP device
    mtp-probe[635]: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.3"
    mtp-probe[634]: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4"
    mtp-probe[530]: bus: 1, device: 4 was not an MTP device
    mtp-probe[530]: checking bus 1, device 4: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.3"
    mtp-probe[529]: bus: 1, device: 6 was not an MTP device
    mtp-probe[529]: checking bus 1, device 6: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1/1-1.4"
    mtp-probe[510]: bus: 1, device: 5 was not an MTP device
    mtp-probe[510]: checking bus 1, device 5: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-3"
    systemd-udevd[294]: could not read from '/sys/module/pcc_cpufreq/initstate': No such device
    systemd[1]: Started Rule-based Manager for Device Events and Files.
    systemd-udevd[267]: Using default interface naming scheme 'v251'.

I also have a udevadm monitor process running and there's this

appending {'action': 'ACTION=change', 'subsystem': 'SUBSYSTEM=net'}

There is no change. Even after a full reboot.

The systemd approach is through a systemd.link file. We have to remove the udev rule so I do that and I add this file to /etc/systemd/network

1-usb01.link

[Match]
MACAddress=ab:12:cd:34:ef:56

[Link]
Name=usb01

After reboot there is still no effect.

Last edited by hwallace (2022-09-28 22:42:50)

Lone_Wolf · 2022-09-28 11:11:30

https://wiki.archlinux.org/title/Networ … rface_name only lists one method, using udev .

a few things to check / try :

usb01 kinda feels like it may be a reserved name, does using a fantasy name like best-usb-ethernet-ever1 make a difference ?

Maybe the mac address is dynamically changed, have you tried DEVPATH or idVendor & idProduct ?

hwallace · 2022-09-28 22:42:04

Lone_Wolf wrote:

https://wiki.archlinux.org/title/Networ … rface_name only lists one method, using udev .
a few things to check / try :
usb01 kinda feels like it may be a reserved name, does using a fantasy name like best-usb-ethernet-ever1 make a difference ?
Maybe the mac address is dynamically changed, have you tried DEVPATH or idVendor & idProduct ?

Thanks.

Yes, yess.... The systemd solution I found while wandering away from home.

I see you don't like systemd, but there it is so...

After tinkering with your suggestions - to no avail - I tried another adapter. It took the new name and so there you go.

It's a puzzle because the 'bad' adapter was perfectly fine in all other respects.

seth · 2022-09-29 07:19:30

Does the "bad" adapter respond to the rule after the boot?
See Lone_Wolf's link - at the bottom, right above the blue note.
Don't foget to take the NIC down.

hwallace · 2022-09-30 21:31:58

seth wrote:

Does the "bad" adapter respond to the rule after the boot?
See Lone_Wolf's link - at the bottom, right above the blue note.
Don't foget to take the NIC down.

No change after boot. I did run

ip link set dev <device> down
ip link set dev <device> up

Is that what you mean?

seth · 2022-10-01 06:32:26

This would set the device down and back up, but setting it down might not succeed if it's in use (check "ip a") and you'd still have to trigger the udev rule inbetween ("udevadm --debug test /sys/class/net/*")

The idea is that the udev rule cannot apply during the boot because the device is already in use when it's triggered.

Arch Linux

#1 2022-09-27 23:01:58

[SOLVED] renaming network device: 2 approaches/both failing

#2 2022-09-28 11:11:30

Re: [SOLVED] renaming network device: 2 approaches/both failing

#3 2022-09-28 22:42:04

Re: [SOLVED] renaming network device: 2 approaches/both failing

#4 2022-09-29 07:19:30

Re: [SOLVED] renaming network device: 2 approaches/both failing

#5 2022-09-30 21:31:58

Re: [SOLVED] renaming network device: 2 approaches/both failing

#6 2022-10-01 06:32:26

Re: [SOLVED] renaming network device: 2 approaches/both failing

Board footer