[slime-devel] Lisp connection closed unexpectedly

[Helmut Eller]

* 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