On Sun, 20 Apr 2008, Chris Buechler wrote:
> On Sun, Apr 20, 2008 at 10:04 PM, Joe <j dot commisso at verizon dot net> wrote:
> > Fred,
> > I removed the nic setting and now it is back to defaulting to
> > half-duplex.
> Fred is 100% correct. I bet if you go look at Status -> Interfaces, if
> you haven't already rebooted the box, you'll see your collisions went
> up exponentially after you did that. Except these were late collisions
> (m0n0wall doesn't differentiate, some managed switches do) which means
> duplex mismatch, and is vastly worse than the normal collisions on
Actually, you wouldn't expect to *see* collisions at all, because the
concept of collisions is nonexistent on the full-duplex side. The
*switch* would be detecting plenty, but there's no way to see that on an
What you'd see on the NIC side is a lot of runt packets and CRC errors due
to the switch's aborted transmissions. If you *could* detect collisions
from the full-duplex side, it would be possible to recover duplex
mismatches in software.
> Never force speed and duplex. If you have to, make sure it's done on
> both the switch and the device. You can never force full duplex with
> unmanaged switches, they require autonegotiation and will fall back to
> half duplex if they don't get it. That's a requirement of nway
> autonegotiation, to retain backwards compatibility (old gear that
> doesn't autonegotiate is half duplex).
> Assuming you have just a two interface, LAN and WAN firewall, it's of
> no consequence which side you use for the 10 Mb card. I'd leave it as
> is until you can upgrade the hardware to something made in this
> decade. ;)
Well, you'd lower the collision *stats* by putting the slow NIC on the
slow side. :-) And of course, any LAN traffic with the m0n0wall as its
endpoint would benefit from the faster NIC. But, yes, the overall
WAN<->LAN throughput doesn't really care which side is which.