At 7:53 PM -0800 11/28/99, Andrew Brown wrote:
>>> 15:04:20.729215 55:55:55:55:55:55 58:55:55:55:55:55 800c 5461:
>>>                          5555 fcff 5555 fcff 5555 fcff 5555 fcff
>>>                          5555 fcff 5555 fcff 5555 fcff 5555 fcff
>>>                          5555 fcff 5555 fcff 5555 fcff 5555
>>
>>  Depending on the kind of network eq	uipment you have, you're
>>bound to see beaucoup packets of this sort.  I can't tell for sure,
>>but this could be a collision, a late collision, or just a bogus
>>packet from an exuberant driver.  We had cases of this on our
>>network, which we "sort of" traced to an Intel box, running some
>>variant of Linux, using an Intel EtherExpress Pro/100B.  Couldn't
>>tell for sure, since there's no way to trace this stuff back to its
>>source(*), but we hypothesized it was a bad driver.  If we unplugged
>>the sucker, the problems went away.  We ended up replacing the board.
>

>>In any case, this looks like pure junk, either manufactured by the
>>network, or provided to you by a pointer into random memory, by a
>>wayward driver.  Nothing in it to lead you back to a culprit, unless
>>the bit patterns look familiar (which is how we got to the linux
>>box).
>
>it looks like junk, but it's rather regular.  i'd sort of convinced
>myself that a machine reading manchester encoding on a wire where a
>differential manchester encoded collision took place would see this,
>but that would just explain the fives, not the other stuff.

If it were a collision then only the later bytes should be garbage, not
generally the header (unless there is a lot of interleaving on Ethernet
encoding).  A more likely scenario would be failure to lock up on the
signal leading into the packet.  This could be due to cable and/or signal
strength limits or a less-than-optimal receive buffer in your interface.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
h.b.hotz@jpl.nasa.gov, or hbhotz@oxy.edu