Le mercredi 24 ao?t 2011 ? 00:32 +0300, Daniel Baluta a ?crit :

On Tue, Aug 23, 2011 at 11:55 PM, Eric Dumazet [off-list ref] wrote:

quoted

TCP in RFC 1122 section 4.2.2.13:

 "A host MAY implement a "half-duplex" TCP close sequence, so that an
 application that has called CLOSE cannot continue to read data from the
 connection. If such a host issues a CLOSE call while received data is
 still pending in TCP, or if new data is received after CLOSE is called,
 its TCP SHOULD send a RST to show that data was lost."

So, this means that server's CLOSE operation is issued while received
data is still pending? I will analyze ftp's server code, but this is strange
since P4 [221 Have a nice day!\r\n] it is generated as a response for
P3 [QUIT\r\n]. So P4 must have been fully received.

tcpdump only shows TCP stack did receive the frame, not that it was
_read_ by application.

Only strace could eventually say if the input queue was really drained
before the close().

Maybe server decided to close the connexion before reading the QUIT
command from client.

Also, looking at the capture no data is received from the client after
server calls CLOSE (P5) (there are only ACKs and FIN - P6, P7, P8).

That doesnt matter.

If data was received (and ACKnowledged by TCP stack) _before_ close(fd),
but not yet read by application, TCP must send an RST to be RFC
compliant.