[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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



Reply to: