eth0 - eth1 confusion vs. local network
in [Debian]
|
From: Frank Miles on 7 Feb 2010 10:30 I am in the final throes of getting a new system running (Debian/squeeze). For the past 2 weeks it's had just eth0, and the network has worked fine. Now I want this system to have two network interfaces - the original eth0, and eth1 to a DSL modem, just like its precessor system. The strange thing is that wth the introduction of the second network card, the DSL connection works fine, but eth0 fails. A few relevant outputs: first, ifconfig shows (I masked the HWaddr's): eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:192.168.0.10 Bcast:192.168.0.255 Mask:255.255.255.0 inet6 addr: fe80::6ef0:49ff:fe08:a40/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:198 errors:0 dropped:0 overruns:0 frame:0 TX packets:26 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:11880 (11.6 KiB) TX bytes:1916 (1.8 KiB) Interrupt:32 Base address:0x2000 eth1 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx inet addr:192.168.1.33 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::260:8ff:fead:ec57/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5811 errors:0 dropped:0 overruns:0 frame:0 TX packets:6876 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4123103 (3.9 MiB) TX bytes:740692 (723.3 KiB) Interrupt:18 Base address:0xdf00 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:212 errors:0 dropped:0 overruns:0 frame:0 TX packets:212 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:43609 (42.5 KiB) TX bytes:43609 (42.5 KiB) And route -n : Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth1 However, if I (even as root) try to ping another machine on the network: PING 192.168.0.4 (192.168.0.4) 56(84) bytes of data. ping: sendmsg: Operation not permitted ping: sendmsg: Operation not permitted ... ssh to the other machine similarly fails, though it worked when the new machine had a single interface. Similarly, I cannot ping or otherwise interact with the new machine from other machines on the local network. Strangely, arp -a shows: grebe (192.168.0.4) at xx:xx:xx:xx:xx:xx [ether] on eth0 rubberducky (192.168.1.1) at xx:xx:xx:xx:xx:xx [ether] on eth1 where 'grebe' is the machine that I tried to ping. It may have gotten the name from /etc/hosts, not necessarily via the network. No help if iptables rules are flushed. There is one troubling line in the logs from boot: udev: renamed network interface eth0 to eth1 Doing an "ifdown eth1" does not fix the eth0 problem. So far, I haven't seen anything in the udev rules that might cause this. This is all with the 2.6.32-trunk kernel in squeeze. If anyone has any ideas on how to diagnose or fix this problem I'd appreciate it. TIA! -F -- 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 12:00 On Sun, 07 Feb 2010 07:07:03 -0800, Frank Miles wrote: (...) > There is one troubling line in the logs from boot: > udev: renamed network interface eth0 to eth1 > Doing an "ifdown eth1" does not fix the eth0 problem. Mmm... check your "/etc/udev/rules.d/70-persistent-net.rules", there should be "two" adaptapters listed there. 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: Frank Miles on 7 Feb 2010 14:10 Thanks, Camaleon (sorry - don't know how to generate the proper characters). 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". FWIW the kernel is the amd64 variant. Any other thoughts? I should probably pull the 2nd NIC to verify that I'm not delusional, or haven't bunged the configuration somehow, but I'm stumped in solving this... especially since it is in most respects much like a previous system. Thanks, all! -F -- 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 15:20 On Sun, 07 Feb 2010 10:41:46 -0800, Frank Miles wrote: > Thanks, Camaleon (sorry - don't know how to generate the proper > characters). Still "us-ascii"? ;-) No problem. > 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" Seems both are detected. Nothing strange here. > On further checking, it may be that renaming is acceptable - in > /var/log/messages: (...) > 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. 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"? 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: Frank Miles on 7 Feb 2010 17:00
[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. 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. Thanks, -Frank -- To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org |