>> [ 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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
