> Look at the docs:
>
> "0x82
>      Out of window collision. This typically occurs when *some other*
>      (emphasis added) Ethernet host is incorrectly set to full duplex
>      on a half duplex network. "
>
>      "Both of these errors are the result of network errors that
should
>      be corrected. They do not represent driver malfunction."
>
> So, I suspect that the problem is on the other end of the wire.
[Therefore]
> changing my end will accomplish nothing except breaking what I already
have
> in place. I suppose I could open a dialogue to my brain-dead ISP (but,
I repeat
> myself) and get nowhere, but why?
>
> I'd jusd like to get rid of the messages. I suppose I could try my
hand at re-
> writing the driver, but ...
>
> | When transmit errors occour on LAN, it means that there ARE hardware
> | problems.
>
> But not on my machine, I suspect.
>
> | I can understand that since everything works quite well on your
> | internal net and all connections to the internet, your wish is to
> | have those messages removed.
>
> | But removing the messages 'per se' does not solve your problem.
>
> Why not? The messages are precisely the problem. Removing the messages
would
> solve the problem nicely.
>
> "if it ain't broke, don't fix it."
>
> | Please explain us more about your setup.
>
> Sure: internal LAN talks to one NIC on the router; the other NIC talks
to the
> ISP which routes for the internet.

Don't be so quick to state that there's nothing broken.  Just because
traffic is flowing doesn't mean it flowing optimally.  If you have an
ethernet link with two ends mis-matched for duplex, everything will
appear to work fine (you'll just get the annoying errors in your logs,
along with TX and/or RX errors, and high numbers for collisions) until
you start pushing the bandwidth limit of the link, at which point things
can rapidly degenerate to where you're available bandwidth is getting
eaten-up by re-transmissions (kind of an ethernet duplex equivalent of a
 broadcast storm).

I had a similar problem when hooking up to a Cogent 100MBit ethernet
drop.  The switches used by Cogent didn't auto-negotiate properly, so my
firewall NIC was stuck in half duplex, while the Cogent end was running
full duplex.  To fix the problem (and it *IS* a problem), I had to
download/compile one of the utilities from the sycld site (I run Dan
Becker's Tulip drivers on most of my Dachstein boxes), and use it to
force the link to 100 MBit full duplex.  Once I did this, everything was
peachy...no more TX/RX errors or collisions, and no more weird log
messages.

You may be having a similar problem, in which case I urge you to
actually fix it, rather than simply ignore or disable the error
messages.    Find out what you're hooked to on the ISP end...at least to
the level of 10/100 MBit, full/half duplex.  Compare this to the link
status on your end, and force your end to match, if required.
Auto-negotiation is wonderful when everything works, but if you're
hooked to something that doesn't support auto-negotiation (like a lot of
the fixed speed/duplex switches used by ISP's, where shaving every buck
off equipment cost matters), it's frequently necessary to bypass
auto-negotiation and "peg" a specific set of operating parameters, so
don't just ignore those error warnings.

Your network will thank you every time it's carrying a heavy traffic
load. :-)

Charles Steinkuehler
http://lrp.steinkuehler.net
http://c0wz.steinkuehler.net (lrp.c0wz.com mirror)



-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to