Netdev List
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Daniel Baluta <daniel.baluta@gmail.com>
Cc: netdev@vger.kernel.org, kernelnewbies <kernelnewbies@kernelnewbies.org>
Subject: Re: TCP - RST flag
Date: Tue, 23 Aug 2011 23:50:20 +0200	[thread overview]
Message-ID: <1314136220.4478.6.camel@edumazet-laptop> (raw)
In-Reply-To: <CAEnQRZChkX0K_qWf-Gmu8YeAyxoOb7DTPvvbnA5YxSHEMj_J=g@mail.gmail.com>

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@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.

  reply	other threads:[~2011-08-23 21:50 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-23 20:31 TCP - RST flag Daniel Baluta
2011-08-23 20:55 ` Eric Dumazet
2011-08-23 21:32   ` Daniel Baluta
2011-08-23 21:50     ` Eric Dumazet [this message]
2011-08-23 22:05       ` Daniel Baluta

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1314136220.4478.6.camel@edumazet-laptop \
    --to=eric.dumazet@gmail.com \
    --cc=daniel.baluta@gmail.com \
    --cc=kernelnewbies@kernelnewbies.org \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox