All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Kuzminsky <seb@highlab.com>
To: Stephen Hemminger <shemminger@linux-foundation.org>
Cc: netdev@vger.kernel.org
Subject: Re: bug in tcp?
Date: Mon, 16 Apr 2007 17:05:42 -0600	[thread overview]
Message-ID: <E1HdaGU-0001sZ-JS@highlab.com> (raw)
In-Reply-To: <20070416155038.3bfa5104@freekitty>

Stephen Hemminger <shemminger@linux-foundation.org> wrote:
> On Mon, 16 Apr 2007 16:28:22 -0600
> Sebastian Kuzminsky <seb@highlab.com> wrote:
> 
> > I'm seeing some weird behavior in TCP.  The issue is perfectly
> > reproducible using netcat and other programs.  This is what I do:
> > 
> >     1.  Open a TCP connection over the loopback (over IPv4).
> > 
> >     2.  Send a couple of bytes of data each way.  No problems.
> > 
> >     3.  Wait about 120 hours with no writes on either side of the
> >         connection.
> > 
> >     4.  write() a few bytes to the server's socket.  I'd expect the data
> >         to go through, but it doesnt.  I see the TCP frame from the
> >         server to the client, but instead of an ACK, the client sends
> >         back a RST.  netstat shows the bytes sitting in the server's
> >         socket's send-buffer.
> > 
> >     5.  write a few bytes to the client's socket.  The server gets
> >         these immediately.
> > 
> >     6.  On the next server-to-client retransmit, the client gets the
> >         bytes from the server.  After this, the connection works normally.
> > 
> > 
> > The libpcap capture file is here (only shows steps 4-6):
> > 
> >     http://highlab.com/~seb/tcp-idleness-bug
> > 
> > 
> > The behavior is reproducible on all kernels I've tried: 2.4.32, 2.6.19.1,
> > and 2.6.20.4.  I dont think it's iptables-related, though I'm rerunning
> > the tests on a machine without iptables to be sure.  I'll have results
> > for you in 120 hours.  ;-)
> > 
> > 
> 
> What server? Some servers do application timeouts.

I've observed the behavior with the server mode of nc, and with a homebrew
application which does not do app-level timeouts.

But anyway, application timeouts wouldnt explain the described behavior,
afaik.


-- 
Sebastian Kuzminsky

  reply	other threads:[~2007-04-16 23:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-16 22:28 bug in tcp? Sebastian Kuzminsky
2007-04-16 22:50 ` Stephen Hemminger
2007-04-16 23:05   ` Sebastian Kuzminsky [this message]
2007-04-16 23:30     ` Stephen Hemminger
2007-04-17  4:19       ` Sebastian Kuzminsky
2007-04-17  4:30       ` John Heffner
2007-04-17  4:42         ` Sebastian Kuzminsky
2007-04-17  4:44 ` Philip Craig
2007-04-17  5:35   ` Sebastian Kuzminsky
2007-04-17  6:13     ` Philip Craig
2007-04-17 13:56       ` Sebastian Kuzminsky
2007-04-18  0:03         ` Philip Craig
2007-04-23 18:45         ` bug in my understanding (was Re: bug in tcp?) Sebastian Kuzminsky
  -- strict thread matches above, loose matches on Subject: below --
2007-04-16 21:45 bug in tcp? Sebastian Kuzminsky
2007-04-16 22:10 ` David Miller

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=E1HdaGU-0001sZ-JS@highlab.com \
    --to=seb@highlab.com \
    --cc=netdev@vger.kernel.org \
    --cc=shemminger@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.