Arnaud Brand wrote:
> Snooping showed that the receiving end sent RST packets.
> My TCP is quite rusty, but if I remember well, RST does not mean "close
> the connection".
Correct. It means "I don't know what you're talking about, so please go
away."
> Does anyone have a clue why the sending side chooses to close the
> connection ?
Causes for RST include:
- peer application is intentionally setting the linger time to zero
and issuing close(2), which results in TCP RST generation.
- peer has crashed and rebooted, and thus no longer has that
connection open.
- stateful middlebox (such as firewall or load-balancer) has lost
state for the connection and is terminating it.
- network misconfiguration, such as duplicate IP addresses.
- bugs in one or both peers (often related to TCP keepalive; key
signature of such a problem is an apparent two-hour time limit).
You (at least) have to analyze the packet sequences to determine what is
going wrong. Depending on the nature of the problem, it may also take
in-depth kernel debugging on one or both peers to locate the cause.
(For what it's worth, it's not an OpenSolaris-specific issue. These
sorts of unexpected RSTs plague users and are hard to diagnose properly,
even on a good day.)
> Furthermore, the receiving end doesn't even get FIN packets from the
> sending end.
That's correct behavior when RST is seen. RST is an abortive disconnect
-- quit right now; don't try to finish. FIN is an orderly disconnect --
finish sending what you have then close normally.
RST doesn't (and shouldn't) cause FIN.
> Again, if I remember well, one should send FIN packets and wait for
> FIN/ACK (or timeout I guess) before closing the connection.
Only for a normal connection termination. If the connection is
_broken_, you should see RST instead.
--
James Carlson 42.703N 71.076W <[email protected]>
_______________________________________________
networking-discuss mailing list
[email protected]
