sung@mcnc.org (Wayne Sung) (04/20/88)
I had been following the checksum issue on tcpip with some interest when
we started seeing what obviously were bad addresses showing up in our
bridges. The most annoying thing was that these were not being flagged as
having CRC errors on my own network monitor (just a plain programmable
enet board with various test programs running) even though I am checking
almost every error I know about. After collecting many megs of packet traces
I finally caught one. Note that the beginning part of the packet (after the
XX's) don't correspond to any manufacturer codes. But since it is in the head
of the packet, all bridges duly noted the second 6 bytes as source addresses.
This bad address allowed us to trace back to where the packet was generated.
I can't say exactly yet how this is happening. It seems two packets have been
amalgamated but the nearest bridge did not flag that as an error. Then it
sent this "packet" out to the whole system, since the destination is not local
(or exists!) This also possibly explains something else we have been seeing -
addresses that are absolutely known to be remote nonetheless show up local. If
packets can get shifted by 6 bytes then what was a destination shows up as a
source.
If you would like more specific info send me mail.
v-------------------------
7E7C00 XXXX XXXX XXXX 5500 54BF 09FF 02A0 F403 _9_*_~U_T?___ t_
---v note 1
7E7C10 FFFC 01AA FF2A FF82 2A2A 0081 D4AA 8090 _|_*_*__**__T*__
v-------------------------
7E7C20 0401 FF00 15C1 0800 2001 2995 0800 2001 _____A__ _)___ _
-------------v note 2
7E7C30 2879 0800 4500 0398 D250 039D FF11 D130 (y__E___RP____Q0
7E7C40 806D 8832 806D 8829 BABA AAAA 0000 0000 _m_2_m_)::**____
7E7C50 0000 0004 4440 4000 0000 0000 4440 0155 ____D@@_____D@_U
7E7C60 5555 5555 5440 0000 0000 4045 5554 4444 UUUUT@____@EUTDD
7E7C70 4044 5444 4444 4040 4044 4445 5555 5555 @DTDDD@@@DDEUUUU
7E7C80 5555 5554 4444 4444 4444 5455 5454 4440 UUUTDDDDDDTUTTD@
7E7C90 4044 5555 5555 5555 5400 0000 0000 0000 @DUUUUUUT_______
7E7CA0 0000 0000 0000 0000 0000 0000 0000 0000 ________________
7E7CB0 0005 5555 5555 5555 5555 D5D5 5540 0000 __UUUUUUUUUUU@__
7E7CC0 0000 0000 0000 0000 0000 0005 5555 5555 ____________UUUU
7E7CD0 5555 5555 5555 5555 5555 5555 AAAA AAAA UUUUUUUUUUUU****
7E7CE0 AAAA AAAA AAAA AAAA A8A8 A8AA AAA8 AAAA ********(((**(**
7E7CF0 AEEA AAEA AAA8 8888 88AA AAAA AAAA AAAA .j*j*(___*******
7E7D00 AAAA AAAA AAAA AAAA AAAA AAAA AAAB FFFE *************+_~
7E7D10 AAEE EAAA AAAA AAAA AAAA AAAA AAAA AAAA *nj*************
7E7D20 AAAA AEFF EEFF FFFE EA88 8088 8888 8888 **._n__~j_______
7E7D30 8888 8888 8888 8888 8880 8080 0080 8080 ________________
7E7D40 00AA AAAA AAAA EAEA EFFF FFFF FAA8 8888 _*****jjo___z(__
7E7D50 8888 8888 8888 8888 8888 8AAA EAEE EAFF ___________*jnj_
.....more of the same.....
note 1: what obviously is a bad ethernet header
note 2: what turns out to be a perfectly good ethernet header
plus some ip header