netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Philip Craig <philipc@snapgear.com>
To: Sebastian Kuzminsky <seb@highlab.com>
Cc: netdev@vger.kernel.org
Subject: Re: bug in tcp?
Date: Tue, 17 Apr 2007 14:44:53 +1000	[thread overview]
Message-ID: <462450C5.5080702@snapgear.com> (raw)
In-Reply-To: <E1HdZgM-0001n2-F0@highlab.com>

Sebastian Kuzminsky 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.  ;-)

It sounds like it could easily be iptables related, if you have iptables
rules that only allow new connections in the client to server direction,
which is quite normal.

The default iptables timeout for TCP connections is 5 days.
So after 5 days of idle, any packets from the server will be treated
as a new connection and the iptables rules will drop them.

  parent reply	other threads:[~2007-04-17  5:04 UTC|newest]

Thread overview: 13+ 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
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 [this message]
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

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=462450C5.5080702@snapgear.com \
    --to=philipc@snapgear.com \
    --cc=netdev@vger.kernel.org \
    --cc=seb@highlab.com \
    /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;
as well as URLs for NNTP newsgroup(s).