[Wlug] ISP/Router/Modem Ethernet communications

[Frank Sweetser]

kstratton at fastmail.us wrote:
> I just went through some painful debug session(s) with my ISP.  For some
> reason, after forcing 10 base T half duplex through my windows box
> directly to my modem (I do not expect ISPs to support linux),everything
> suddenly worked (after reconnection and re-enabling of course).  
> 
> How often does this kind of thing happen?  I have seen this kind of
> thing before only once before, and I was using an old hub that only
> supported 10 base T, not a home router that is supposed to autodetect
> the port type.  I remember that the modem only supports 10 base T, but I
> am not 100% certain.
> 
> Does anybody have an explanation of what most likely happened?  Do not
> hesitate to skimp on technical details or references if is convenient. 
> I desperately want to understand what happened.

Actually, that sounds like it's a problem on the PC end.  Here's why.

Back when there was only 10 half, it was easy to figure out what speed and
duplex the other end was running at - 10 half!

With 100M ethernet appearing, though, you soon had dual speed cards on the
market.  Rather than having to configure each and every port explicitly, users
wanted to be able to plug in and have the card just do the right thing.
Luckily, the signaling was different enough between 10 and 100 that it was
relatively straightforward for a 100M card to detect whether the other end was
speaking in 10M or 100M, and shift speeds appropriately.  This is called,
simply enough, autosense.

However, speed is only half the equation.  Along with 100M ethernet came
switches.  Switches, by allowing for a pseudo-dedicated link per machine (as
opposed to hubs, in which the bandwidth of all links was shared by all
stations), introduced and entirely new operating mode - full duplex.  Unlike
speed, there is no reliable way to passively detect what duplex the other end
is configured for.  So, to solve this, and also to lay down a foundation for
interoperability as future network speeds appeared, the autonegotiation
protocol was developed.  Essentially, as soon as a link is established, both
ends send a few magic packets at each other advertising what speed and duplex
combinations it supports.  The two ends pick the highest performance option
supported by both, switch to that operational mode, and go on their merry way.

Even after all this, you'll still see devices appearing which only support 10
half, and don't bother to do autonegotiation.  When a newer device that does
support autonegotiation is plugged into such an older device, autonegotiation
will (obviously) fail.  The new end will then default to autodetection for the
speed, and will always use half duplex.  This is why forcing on end of a link
to full duplex, and leaving the other end on auto, will virtually always
result in a duplex mismatch, and a link that works, just with really, really
crappy performance.

Donald Becker used to have a paper floating around describing this in a little
more detail.  I can't find the original anymore, but this looks like a copy of
the same info:

http://www.negotiateddata.com/files/Bunch_Article_020095.pdf

So in the scenario you described, where the other end is sitting fixed at 10
half, it would have been up to your computer to gracefully fail
autonegotiation, and use autosense to configure the link at 10 half.  Sadly,
such bugs, where chipset manufacturers assume that everyone else out there
will always support autonegotiation, are not unheard of these days.

-- 
Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL Mencken
    GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC