TCP - RST flag

[Daniel Baluta]

On Wed, Aug 24, 2011 at 12:50 AM, Eric Dumazet <eric.dumazet at gmail.com> wrote:
> Le mercredi 24 août 2011 à 00:32 +0300, Daniel Baluta a écrit :
>> On Tue, Aug 23, 2011 at 11:55 PM, Eric Dumazet <eric.dumazet at gmail.com> wrote:
>
>> > 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.

I see. Thanks a lot for your explanations. I will further use strace
to see what's going on.

Daniel.