eth0 - eth1 confusion vs. local network
in [Debian]
|
From: Camaleón on 7 Feb 2010 17:40 On Sun, 07 Feb 2010 13:36:13 -0800, Frank Miles wrote: > [snip] > >>I fail to see what it's doing, but I cannot see any reference to "eth1", >>it's like only one interace is being recognized :-? >> >>What is the output of "dmesg | grep eth"? > > [ 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 > > Again, eth1 is working fine; eth0 seems completely > blocked/nonfunctional, despite all the configuration files and netstats > looking fine. 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. Also, there is no "link up" or "link down" for eth1 but *both" eth0 going up. Not sure how to interpret that. > I made a minor effort earlier to suppress the IPv6 modules, but [a] > didn't succeed; and [b] hadn't suppressed them earlier with the > one-interface system so wasn't convinced it was worth trying - why > shouldn't this cause eth1 to quit as well as eth0? Also the previous > system showed some indications of IPv6 in its reports, and it worked > fine. I don't think this issue can have any relation with ipv6 :-?. How about your "/etc/network/interfaces"? Besides, you can make a quick probe by disabling "eth1" and test if the network works as expected ("ping" et al) and then disable "eth0" and perform the same test. I mean, test the network adapters "separately". Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Tom H on 7 Feb 2010 17:40 > I made a minor effort earlier to suppress the IPv6 modules, but [a] didn't > succeed Add ipv6.disable=1 to the grub kernel/linux line to disable ipv6 (without recompiling the kernel) but it cannot be the problem. -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Tom H on 7 Feb 2010 17:40 > That file includes: > # PCI device 0x10ec:0x8168 (r8169) > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", > ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", > KERNEL=="eth*", NAME="eth0" > # PCI device 0x10b7:0x9050 (3c59x) > SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", > ATTR{address}=="xx:xx:xx:xx:xx:xx", ATTR{dev_id}=="0x0", ATTR{type}=="1", > KERNEL=="eth*", NAME="eth1" > On further checking, it may be that renaming is acceptable - in > /var/log/messages: > Feb 7 04:51:22 puffin kernel: [ 6.122403] 3c59x 0000:03:02.0: PCI INT A > -> GSI 18 (level, low) -> IRQ 18 > Feb 7 04:51:22 puffin kernel: [ 6.122407] 3c59x: Donald Becker and > others. > Feb 7 04:51:22 puffin kernel: [ 6.122411] 0000:03:02.0: 3Com PCI 3c905 > Boomerang 100baseTx at 000000000001df00. > Feb 7 04:51:22 puffin kernel: [ 6.148201] Linux agpgart interface v0.103 > Feb 7 04:51:22 puffin kernel: [ 6.153035] udev: renamed network > interface eth0 to eth1 > Feb 7 04:51:22 puffin kernel: [ 6.156559] r8169 Gigabit Ethernet driver > 2.3LK-NAPI loaded > Feb 7 04:51:22 puffin kernel: [ 6.156573] r8169 0000:02:00.0: PCI INT A > -> GSI 17 (level, low) -> IRQ 17 > Feb 7 04:51:22 puffin kernel: [ 6.157040] eth0: RTL8168d/8111d at > 0xffffc90000c78000, x:x:x:x:x:x, XID 083000c0 IRQ 32 > Feb 7 04:51:22 puffin kernel: [ 6.161239] r8169 0000:02:00.0: firmware: > requesting rtl8168d-2.fw > Feb 7 04:51:22 puffin kernel: [ 6.234448] eth0: unable to apply firmware > patch > Perhaps the kernel brings eth1 into existence by first establishing it as > eth0, then renaming it to eth1; then bringing the "real" eth0 into > existence. > The "unable to apply firmware patch" seems potentially alarming, but it > used to work as a single-interface system. lspci -v indicates both > NICs have "Kernel driver in use". Re the renaming of eth1/3c59x: is eth1/3c59x compiled into the kernel and eth0/r8169 is compiled as module? Re eth0/r8169 firmware: is rtl8168d-2.fw in /lib/firmware? if eth0 is up and running it might not need this patch (!). can you ping through eth0 if you remove eth1? I have just looked at your first email. eth0 does not have a default gateway. -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Camaleón on 7 Feb 2010 17:50 On Sun, 07 Feb 2010 13:36:13 -0800, Frank Miles wrote: > [snip] > >>I fail to see what it's doing, but I cannot see any reference to "eth1", >>it's like only one interace is being recognized :-? >> >>What is the output of "dmesg | grep eth"? > > [ 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 > > Again, eth1 is working fine; eth0 seems completely > blocked/nonfunctional, despite all the configuration files and netstats > looking fine. 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. Also, there is no "link up" or "link down" for eth1 but *both" eth0 going up. Not sure how to interpret that. > I made a minor effort earlier to suppress the IPv6 modules, but [a] > didn't succeed; and [b] hadn't suppressed them earlier with the > one-interface system so wasn't convinced it was worth trying - why > shouldn't this cause eth1 to quit as well as eth0? Also the previous > system showed some indications of IPv6 in its reports, and it worked > fine. I don't think this issue can have any relation with ipv6 :-?. How about your "/etc/network/interfaces"? Besides, you can make a quick probe by disabling "eth1" and test if the network works as expected ("ping" et al) and then disable "eth0" and perform the same test. I mean, test the network adapters "separately". Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
From: Tom H on 7 Feb 2010 22:10
>> [ 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-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org |