* Matthew Mondor [2009-12-07 04:31+0100] writes:
The file is attached below and can be opened with Wireshark. Some TCP packets have a "TCP CHECKSUM INCORRECT". This seems very odd to me. Does somebody know what it means?
The text results of tcpdump (especially using -nvvxX flags) or a binary tcpdump result would be easier for me (and perhaps others?) to read.
When I encountered packet checksum errors here it was due to a card/driver specific TCP hardware acceleration feature when enabled, or hardware problems, although a faulty software packet translator or IP stack bug is not impossible... Since your test appears to be local, I doubt NIC TCP acceleration to be the problem however.
In case your question was litteral about "what it means?" (sorry for stating the obvious if it wasn't), a TCP checksum is wrong for a packet when it doesn't match the actual checksum of its payload (indicating it was probably corrupted in transit, or wrongly calculated), and this is rarely calculated/verified at the application layer, except by userland packet-level analysis/manipulation tools.
It could even be a tshark-specific problem...
Everything goes through the loopback device and no real hardware is involved so it strange to see checksum errors. Maybe it's just a Wireshark weiredness.
Anyway, my current hypothesis is that Emacs' connect() is interrupted by a timer and, instead of retrying, Emacs closes the socket and starts over with a new socket. That would explain the two connections from different ports in the trace. It's also not entirely unreasonable to start with a fresh socket if we assume that the server accepts multiple connections, but our server accepts one connection only. It's still strange that the 3-way handshake for the second connection succeeds. Need to dig deeper.
Helmut