1 in 2 chance : need to issue "/etc/init.d/networking restart" after boot
 

Hi,

I installed Debian 4.0r1 on a test-box with known to be working
hardware. Unfortunately there seems to be a problem with the NIC's when
running Debian.


I have around a 50% chance that after a reboot I have no network
connectivity. The box has 3 NIC's : 1 onboard Intel NIC and 2 seperate
GBit Realtek RTL8169sb/8110sb NIC's.


All are configured with static ip's. And everytime after boot they are
assigned the correct ip's and are being reported as UP, but there is a
50% chance there is something wrong: eg. I can not even ping their own ip's.


The problem already occurs with just 1 NIC configured/enabled by the
default Debian installer. Again here, after a fresh install I have
around a 50% chance the 1 Realtek NIC that is enabled by the installer
is not working. I reinstalled several times and during install it always
works (can get dns-info and retrieve packages), only after reboot it
starts to fail sometimes.


I have only ran OpenBSD on this box previously but I hope that is
sufficient to conclude the hardware as such is not faulty.


A workaround for the problem is trivial : I simply added
"/etc/init.d/networking restart" to /etc/rc.local


With this in place the NIC's will always work after boot.


I tried changing parameters in /etc/network/interfaces (eg. adding
pre-up sleep 5) but to no avail. If I want to be certain the interfaces
work I still need to rely on "/etc/init.d/networking restart" in
/etc/rc.local


Issueing "/etc/init.d/networking restart" always (100%) solves the problem.


So granted, with this line in place there is no real issue, but I am
still curious. Would anyone be so kind to tell me whether this could be
a known issue ?



$dmesg | grep eth : (I assume all the bridging references come from
running vmware server)


e100: eth0: e100_probe: addr 0xcfffe000, irq 58, MAC addr 00:11:D8:11:B1:52
eth1: RTL8169sb/8110sb at 0xf884a800, 00:1b:11:63:e1:7d, IRQ 66
eth2: RTL8169sb/8110sb at 0xf884cc00, 00:1b:11:71:15:26, IRQ 74
r8169: eth1: link up
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
r8169: eth2: link down
ADDRCONF(NETDEV_UP): eth2: link is not ready
bridge-eth1: enabling the bridge
bridge-eth1: up
bridge-eth1: already up
bridge-eth1: attached
bridge-eth2: enabling the bridge
bridge-eth2: up
bridge-eth2: already up
bridge-eth2: attached
bridge-eth0: enabling the bridge
bridge-eth0: up
bridge-eth0: already up
bridge-eth0: attached
bridge-eth1: disabling the bridge
bridge-eth1: down
bridge-eth0: disabling the bridge
bridge-eth0: down
bridge-eth2: disabling the bridge
bridge-eth2: down
r8169: eth1: link up
bridge-eth1: enabling the bridge
bridge-eth1: up
ADDRCONF(NETDEV_UP): eth0: link is not ready
bridge-eth0: enabling the bridge
bridge-eth0: up
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
r8169: eth2: link down
ADDRCONF(NETDEV_UP): eth2: link is not ready
bridge-eth2: enabling the bridge
bridge-eth2: up
ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
eth1: no IPv6 routers present
eth0: no IPv6 routers present
device eth0 entered promiscuous mode
audit(1195553991.324:2): dev=eth0 prom=256 old_prom=0 auid=4294967295
bridge-eth0: enabled promiscuous mode
device eth2 entered promiscuous mode
audit(1195553991.324:3): dev=eth2 prom=256 old_prom=0 auid=4294967295
bridge-eth2: enabled promiscuous mode
device eth1 entered promiscuous mode
audit(1195553991.328:4): dev=eth1 prom=256 old_prom=0 auid=4294967295
bridge-eth1: enabled promiscuous mode
device eth0 left promiscuous mode
audit(1195554024.134:5): dev=eth0 prom=0 old_prom=256 auid=4294967295
bridge-eth0: disabled promiscuous mode
device eth0 entered promiscuous mode
audit(1195554024.134:6): dev=eth0 prom=256 old_prom=0 auid=4294967295
bridge-eth0: enabled promiscuous mode
device eth1 left promiscuous mode
audit(1195554024.362:7): dev=eth1 prom=0 old_prom=256 auid=4294967295
bridge-eth1: disabled promiscuous mode
device eth1 entered promiscuous mode
audit(1195554024.366:8): dev=eth1 prom=256 old_prom=0 auid=4294967295
bridge-eth1: enabled promiscuous mode
device eth2 left promiscuous mode
audit(1195554024.386:9): dev=eth2 prom=0 old_prom=256 auid=4294967295
bridge-eth2: disabled promiscuous mode
device eth2 entered promiscuous mode
audit(1195554024.386:10): dev=eth2 prom=256 old_prom=0 auid=4294967295
bridge-eth2: enabled promiscuous mode

--
Joris Van Herzele


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

1 in 2 chance : need to issue "/etc/init.d/networking restart" after boot
 

* Joris Van Herzele <jvh@whitenix.com> 2007-11-20
> I have around a 50% chance that after a reboot I have no network
> connectivity. The box has 3 NIC's : 1 onboard Intel NIC and 2 seperate
> GBit Realtek RTL8169sb/8110sb NIC's.

I have a similar problem on my home computer, which runs 4.0r0. In case you
solve your problem, do let me know the solution. Thank you!

--
Masatran, R. Deepak <http://research.iiit.ac.in/~masatran/>



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

1 in 2 chance : need to issue "/etc/init.d/networking restart" after boot
 

Joris Van Herzele wrote:

Hi,

I installed Debian 4.0r1 on a test-box with known to be working
hardware. Unfortunately there seems to be a problem with the NIC's when
running Debian.


I have around a 50% chance that after a reboot I have no network
connectivity. The box has 3 NIC's : 1 onboard Intel NIC and 2 seperate
GBit Realtek RTL8169sb/8110sb NIC's.


All are configured with static ip's. And everytime after boot they are
assigned the correct ip's and are being reported as UP, but there is a
50% chance there is something wrong: eg. I can not even ping their own ip's.


The problem already occurs with just 1 NIC configured/enabled by the
default Debian installer. Again here, after a fresh install I have
around a 50% chance the 1 Realtek NIC that is enabled by the installer
is not working. I reinstalled several times and during install it always
works (can get dns-info and retrieve packages), only after reboot it
starts to fail sometimes.


Because of the intermittency of the problem, I would first suspect
autonegotiation. Try a different device on the opposite end, or if you roll
your own kernel, just manually force the mode. (If this works, please report it
as a potential bug in the NIC driver.)



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

1 in 2 chance : need to issue "/etc/init.d/networking restart" after boot
 

is
http://www.debian.org/releases/stable/i386/release-notes/ch-information.en.html#s-asynchronous-network-start
relevant?

I also believe there is information in the wiki or release notes about workarounds.


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

1 in 2 chance : need to issue "/etc/init.d/networking restart" after boot
 

Marty wrote:

Because of the intermittency of the problem, I would first suspect
autonegotiation. Try a different device on the opposite end, or if you
roll your own kernel, just manually force the mode. (If this works,
please report it as a potential bug in the NIC driver.)




Thank you all for your interest and advice.
I really appreciate this.


Marty definitely had a point worth checking and indeed there appeared to
be an issue with auto-negotiation since the interface which I always
configured first, was working in half duplex mode ...


Something I only noticed when using 'ethtool'. In my defense I am more
familiar with BSD and seeing media- types and options by simply running
'ifconfig'. I had not noticed that this info does not show up in Debian
by just running 'ifconfig'.


Additionally I always assumed a duplex mismatch only causes severe
collisions and very slow access (the only behaviour I have previously
encountered in networks) but I never considered this would totally stop
the link from functioning.



Nonetheless I added lines such as 'post-up ethtool -s eth1 speed 100
duplex full autoneg off' to '/etc/network/interfaces' both on this
Debian testbox and at the same time reconfigured the appliance on the
other side. And yes I could get it to work like that. :)



The solution I went with however was replacing the crossover cable
between this Debian-host and the appliance by straight-through cables
and another switch. Both the Debian box and the appliance (also RealTek
NIC's by the way) not only always negotiate correctly this way, it has
an additional advantage.


The appliance on the other end sometimes has to go in layer2-fallback
and that once again tends to break the connectivity with a direct
crossover cable. Going in layer2-fallback does however not cause any
disruptions with this additional switch in place.



So the conclusion : Yes, it was indeed an autonegotiation failure :) and
No, I have no idea why I can have layer2-fallback with the additional
switch in place, yet not when the appliance is directly connected :(


Anyway another lesson learned, thanks for that ;)


--
Joris Van Herzele


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