0

I am trying to assign persistent names to network interfaces on a Linux Mint 21.3 PC. This particular PC often has PCIe devices added and removed, so the 'predictable' naming scheme of enpXs0 is inconvenient.

This PC has two ethernet controllers, one on the motherboard, and one on a PCIe add-in card. I am able to define the motherboard ethernet port as lan0 using both using udev rules, and using systemd, but trying to define the PCIe add-in card as lan1 using the same methods is failing, and this is instead being assigned as enpXs0.

Here is the udev rules file:

#/etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="<mac for motherboard lan0>", NAME="lan0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="<mac for PCIe lan1>", NAME="lan1"

And here is the systemd link. This example is for lan0, but the file is identically structured for lan1:

#/etc/systemd/network/10-persistent-lan0.link
[Match]
MACAddress=<mac for motherboard lan0>

[Link]
Name=lan0

The only meaningful difference I can determine between the two cards their physical form factor. This of course means that they have different PCIe addresses as well. The PCIe add-in card (lan1) will eventually be configured with a static IP and set up to respond to RARP requests on a small private network, but all of that configuration was set up with a different interface name (not the assigned or the target) -- think RARP is set up on enp2s0, and the card is being initially assigned enp3s0, then attempted renaming to lan1 -- so I don't see why this would make a difference.

What would cause the add-in card to behave differently than the integrated card? I have looked at several other questions that deal with issues in naming of all the interfaces on a PC, but have not come across any topics that deal with specifically

Improve this question
3
  • What operating system are you using? Edit your question to include this vital information
    – Ramhound
    Commented Apr 22 at 16:28
  • Linux Mint 21.3. Updated.
    – user18
    Commented Apr 22 at 16:31
  • Are you using any VLANs on this machine? Can you search the system logs (journalctl -b) for any mentions of the interface, both as enp3s0 and as eth1, and just in case also as lan1?
    – grawity_u1686
    Commented Apr 22 at 17:14

2 Answers 2

Reset to default
0

Based on the comment from @u1686_grawity, some digging in the logs revealed a kernel message from the r8169 driver used for the PCIe ethernet card.

r8169 0000:02:00.0: can't read MAC address, setting random one

This is a known bug for this driver in kernel 5.15.x, which my system is running, and appears to be fixed in kernel 5.16. I'm not sure this fully solves the problem, since the random MAC seems to be preserved by a restart (as opposed to shutdown and fresh boot), but perhaps this interaction is why it cannot be properly assigned.

As a workaround for now, I am instead setting the interface based on the driver, as this is the only device using the r8169 driver in this PC. The working udev rule is:

#/etc/udev/rules.d/70-persistent-net.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="<mac for motherboard lan0>", NAME="lan0"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="r8169", NAME="lan1"
Improve this answer
0

The referenced bug was introduced with 5.16 and fixed as part of a 5.16-rc version. In the case here the vendor may have missed to program the NIC with a valid MAC address.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .