Re: eth0 - eth1 confusion vs. local network
>> [ 6.317161] eth1: RTL8168d/8111d at 0xffffc90000c4e000,xx:xx:xx:xx:xx:xx, XID 083000c0 IRQ 32
>> [ 6.384830] eth1: unable to apply firmware patch
>> [ 7.190453] udev: renamed network interface eth1 to eth0
>> [ 7.229390] udev: renamed network interface eth0_rename to eth1
>> [ 11.276999] r8169: eth0: link up
>> [ 11.277005] r8169: eth0: link up
>> [ 12.215716] eth1: setting full-duplex.
>> [ 21.531029] eth0: no IPv6 routers present
>> [ 22.599867] eth1: no IPv6 routers present
> Errr, sir... something goes wrong here.
> As per your "/etc/udev/rules.d/70-persistent-net.rules":
> eth0 -> realtek
> eth1 -> 3com
> But that is not what dmesg says above.
The udev rules and dmesg output concur..
6.317161 --> realtek is eth1
7.190453 --> realtek renamed eth0 (and, I assume, 3com renamed eth0_rename)
7.229390 --> 3com renamed eth1
So 3com is eth0 and realtek is eth1 after boot and udev renames them
when it applies its rules.
I had asked earlier about whether the 3com driver was compiled into
the kernel and the realtek driver compiled as a module because it
_MIGHT_ explain why 3com is eth0 before the udev rules kick in. But it
could also be a simple hardware detection order issue. If it is a
hardware order issue, I would love to know why this order when the
nics are first named and the order when the udev rules are written
differ...
Another question: is there an alias for either of both nics in
/etc/modprobe.conf or /etc/modprobe.d?
> Also, there is no "link up" or "link down" for eth1 but *both" eth0 going
> up. Not sure how to interpret that.
+1
Reply to: