Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian User (http://www.linux-archive.org/debian-user/)
-   -   eth0 - eth1 confusion vs. local network (http://www.linux-archive.org/debian-user/322102-eth0-eth1-confusion-vs-local-network.html)

Frank Miles 02-07-2010 02:07 PM

eth0 - eth1 confusion vs. local network
 
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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Camaleón 02-07-2010 03:54 PM

eth0 - eth1 confusion vs. local network
 
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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Frank Miles 02-07-2010 05:41 PM

eth0 - eth1 confusion vs. local network
 
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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Camaleón 02-07-2010 07:13 PM

eth0 - eth1 confusion vs. local network
 
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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Frank Miles 02-07-2010 08:36 PM

eth0 - eth1 confusion vs. local network
 
[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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Tom H 02-07-2010 09:31 PM

eth0 - eth1 confusion vs. local network
 
> 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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Camaleón 02-07-2010 09:38 PM

eth0 - eth1 confusion vs. local network
 
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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Tom H 02-07-2010 09:38 PM

eth0 - eth1 confusion vs. local network
 
> 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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Camaleón 02-07-2010 09:39 PM

eth0 - eth1 confusion vs. local network
 
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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Tom H 02-08-2010 02:01 AM

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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


All times are GMT. The time now is 01:44 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.