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.
next prev parent reply other threads:[~2007-04-17 5:04 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
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
-- 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=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 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.