LANCE/ethernet problem. (original v9n179)

tktk at physics.att.com tktk at physics.att.com
Sat Jun 2 01:33:52 AEST 1990


In v9n179, buengc!apollo at bu.edu (Douglas Chan) writes:

> We're getting a lot of the following pairs of error messages:
>  le0: Received packet with ENP bit in rmd cleared
>  le0: Received packet with STP bit in rmd cleared

> It doesn't seem to be causing any problems, it is just an annoyance...

> I've called Sun about it and they say it is caused by other systems on the
> network generating packet sizes greater than 1515.  I've tried tracking
> down the source(s) w/ etherfind but it doesn't seem to find anything
> generating packets larger than 1515.

 Pete Mellor responds (v9n189):
> I don't wish to sound ignorant, but what's magic about 1515?

Well this all makes some small amount of sense because we have seen this
problem too.  It began to happen only after we put up nfs on some
Sparcstations.  Turns out that nfs packets are logically large and need to
be fragmented down to the max ethernet size of 1526 bytes (suspiciously
close to the 1515 number above).  The fragmented packets are sent lickety
split one after another which is normally not a problem.  It turns out we
had a bad thinwire port on a repeater which propagated trash on the net
after each packet.  Because packets are normally widely spaced the trash
was normally ignored, but in the case of the fragmented packets the trash
landed on top of a packet and the above errors showed up.

Not every machine showed the problem at the same time (which might have
something to do with propagation delay?) Any kind of noise on a very busy
net would probably turn up the same problem.  etherfind shows the size of
the ethernet packet not the logical ip packet, I think fragmented packets
are preceeded by an *.

Terry Kovacs
AT&T Bell Labs
tktk at physics.att.com



More information about the Comp.sys.sun mailing list