[ previous ] [ next ] [ threads ]
 
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  RE: [m0n0wall] Losing connection
 Date:  Thu, 27 May 2004 19:26:03 -0700 (PDT)
On Thu, 27 May 2004, Barry Mather wrote:

> Check either your m0n0 or the modem to make sure that they are both not
> set to auto detect the speed and duplex of the wan / eth port ..

Aarrgh!  Bad advice alert!

> This can sometimes cause problems when both devices on the same piece of
> wire are trying to auto detect, I've had it the same as you before,
> works for hours and hours, then dies when it goes quiet ...

It's *extremely* unlikely that autonegotiation was to blame for that, and
if it was it was only due to a buggy implementation.

Contrary to some people's belief, autonegotiation is not some kind of
"dance" that the MACs do to stumble onto a correct setting.  It expands
the original 10BaseT "link pulses" to small packets that report the
complete set of each MAC's capabilities to its peer.  Once this
information has been exchanged, both MACs select the best mutual
capability according to a predetermined priority.  This is simple enough
that it's *really* not hard to implement it correctly.  And it's
*supposed* to be done "mutually", so it's not a "conflict" to enable it on
both ends.

In some cases (e.g. inexpensive Ethernet switches), the *only* way to set
the speed and duplex mode is via autonegotiation.  This is unfortunate for
10Mb stations, since autonegotiation is rarely (if ever) available on
10Mb-only NICs, so you're stuck with half-duplex mode (802.3 requires
defaulting to 10-half in the absence of autonegotiation) even when the NIC
and the switch are both full-duplex-capable.  Many times someone has tried
to "improve" this by forcing full-duplex mode manually, which results in
a mixed-duplex configuration and horrendous packet loss whenever traffic
is high.

In general, you should *never* configure speed and duplex manually unless
you can do it manually (and consistently) on *both* ends of the
wire.

Personally, I've never had trouble with autonegotiation, though I've had
to help others who've screwed things up by trying to override it.  I
*have* had a case of a link that would get "tired" after a while (not
dead, but 30-40% packet loss), but that turned out to be a flaky switch
port.

There are a couple of things you might be confusing with autonegotiation:

1) There's a scheme called "parallel detection", whose purpose is to
automatically determine the speed *without* autonegotiation.  It's indeed
pretty kludgy, since it involves trying to bring up the link in both
10BaseT and 100BaseT modes simultaneously, and then figuring out which
modes mutually exist.  I wouldn't be at all surprised if this often had to
be turned off to avoid problems.

2) There's auto-MDI/MDIX switching (eliminating the need to worry about
"crossover" versus "straight-through" cables), which *does* involve a
certain amount of "stumbling around" to decide which pair is which.  But
its fairly rare on 10/100 stations, so most 10/100 MDI/MDIX autoswitching
is on the switch side only.  For 1000BaseT it's part of the spec, though,
and typically is also included for 10/100 in 10/100/1000 stations.  I've
heard reports of significant delays bringing up 100Mb links between pairs
of auto-MDI/MDIX stations, but the only autoswitching ports I have here
are 10/100/1000, where it works fine.  Admittedly that's different, since
1000BaseT sends *and* receives on all *four* pair, so the only thing to
"sort out" is which pair is which.

					Fred Wright