Today I noticed a lot of checksum errors in an Ethereal 0.9.9 trace. Things
went downhill from there, as there was evident weirdness in the first three
frames, and the pattern repeated over and over again.
Frames 1 and 2 were identical HTTP continuation packets from an Internet
host to a host on my local LAN, but they were only .000679 seconds. That
seemed a little strange, but perhaps believable given congestion conditions
on the Internet backbone.
The really BIG problem became apparent in frame #3. The summary of the frame
in Ethereal's top panel showed the packet to be an ACK from my local
desktop, but the decode in the middle panel was actually a portion of the
previous frame! The top panel showed local source address 10.136.128.9, but
the middle panel showed the source IP of the Internet server. The summary
panel said the source port was 3428 and the dest port was 80, but the decode
panel said exactly the opposite. The sequence and ACK numbers were also
reversed between the top panel and middle panel. The 3rd frame appeared to
be a truncated version of frame 2; it was only 54 bytes long, however, and
showed up as a checksum error.
I converted data from the raw hex in the bottom panel, and found that the
bottom panel agreed with the middle panel, but not with the summary panel.
The pattern repeated many times. I then noticed this same weirdness in
another trace. I have not looked at a third trace yet, but I am wondering if
there is some Ethereal or WinPcap issue here?
--Eric