# Persistent Names changing on stable multihomed machine

## dbishop

I have a multi-homed choke firewall box with two wired NICs.  The hardware configuration never changes but the machine is frequently cold-started.  One NIC is built in, the other is a PCIe adapter.

The add-in PCIe NIC always shows up as enp3s0.  The built-in NIC flaps back and forth between enp4s0 and enp5s0.  This wreaks havoc on my iptables rules.  As I understand it, these names are derived from the PCI bus enumeration, so I suspect something on this particular motherboard is causing a race condition in the enumerating.  Ironic that it's the built in one, and ironic that it would be a race condition.  None of this matters to me but it is interesting that this goofy convention was supposed to stop a problem I never had while causing the very one it was supposed to prevent.  ANYWAY...

I tried going back to the old (and far more likable) kernel naming via the GRUB_CMDLINE_LINUX="net.ifnames=0" mechanism.  Sure enough, I get eth0 and eth1, but eth0 -- which should get a fixed IP via /etc/conf.d/net but it does not (i.e., config_eth0="172.16.7.1").  Instead I consistently get an apipa-like (169.154) address.  Sometimes I get some spew during start-up like -- can't recall precisely -- "local: waiting for ... 60sec" and it counts down.  eth1 gets an address via dhcp no problem.

I did spend some time early on chasing udev work-arounds a while ago on different machines (never this one, it's always used these idiotic 'persistent' names, not meant to rile anyone, just idiotic IMHO)

I don't mind fixing this any which way, but I was wondering if anyone had any tips on the eth0 issue and creating udev rules. I know that there are many howto's out there but udev seems to be harder to get hold of than a greased pig, and what works is not exactly 'universal'....

I am using:

```
sys-fs/udev-216

sys-boot/grub-2.02_beta2-r3:2

sys-kernel/gentoo-sources-3.17.8-r1:3.17.8-r103:00.0
```

The relevant bits fron the PCI bus look this way (The Realtek interface is built in, the Intel adapter is an expansion card):

```
03:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection

04:00.0 RAID bus controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01)

05:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 09)
```

Any help is be greatly appreciated.

----------

## NeddySeagoon

dbishop,

Write some udev rules to generate interface names based on the MAC addresses of the interfaces.

Avoid the namespaces already in use, since you do not want name collisions.

udev will no longer do renaming for you.

This used to be done automatically for wired interfaces so we had persistant names before udev introduced persistent names.

It was not so good for wifi interfaces that had software assigned (and often random) MAC addresses.  

If you can live with the kernel names and just want them to be persistant, make the kernel drver for the interface that is to be eth0 built in and eth1 as a module.

This eliminates the kernel race as built ins are always enumerated before modules.

You still need to tell udev to keep its hands off your interface naming.

----------

## khayyam

 *NeddySeagoon wrote:*   

> Write some udev rules to generate interface names based on the MAC addresses of the interfaces.

 

dbishop, Neddy ... some weeks back I setup a similar type box for a friend ... not much to it, mostly a stage3 minus udev, and toolchain, plus the addition of iptables and such. I don't have access to the machine so I can only provide similar output from this one:

```
# cat /etc/mactab.conf

# Generated by settle-nics from mdev-like-a-boss.

eth0            xx:xx:xx:xx:xx:xx

wlan0           xx:xx:xx:xx:xx:xx
```

Of course "interface names" can be whatever you want.

best ... khay

----------

## krinn

What you should do ; edit the 70-per...rules file and force matching it thru its mac adress. I don't use the stupid new naming, so i don't know howto do it with it, but here's howto do it with old style (that works for me)

 *Quote:*   

> cat /etc/udev/rules.d/70-persistent-net.rules 
> 
> SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:26:18:2f:cc:06", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
> 
> 

  *Quote:*   

> ifconfig eth0
> 
> eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
> 
>         inet 192.168.0.4  netmask 255.255.255.0  broadcast 192.168.0.255
> ...

 

I'm totally unsure if this still works with udev but it will with eudev-1.9

Note that if you get totally bored by kernel renaming collision, you could just change eth0 to intel0 and config_intel0="172..." to stop the kernel race condition.

----------

## NeddySeagoon

krinn,

That no longer works if the interface name you are trying to assign is already in use.

Hence my advice to avoid names like ethX.

udev used to do interface renaming, so that this wasn't an issue.

The udev devs dropped that, which messed up most systems with two or more interfaces, then a few udev versions later, thay added "persistent" interface names, which upset most users and at the same time fixed a few corner cases that the owners had learned to live with, at the same time, they  created another class of corner cases that took the owners by surprise.

All in all, an utter shambles.

----------

## khayyam

 *NeddySeagoon wrote:*   

> All in all, an utter shambles.

 

... a situation for which the term "omnishambles" was created :)

best ... khay

----------

## dbishop

NeddySeagoon (and others),

Very Grateful.

I am happy to create a udev rule set, seems the simplest. I admit I am a little confused about structure, syntax, and location.  There used to be /etc/udev/rules.d/70-persistent-net.rules and that bit the dust and trashed a whole bunch of work a while back (I have 20 or so Gentoo boxes doing all sorts of things dating back to 2003 or thereabout).  Certain syntax worked, then didn't, then needed arcane options. It was exhausting keeping up.  I used to have this a while ago:

```
# PCI device 0x10ec:0x8167 (r8169)

SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:1b:fc:9f:31:29", KERNEL=="eth*", NAME="eth0"

# PCI device 0x11ab:0x4364 (sky2)

SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:1b:fc:9f:36:a1", KERNEL=="eth*", NAME="eth1"
```

And then there is  /lib64/udev/rules.d/80-net-setup-link.rules. I read somewhere that there is some sort of equivalent for thwarting it in /etc/udev/rules.d/.  I have seen elsewhere people need to symlink whatever workaround to other names in /etc/udev/rules.d to avoid future clobberings. And I'd use eudev if that would help (frankly I am not even sure what the pros and cons are...)

```
# do not edit this file, it will be overwritten on update

SUBSYSTEM!="net", GOTO="net_setup_link_end"

IMPORT{builtin}="path_id"

ACTION=="move", IMPORT{db}="ID_NET_DRIVER"

ACTION!="add", GOTO="net_setup_link_end"

IMPORT{builtin}="net_setup_link"

NAME=="", ENV{ID_NET_NAME}!="", NAME="$env{ID_NET_NAME}"

LABEL="net_setup_link_end"
```

in which, I get the feeling, there should be a way to fix things in this file with something from this (from a different machine):

```
udevadm test-builtin net_id /sys/class/net/eth0 2> /dev/null

ID_NET_NAME_MAC=enx50465d70bee1

ID_OUI_FROM_DATABASE=ASUSTek COMPUTER INC.

ID_NET_NAME_ONBOARD=eno1

ID_NET_LABEL_ONBOARD=en Onboard LAN

ID_NET_NAME_PATH=enp0s25

```

To avoid naming collisions I was thinking to call one 'theo' and the other 'lennart', but if I do that, the box will never stop shouting at itself or it force everything to do things its way or else...   :Razz: 

Seriously, I am happy to write the udev rules -- would they look like the old "70-" structure/syntax? or the new "80-" format? udev seems to change more often than GTK...

----------

## NeddySeagoon

dbishop,

I don't suffer from udev or its 'friends' any more.

----------

## dbishop

No udev?  What else is there? It's hard enough trying to keep systemd off my boxes...

What is the difference/benefit of eudev?

----------

## khayyam

 *dbishop wrote:*   

> No udev? What else is there? It's hard enough trying to keep systemd off my boxes...

 

dbishop ... sys-fs/static-dev (Neddy's favorite), sys-apps/busybox[mdev], sys-fs/mdev-bb::foo-overlay (the latter two can be used with sys-fs/mdev-like-a-boss::foo-overlay) ... and ...

 *dbishop wrote:*   

> What is the difference/benefit of eudev?

 

eudev ... a fork of systemd-udev, basically.

best ... khay

----------

## NeddySeagoon

dbishop,

I use nothing - or more accurately. I have a static /dev with no auto anything.

----------

## dbishop

NeddySeagoon (and others), 

static dev looks interesting, but it would take much longer tom implement than I have available...

Question now is, is it better to switch to eudev or stick with regular udev, and then write some udev rules like this and put it in a file called /etc/udev/rules.d/70-persistent-net.rules?

```
# PCI device 0x10ec:0x8167 (r8169)

SUBSYSTEM=="net", DRIVERS=="?*", ATTR{address}=="00:1b:fc:9f:31:29", KERNEL=="eth*", NAME="eth0"

```

or is there another way?  I have searched and searched for smething specific, but can't find it.  The best I found was http://www.reactivated.net/writing_udev_rules.html and http://wiki.gentoo.org/wiki/Udev but they seem out-of-date

And I still don't understand why GRUB_CMDLINE_LINUX="net.ifnames=0" yields the old eth* names but I can't get /etc/conf.d/net  config_eth0="172.16.7.1" to work

----------

## NeddySeagoon

dbishop,

Post your /etc/conf.d/net file please. 

net.ifnames=0 gets you kernel names, so config_eth0="172.16.7.1" should work too.

----------

## dbishop

Here it is.  You can see some genetic baggage from my wrestling with this thing.  I am not presently using net.ifnames=0, but when I did, I got eth0 and eth1. eth1 dhcpcd correctly (not in the config at all) but eth0 just returned that ridiculous 169.254 nonsense but did not assign the desired 172.16.7.1 IP.

```
# This blank configuration will automatically use DHCP for any net.*

# scripts in /etc/init.d.  To create a more complete configuration,

# please review /usr/share/doc/openrc*/net.example* and save your configuration

# in /etc/conf.d/net (this file :]!)

# globals

searchdomains="test.sys"

nameservers="127.0.0.1"

# local instrumentation network

config_enp3s0="172.16.7.1/24"

config_eth0="172.16.7.1/24"

# upstream interfaces via dhcp

dhcpcd_enp4s0="-C ntp.conf"

config_enp4s0="dhcp"

#fallback_enp4s0="172.16.3.134/25"

#fallback_route_enp4s0="172.16.3.129/25"

dhcpcd_enp5s0="-C ntp.conf"

config_enp5s0="dhcp"

#fallback_enp5s0="172.16.3.134/25"

#fallback_route_enp5s0="172.16.3.129/25"

dhcpcd_eth1="-C ntp.conf"

config_eth1="dhcp"

#fallback_enp5s0="172.16.3.134/25"

#fallback_route_enp5s0="172.16.3.129/25"

# The network scripts are now part of net-misc/netifrc

# In order to avoid sys-apps/openrc-0.12.4 from removing this file, this comment was

# added; you can safely remove this comment.  Please see

# /usr/share/doc/netifrc*/README* for more information.
```

And here is what it is currently doing -- notice enp3s0. it got assigned a 169.254 address and a route too.  Looks like the extra IP and extra route are harmless (or appear to be)

```
dbishop@temmanuel ~ $ ip a s

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo

       valid_lft forever preferred_lft forever

2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether 00:1b:21:b1:c5:1f brd ff:ff:ff:ff:ff:ff

    inet 172.16.7.1/24 brd 172.16.7.255 scope global enp3s0

       valid_lft forever preferred_lft forever: xauth key data not generated

    inet 169.254.3.149/16 brd 169.254.255.255 scope global enp3s0rwarding.

       valid_lft forever preferred_lft forever

3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether c8:60:00:c4:d4:99 brd ff:ff:ff:ff:ff:ff

    inet 172.16.3.134/25 brd 172.16.3.255 scope global enp5s0

       valid_lft forever preferred_lft forever

4: tunl0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default 

    link/ipip 0.0.0.0 brd 0.0.0.0

5: ip_vti0@NONE: <NOARP> mtu 1364 qdisc noop state DOWN group default 

    link/ipip 0.0.0.0 brd 0.0.0.0

```

```
dbishop@temmanuel ~ $ ip r s 

default via 172.16.3.129 dev enp5s0  metric 203 

127.0.0.0/8 dev lo  scope host 

127.0.0.0/8 via 127.0.0.1 dev lo 

169.254.0.0/16 dev enp3s0  proto kernel  scope link  src 169.254.3.149  metric 202 

172.16.3.128/25 dev enp5s0  proto kernel  scope link  src 172.16.3.134  metric 203 

172.16.7.0/24 dev enp3s0  proto kernel  scope link  src 172.16.7.1 

```

And thank you again for helping.

----------

## dbishop

Okay, I created a custom udev rule set, replete with an homage, using the same syntax as I used long ago, and that seemed to work okay.

```
temmanuel ~ # cat /etc/udev/rules.d/70-net-name-use-custom.rules[/i]

# First one uses MAC information, and 70- number to be before other net rules

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:1b:21:b1:c5:1f", NAME="neddy0"

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="c8:60:00:c4:d4:99", NAME="neddy1"
```

The remaining problem seems to be that the first interface "neddy0" -- hah i was sure there wouldn't be a conflict -- gets both the fixed IP & subnet I assigned in /etc/conf.d/net -- but as a bonus prize I got a 169.254/16 IP assigned as a second interface address. Argghh.  I got a bonus route for it too.

How does one get rid of unwanted apipa behaviour?

And here they are below:

```
temmanuel ~ # ip a s

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 

    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00

    inet 127.0.0.1/8 brd 127.255.255.255 scope host lo

       valid_lft forever preferred_lft forever

2: neddy0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether 00:1b:21:b1:c5:1f brd ff:ff:ff:ff:ff:ff

    inet 172.16.7.1/24 brd 172.16.7.255 scope global neddy0

       valid_lft forever preferred_lft forever

    inet 169.254.106.70/16 brd 169.254.255.255 scope global neddy0

       valid_lft forever preferred_lft forever

3: neddy1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000

    link/ether c8:60:00:c4:d4:99 brd ff:ff:ff:ff:ff:ff

    inet 172.16.3.134/25 brd 172.16.3.255 scope global neddy1

       valid_lft forever preferred_lft forever
```

And below you can see the extra route that got added:

```

temmanuel ~ # ip r s

default via 172.16.3.129 dev neddy1  metric 203 

127.0.0.0/8 dev lo  scope host 

127.0.0.0/8 via 127.0.0.1 dev lo 

169.254.0.0/16 dev neddy0  proto kernel  scope link  src 169.254.106.70  metric 202 

172.16.3.128/25 dev neddy1  proto kernel  scope link  src 172.16.3.134  metric 203 

172.16.7.0/24 dev neddy0  proto kernel  scope link  src 172.16.7.1 

```

and my /etc/conf.d/net

```
searchdomains="test.sys bish0p.org donbishop.cc mediacell.com"

nameservers="127.0.0.1"

config_neddy0="172.16.7.1/24"

dhcpcd_neddy1="-C ntp.conf"

config_neddy1="dhcp"

```

----------

## khayyam

 *dbishop wrote:*   

> How does one get rid of unwanted apipa behaviour?

 

dbishop ... it should be sufficient to do the following:

/etc/conf.d/net

```
modules_neddy0="!apipa !dhcpcd"

config_neddy0="172.16.7.1/24"

modules_neddy1="!apipa dhcpcd"

dhcp_neddy1="nontp"

dhcpcd_neddy1="--noipv4ll"
```

best ... khay

----------

## dbishop

khayyam,

Many thanks.  Not sure when the game changed from saying what you wanted for an interface to saying what you don't want, but now that I know I'll play along...

----------

## khayyam

 *dbishop wrote:*   

> Many thanks.  Not sure when the game changed from saying what you wanted for an interface to saying what you don't want, but now that I know I'll play along...

 

dbishop ... you're welcome. It didn't change, its just that with computers it helps to be explicit :)

best ... khay

----------

## NeddySeagoon

dbishop,

:)

You get the 169.254.x.x address for free when dhcp cannot find a dhcp server.  Its a self assigned address that is useful only for ad hoc networks where there is by definition, no router.

No route is required to reach other  169.254.x.x/16 members either.

----------

## UberLord

 *NeddySeagoon wrote:*   

> No route is required to reach other  169.254.x.x/16 members either.

 

A subnet route of 169.254/16 is still required.

That's technically a route  :Razz: 

----------

## dbishop

Thx everyone. I understand what apipa is, I just was wrestling with keeping it off this system since I didn't really want it, and worse, it was breaking things -- ordinary things. To me, Gentoo always meant never ending up with Microsoft-inspired cruft unless i put it there. *sigh*

It started popping up on some of my Gentoo boxes while on others it did not. On this particular machine it started when I used ifnames=0. The afflicted interface that was set to a fixed IP via /etc/conf.d/net while it was not getting the fixed IP, so the dhcp-ness of it all was baffling.  There was an appropriate link in /etc/init.d/net.eth0 (all instances of enp3s0 -> eth0) and /etc/conf.d/net was correct too.

Adding to the irony, the "persistent names" were bouncing around, probably something to do with a PCI bus enumeration race condition on this particular Asus mobo.  Of course a flapping interface name is anathema to things like iptables on a multihomed machine acting as a router, so it had to be fixed, and publicly so, hence the public forum work-through.  Which of course points out why megalomaniacs should stick to people-politics and not become OS Nazis.

In the end, Khay hit on it -- just overtly disable apipa. I combined this with Neddy's good advice to re-introduce udev mac-based-remapping rules (which I am sure will be a constant source of upgrade headaches like before).  I called the interfaces neddy1 and neddy2, but on further thought i will rename one of them to khay1. Always be grateful (-:

----------

## UberLord

 *dbishop wrote:*   

> Thx everyone. I understand what apipa is, I just was wrestling with keeping it off this system since I didn't really want it, and worse, it was breaking things -- ordinary things. To me, Gentoo always meant never ending up with Microsoft-inspired cruft unless i put it there. *sigh*

 

Apple had the biggest hand in writing the RFC, Sun also participated.

It shouldn't break anything at all and I don't see how it possibly could.

There are many valid use cases for this, especially when partnered with mDNS.

----------

