# Network interfaces randomly swapping!

## RageX^NZ

Hello fellow Gentooists,

I have been using Gentoo for around 5 years now, and have never encountered a strange problem as I am now.  This has only started happening since I installed the from the latest live-cd and Stage3.

What happens is, I have 2 network cards, an onboard e1000 and a PCI e100.  In /etc/modules.autoload.d/kernel-2.6 I have e1000 loading first, then e100.  This should in theory make the gigabit card eth0, and the 100mbit card eth1.  However it does not!   Further to this, almost every time I boot up the order of the interfaces has swapped e.g. eth0 was the gigabit card last time, now eth0 is the 100mbit card.

It is MOST frustrating.

I have also seen this behavior on 2 other machines with similar hardware I have configured up as Asterisk machines.

Can someone shine some light on why this is happening ?

Thanks,

Andrew

----------

## didymos

Udev doesn't really care how things are listed. It basically just has a list of stuff to be loaded and when it's ready,  it loads everything at once, so the order can change (apparently) at random. You'll probably have to create a couple local rules telling udev to name the cards based on the MAC address.  Here's a decent guide for udev rules:

http://www.reactivated.net/writing_udev_rules.html

but you really only need this, in the file /etc/udev/rules.d/10-local.rules:

```

SUBSYSTEM=="net", ATTRS{address}=="aa:bb:cc:dd:ee:ff", NAME="eth0"

SUBSYSTEM=="net", ATTRS{address}=="ff:ee:dd:cc:bb:aa", NAME="eth1"

```

The names can be whatever you feel like.  Also, newer versions of udev should do persistent naming of network interfaces automatically.

----------

## dhave

 *didymos wrote:*   

> Udev doesn't really care how things are listed. It basically just has a list of stuff to be loaded and when it's ready,  it loads everything at once, so the order can change (apparently) at random. You'll probably have to create a couple local rules telling udev to name the cards based on the MAC address.  Here's a decent guide for udev rules:
> 
> http://www.reactivated.net/writing_udev_rules.html
> 
> but you really only need this, in the file /etc/udev/rules.d/10-local.rules:
> ...

 

I understand the rules here and am using them successfully on my system. However, I wonder what this approach means for people who need to manage deployment or maintenance of multiple systems. It seems that it would be better to use generic addresses rather than specific MAC addresses. 

I know this probably isn't the OP's situation, but I'm just wondering about the wisdom of a rule logic like this if it works well with specific MAC addresses entered manually.

----------

## RageX^NZ

The strange thing here is that I am running the latest build of udev e.g. 103 

My entire system is up to date.

I can use the custom udev rules, but would prefer not to.  This has been working perfectly for years and year, why has it suddenly stopped.  

I am not using coldplug so it should not automatically be loading modules for me.

----------

## didymos

dhave:

 *Quote:*   

> 
> 
> I understand the rules here and am using them successfully on my system. However, I wonder what this approach means for people who need to manage deployment or maintenance of multiple systems. It seems that it would be better to use generic addresses rather than specific MAC addresses.
> 
> I know this probably isn't the OP's situation, but I'm just wondering about the wisdom of a rule logic like this if it works well with specific MAC addresses entered manually.
> ...

 

That's just a quick, simple way to do it for a personal system.  I'm sure there are other more sophisticated schemes that are possible using complex rulesets.  It's not really something I cared about one way or the other, except you've made me curious, which means I'm going to have to research it now. Dammit.

RageX^NZ:

 *Quote:*   

> 
> 
> The strange thing here is that I am running the latest build of udev e.g. 103
> 
> 

 

Do you have the file /etc/udev/rules.d/75-persistent-net-generator.rules? All it does is generate custom rules based on the MAC address, and stick them in /etc/udev/rules.d/70-persistent-net.rules.  Having local rules is no different results-wise, just more work and a different filename.  

RageX^NZ:

 *Quote:*   

> 
> 
> I am not using coldplug so it should not automatically be loading modules for me.
> 
> 

 

By this, do you mean you don't have coldplug installed? If yes, then it doesn't matter because udev effectively is coldplug now.  To disable that, you need to edit the /etc/conf.d/rc file and set RC_COLDPLUG to "no".

----------

## RageX^NZ

The way that the Gentoo team have changed this seems a bit daft to me. 

Imagine a Gentoo machine being used as a firewall, updates the baselayout/udev and next time a reboot occurs all of the interfaces get mixed up.

I will check that RC file and hopefully UDEV will lock them automatically.

----------

## RageX^NZ

Yes, I do have that file.  Thanks for your help.

# these rules generate rules for persistent network device naming

ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*|ath*|wlan*|ra*|sta*" \

        NAME!="?*", DRIVERS=="?*", GOTO="persistent_net_generator_do"

GOTO="persistent_net_generator_end"

LABEL="persistent_net_generator_do"

# build device description string to add a comment the generated rule

SUBSYSTEMS=="pci", ENV{COMMENT}="PCI device $attr{vendor}:$attr{device} ($attr{driver})"

SUBSYSTEMS=="usb", ENV{COMMENT}="USB device 0x$attr{idVendor}:0x$attr{idProduct} ($attr{driver})"

SUBSYSTEMS=="ieee1394", ENV{COMMENT}="Firewire device $attr{host_id})"

SUBSYSTEMS=="xen", ENV{COMMENT}="Xen virtual device"

ENV{COMMENT}=="", ENV{COMMENT}="$env{SUBSYSTEM} device ($attr{driver})"

IMPORT{program}="write_net_rules $attr{address}"

ENV{INTERFACE_NEW}=="?*", NAME="$env{INTERFACE_NEW}"

LABEL="persistent_net_generator_end"

----------

## devsk

how are we supposed to change the 75-persistent-net-generator.rules file to get it to assign eth0 to the only interface I have? It sometimes assigns it eth1 and all hell breaks loose: sshd, samba, distccd all fail to start because net.eth0 doesn't start because it fails to find any device.

```

# PCI device 0x10de:0x0057 (forcedeth)

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:00:6c:8e:e3:b4", NAME="eth0"

# PCI device 0x10de:0x0057 (forcedeth)

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:50:8d:d7:c8:4d", NAME="eth1"
```

this is how the file 70-persistent-net.rules looks like. the mac address it found for eth1 is actually the one for my nic which I want as eth0. funny thing is: where did it get the mac address "00:00:6c:8e:e3:b4" from and how did it link it to forcedeth module?Last edited by devsk on Thu Jan 18, 2007 2:26 am; edited 1 time in total

----------

## RageX^NZ

I dont even have the .70 file, I have the 75-persistant-rules one but it does not seem to generate anything!

----------

## devsk

I found where the random mac addresses are coming from. from dmesg:

```
0000:00:0a.0: Invalid Mac address detected: 4d:c8:d7:8d:50:00

Please complain to your hardware vendor. Switching to a random MAC.

```

looks like Abit's messing up with MAC address and udev having based the name assignment on MAC address has created new rules everytime the device driver is removed and re-inserted.

Only solution for me looks like changing the line:

```

ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*|ath*|wlan*|ra*|sta*" \
```

 in 75-persistent-net-generator.rules to :

```

# ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*|ath*|wlan*|ra*|sta*" \
```

, so no new rules are created based on the mac address. And finally leave only one rule in the 70-persistent-net.rules for eth0.

----------

## T38

from dhave:

 *Quote:*   

> However, I wonder what this approach means for people who need to manage deployment or maintenance of multiple systems

 

That's exactly the situation I am in.  The company I work for has a lot of technicians in the field with Gentoo-based PCs.  Since all of these desktops have basically the same architecture, we've made a master image that put on the computer when we build/rebuild them.  I just updated the image on one of these computers (it had been a long, long time since the last emerge --update world), and got it working on one machine, but when I copied the image to a second machine, it kept assigning the e1000 NIC to eth1...took me a few days of scouring the Gentoo forums to figure that out   :Embarassed:   I should have run ifconfig -a a little sooner.

from didymos:

 *Quote:*   

> To disable that, you need to edit the /etc/conf.d/rc file and set RC_COLDPLUG to "no".

 

That looks like it's solved the issue for me.  After changing this option in /etc/conf.d/rc and rebooting, my interface came up as eth0 rather than eth1.

I'm still puzzled though--the Intel Pro100/1000 is the only network device on this system, so I don't know why my NIC was getting eth1 before I set RC_COLDPLUG to "no".  According to my log files, it didn't look like another device had usurped eth0:

```
Jan 26 02:02:26 [rc-scripts] network interface eth0 does not exist

Jan 26 02:02:26 [rc-scripts] Please verify hardware or kernel module (driver)

Jan 26 02:02:26 [rc-scripts] ERROR:  cannot start netmount as net.eth0 could not

 start

```

----------

## T38

Resurrecting a REALLY old thread to post the correct solution in case someone else has a similar problem in the future

 *Quote:*   

> I'm still puzzled though--the Intel Pro100/1000 is the only network device on this system, so I don't know why my NIC was getting eth1 before I set RC_COLDPLUG to "no".

 

Shortly after posting this, I figured it out.  Udev assigns network device names based upon the MAC address of the device.  Since I was building multiple machines off a single image, udev had assigned Eth0 based upon the MAC address of the machine that was used to build the image.  When I built new machines from the master image, Eth0 was already assigned to the original machine's MAC address, and therefore it assigned Eth1 to the MAC address of the network interface that was on the new machine.  The *correct* solution was to remove /etc/udev/rules.d/70-persistent-net.rules from the image (which, of course, allowed udev to create a new 70-persistent-net.rules file with the correct MAC address for Eth0).

----------

