netdev - Re: TCP - RST flag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAEnQRZB2-2FiLPiv6mhsJFgtQS3X5N0xQJfnV9S=kTMkz0f77g@mail.gmail.com>
Date:	Wed, 24 Aug 2011 01:05:07 +0300
From:	Daniel Baluta <daniel.baluta@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	netdev@...r.kernel.org,
	kernelnewbies <kernelnewbies@...nelnewbies.org>
Subject: Re: TCP - RST flag

On Wed, Aug 24, 2011 at 12:50 AM, Eric Dumazet <eric.dumazet@...il.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@...il.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.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html