[SOLVED] Slackware64-current: eth1 replaces eth0, but gets no IP address on new mainboard

gargamel · 07-18-2009, 03:29 PM

Hi there,

I am not sure, if it is a Slackware-specific topic. If not, please, let me know, I'll then post this elsewhere.

System is Slackware64-current with all upgrades up to today.

Problem is:

Because a thunderbolt destroyed my mainboard I had it replaced. Not the system doesn't receive a dynamic IP address from the router anymore with DHCP at boot time. The reason seems to be that there is no interface eth0 anymore. I see messages that udev replaced it with eth1.

Code:

# dhcpcd eth0
err, eth0: ioctl SIOCGIFHWADDR: No such device
root@orion10:/home/alex# dmesg | grep -i eth
Driver 'st' needs updating - please use bus_type methods
Driver 'sd' needs updating - please use bus_type methods
Driver 'sr' needs updating - please use bus_type methods
forcedeth: Reverse Engineered nForce ethernet driver. Version 0.62.
forcedeth 0000:00:14.0: PCI INT A -> Link[LMAC] -> GSI 23 (level, low) -> IRQ 23
forcedeth 0000:00:14.0: setting latency timer to 64
forcedeth 0000:00:14.0: ifname eth0, PHY OUI 0x732 @ 1, addr 00:19:db:cf:36:79
forcedeth 0000:00:14.0: highdma pwrctl timirq gbit lnktim desc-v3
udev: renamed network interface eth0 to eth1
eth1: no link during initialization.
ADDRCONF(NETDEV_UP): eth1: link is not ready
eth1: link up.
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
eth1: no IPv6 routers present

Now

Code:

# dhcpcd eth1

works, while

Code:

# dhcpcd eth0

gives me an error message:

Code:

err, eth0: ioctl SIOCGIFHWADDR: No such device

In another thread I found a hint to delete /etc/udev/rules.d/70-persistent-net.rules, which I did. This file contains a line referring to eth1. But after deleting it, restarting udev brought it back, again with eth1 instead of eth0.

No I wonder, what's the best way to get back the standard behaviour, i. e. getting an IP address from the router at boot time?

Thanks for any hint!

gargamel

XGizzmo · 07-18-2009, 03:49 PM

Try stopping udev then deleting /etc/udev/rules.d/70-persistent-net.rules . Also lspci and lsmod may help to see whats loaded up.

gargamel · 07-18-2009, 05:04 PM

As I said, I had tried stopping udev and deleting /etc/udev/rules.d/70-persistent-net.rules before, but to no avail. But let's try again.

Code:

# /etc/rc.d/rc.udev stop
# rm /etc/udev/rules.d/70-persistent-net.rules
# lspci
[...]00:14.0 Bridge: nVidia Corporation MCP51 Ethernet Controller (rev a3)
[...]
# lsmod
[...]
ipv6                  288704  18
ppdev                   8488  0
nvidia              10264072  36
snd_hda_codec_realtek   253956  1
i2c_nforce2             7496  0
forcedeth              59696  0
[...]

There's a lot more, but this is what I think is network related. If it doesn't give a clue, I can, of course post, the complete logged messages.

Here is /etc/udev/rules.d/70-persistent-net.rules:

Code:

# PCI device 0x10de:0x0269 (forcedeth)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:19:db:cf:36:79", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

But what I don't get here is: Why eth1, and not eth0?
And why does this interface not get an IP address?

Only way currently is

Code:

# dhcpcd eth1

Thanks again!

gargamel

gargamel · 07-18-2009, 05:04 PM

Could this be IPv6 or Nforce related?

gargamel

rg3 · 07-18-2009, 05:12 PM

Change /etc/udev/rules.d/70-persistent-net.rules and write "eth0" instead of "eth1", then reboot. I'm not sure it will work, but it's just to try different things.

markush · 07-18-2009, 05:30 PM

Hello,

when experiencing peculiar events in a network after a thunderbolt as you write, I'd suggest to test if a switch or a router is damaged. A damaged switch can cause dhcp not to work properly.

Markus

gargamel · 07-18-2009, 05:55 PM

Quote:

Originally Posted by rg3

Change /etc/udev/rules.d/70-persistent-net.rules and write "eth0" instead of "eth1", then reboot. I'm not sure it will work, but it's just to try different things.

This works, even without rebooting. I did:

Code:

# cd /etc/rc.d
# ./rc.inet1 stop
# ./rc.udev stop
# vim /etc/udev/rules.d/70-persistent-net.rules

Here I changed eth1 to eth0
I used ifconfig to ensure that there was now no active interface, except loopback. Which was the case, the computer had 127.0.0.1 for interface lo as its only IP address. Then:

Code:

# ./rc.udev start
# ./rc.inet1 start
# ifconfig
eth0      Link encap:Ethernet  HWaddr XX:XX:XX:XX:XX
          inet addr:192.168.xxx.27  Bcast:192.168.xxx.xxx Mask:255.255.255.0
          inet6 addr: XXXX::XXX:XXXX:XXXX:nnnn/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:5620 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5531 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:5079183 (4.8 MiB)  TX bytes:803583 (784.7 KiB)
          Interrupt:23 Base address:0x2000

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:896 errors:0 dropped:0 overruns:0 frame:0
          TX packets:896 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:268694 (262.3 KiB)  TX bytes:268694 (262.3 KiB)

Now, this seems to work. However, I'd still like to know where the automatically generated eth1 comes from, and why DHCPCD doesn't use it then, once it is detected and as there is no eth0.

Does anyone know?

Thanks!

gargamel

gargamel · 07-18-2009, 05:57 PM

Quote:

Originally Posted by markush

Hello,

when experiencing peculiar events in a network after a thunderbolt as you write, I'd suggest to test if a switch or a router is damaged. A damaged switch can cause dhcp not to work properly.

Markus

Switch/router was already replaced, the new device worked out of the box with all my other machines, so it's very unlikely that the problem is caused on the router side.

Thanks anyway.

gargamel

Alien Bob · 07-18-2009, 06:30 PM

Quote:

Originally Posted by gargamel

I'd still like to know where the automatically generated eth1 comes from, and why DHCPCD doesn't use it then, once it is detected and as there is no eth0.

When your computer boots, udev looks for a card definition in /etc/udev/rules.d/70-persistent-net.rules that matches your new NIC's MAC address. The very first time it will not find a line for the new NIC. Instead it finds the entry for your old card, and additionally udev sees that this old card was called "eth0".

Even though your old NIC no longer exists, udev has to pick "eth1" for your new card because "eth0" appears to be taken. For all udev knows, the old card may only be gone temporarily, so it will not mess with existing NIC configurations.

And your Slackware box will probably only have configuration data for "eth0" in the file '/etc/rc.d/rc.inet1.conf'. When the interface with name "eth1" becomes available, and that interface is not configured in the rc.inet1.conf file, Slackware will not bring it up.

Eric

gargamel · 07-18-2009, 06:51 PM

Thanks, Eric, this explains part of it, but:
After deleting /etc/udev/rules.d/70-persistent-net.rules and restarting udev all traces of the old NIC should be wiped, right? But when I then re-start udev, the file is created anew, again with a reference to eth1.

Why does udev "think" that eth0 is taken? Where does it take this (wrong) information from?

There is still a gap in my understanding, it seems... Would be grateful, if you could help me to close it.

Thanks again!

gargamel

XGizzmo · 07-18-2009, 11:56 PM

gargamel I think since the nic had already been setup as eth1 in the kernel, udev was pulling the same info to create /etc/udev/rules.d/70-persistent-net.rules. After you delete that file you need to reboot to clear the old info out of the kernel.

gargamel · 07-19-2009, 02:56 AM

Thanks a lot, XGizzmo, that solved it!
1. Delet /etc/udev/rules.d/70-persistent-net.rules
2. Reboot

Now, just for curiosity: Where does the kernel take this information from, and how can it be changed at runtime?

It should be possible. Isn't runtime flexibility what udev (and hal) are all about? E. g., when I plug an external USB hard disk, it's detected and made available to users (depending on pre-defined rules). However, when an Ethernet adapter is replaced with another one, this principle does not seem to apply (of course, this is rarely done).

gargamel

XGizzmo · 07-19-2009, 06:57 AM

Quote:

Originally Posted by gargamel

Now, just for curiosity: Where does the kernel take this information from, and how can it be changed at runtime?

This is done when the kernel module is loaded. In your case you could have rmmod the module for your nic and modprobe the module. But unless you need high uptime a reboot is just as easy.

gargamel · 07-22-2009, 03:40 PM

Thanks!

gargamel