... ok, started...
[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.
That's the reason for my earlier fact-free speculation , based on a kern.log
entry:
> 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 kern.log entries don't appear in the dmesg output.
Also, there is no "link up" or "link down" for eth1 but *both" eth0 going
up. Not sure how to interpret that.
I don't know how to interpret that either, but the message is completely
unchanged other than time - why assume it is referring to the 3com card
in either case? And in any event, the 3com card is functioning - it's
the realtek that isn't.
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
Tom H:
Thanks for your queries also. I agree that the ipv6 warning is probably
not an issue. What follows may help answer the questions that both of
you have raised:
-----------------------------------------
...and diverted and continued...
I decided to go back and re-establish the system when it only had a single NIC.
Unfortunately this is the r8169, which has the possible firmware issue. I was
_unable_ to get that working, though it had worked at one time. In the hopes
of satisfying your curiousity, here are some reports from that experiment:
puffin:~# netstat -nr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
puffin:~# arp -a
grebe (192.168.0.4) at xx:xx:xx:xx:xx:xx [ether] on eth0
puffin:# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.0.10 0.0.0.0 UG 0 0 0 eth0
puffin:# ping 192.168.0.4
PING 192.168.0.4 (192.168.0.4) 56(84) bytes of data.
^C
--- 192.168.0.4 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2016ms
puffin:~# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
puffin:~# /sbin/ifconfig
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:18 errors:0 dropped:0 overruns:0 frame:0
TX packets:9 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1080 (1.0 KiB) TX bytes:594 (594.0 B)
Interrupt:32 Base address:0x6000
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:69 errors:0 dropped:0 overruns:0 frame:0
TX packets:69 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:18577 (18.1 KiB) TX bytes:18577 (18.1 KiB)
puffin:~# dmesg | fgrep eth
[ 0.534289] Driver 'rtc_cmos' needs updating - please use bus_type methods
[ 6.658237] eth0: RTL8168d/8111d at 0xffffc90000c56000, xx:xx:xx:xx:xx:xx,
XID 083000c0 IRQ 32
[ 6.808657] eth0: unable to apply firmware patch
[ 11.283432] r8169: eth0: link up
[ 11.283438] r8169: eth0: link up
[ 21.431334] eth0: no IPv6 routers present
puffin:~# ping 192.168.0.4
PING 192.168.0.4 (192.168.0.4) 56(84) bytes of data.
^C
puffin:# route add default gw puffin
puffin:# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
0.0.0.0 192.168.0.10 0.0.0.0 UG 0 0 0 eth0
puffin:# ping 192.168.0.4
PING 192.168.0.4 (192.168.0.4) 56(84) bytes of data.
^C
--- 192.168.0.4 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2016ms
-----------------------------------------
Briefly, my thinking now is that I somehow managed to mess up the NIC firmware
situation that had originally been set up, probably when I updated the system.
Before this change, I'd loaded the whole system using eth0 - tens of GB - with
no problem!
There are several bug reports associated with the r8169 - and its (lack of)
firmware associated with the 2.6.32 kernel [see, for example, #561309].
I'll have to see if I can scrounge another NIC as a temporary work-around.
Thanks again for your diagnostic tips, it has prodded my thinking. Any
other ideas welcome!
Frank
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
