Header Shadow Image


Linux Networking: Persistent naming rules based on MAC for eth0 and wlan0

PROBLEM

You've got a set of devices but their names, such as NIC / Network card names keep changing on each reboot or reconnect.  This is a continuation of Linux Networking: device eth0 does not seem to be present, delaying initialization.  where we resolved a similar issue due to naming but here we'll make it persistent using this simple naming system for Linux.  At the end of this very short post, we'll have a constant name for our physical device on reboots.  In particular, it is to make the line ip link set dev wlan1 name wlan0 permanent across reboots.

SOLUTION

To solve this, we'll use UDEV rules to give a certain device a persistent name.  We'll use the 70-persistent-net.rules file to do just that so our network interfaces keep coming up with the same name on reboots or replugging.

# cat /etc/udev/rules.d/70-persistent-net.rules

# PCI device 0x10ec:0×8168 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="1c:6f:35:3f:da:14", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# USB device 0x0cf3:0×1002 (usb) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:15:86:f1:65:d5", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlan0"

#

There's several ways to get parameters for the devices you have.  Most notable is lspci that we can use here:

# lspci -s 03:00.0
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
#

Add some -v[v....] options for verbosity to see more details.   Another way, which is probably the most common, is to use netstat or ifconfig to get your MAC address and other parameters you can use with which to uniquely define your rules:

# netstat -anevi
Kernel Interface table
bond0     Link encap:Ethernet  HWaddr 1c:6f:35:3f:da:14 
          inet addr:192.168.0.8  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::1e6f:65ff:fe3f:fc14/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:53255 errors:0 dropped:0 overruns:0 frame:0
          TX packets:41224 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:28013914 (26.7 MiB)  TX bytes:4811379 (4.5 MiB)
 

Or ifconfig bond0 which would provide the exact same thing as above.  Another way still is to use udev itself to get more information on your device in this manner:

# udevadm info -a -p /sys/class/net/eth0 2>&1|grep -i "ATTR{address}"
    ATTR{address}=="1c:6f:35:3f:da:14"
#

If you have bonding setup, all MAC's may appear the same.  The way to find out the unique ones for each interface is with this command:

[root@mbpc bonding]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009)

Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: eth0
MII Status: down
Speed: 10 Mbps
Duplex: half
Link Failure Count: 0
Permanent HW addr: 1c:6f:65:3f:fc:14
Slave queue ID: 0

Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 90:e2:ba:1a:08:28
Slave queue ID: 0
[root@mbpc bonding]#

Hope you found this useful.  Feel free to leave a reply!

Cheers!
TK

5 Responses to “Linux Networking: Persistent naming rules based on MAC for eth0 and wlan0”

  1. Since I am semi-dumb today, would just changing NAME=”eth0″ to something else work? Rebooting it seems to keep it persistant, but what causes the autogenerated script to generate again since the laptop I am working on once configure is being shipped to a remote location with no network connection (its going to be a local static IP for IP electronics, so no external network rather – so i will not be able to remote in to fix)

  2. Hey Jon,

    Correct. You should be able to change NAME=”eth0″ to the name you want. So things like NAME=”MyLocalNetwork” for example should also work. Here’s a sample of how this link is created on my system by the above udev rule:

    # ls -al /sys/class/net/eth0
    lrwxrwxrwx 1 root root 0 Feb 29 19:01 /sys/class/net/eth0 -> ../../devices/pci0000:00/0000:00:0d.0/net/eth0
    #

    … what causes the autogenerated script to generate again
    udev rules are interpreted by the udevd daemon and the affiliated infrastructure. Try ps aux|grep -i udevd.

    …its going to be a local static IP ….
    Should not affect this. For example, if your eth0 has IP 67.76.53.35 the same eth0 would have something like 192.168.0.10 for example on the clients internal static network. They’ll of course have to change the static external IP for their own static internal IP so some degree of Linux skills would be required. :)

    Cheers!
    TK

  3. Very helpful – both articles. Thank you

  4. Right, but my problem was, the networking service didn’t reload because eth0 became something else, the laptop is Fedora 16, even though at the time I had two network devices, a PCMCIA card which was on my 10.x.x.x network which was outside world addressable, and internal, which I wanted to be eth1, for a local static ip which wasn;t world addressable. For some reason, the internal one got the pc01 something another, and the pcmcia one got em1. I changed the persistant network rules so it doesnt rename it, made the network scripts ifcfg-eth0 and 1 respectively, and all was good. Howver, after rebooting, the eth1 became pc01 once again in /sys/class/net so the actual device eth1 didnt know where it was pointing to, thus /etc/rc.d/init.d/network restart failed until i ran that ip set command, or now renaming the device in that other conf script. i never seen this before and it was driving me bonkers, but since i found out where its going to cant have external network, i thought it was fine, until i realised it was the internal integrated network that was causing hte issues (dunno why it said it was the pcm01 rather than em1 since em/eth is supposed to been meant for integrated, according to Fedoras own documentation.

    Shame I couldnt had used Debian, but your tutorials were very helpful (and so was your patience with me!)

  5. Hey Jon,

    No Problem and You’re Welcome.

    Cheers!
    TK

Leave a Reply

 

     
  Copyright © 2003 - 2013 Tom Kacperski (microdevsys.com). All rights reserved.

Creative Commons License
This work is licensed under a Creative Commons Attribution 3.0 Unported License