From: "David S. Miller" <davem@davemloft.net>
To: seb@highlab.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.6.12.5 bug? per-socket TCP keepalive settings
Date: Thu, 18 Aug 2005 15:54:21 -0700 (PDT) [thread overview]
Message-ID: <20050818.155421.65905823.davem@davemloft.net> (raw)
In-Reply-To: <E1E5sXs-00048w-Rv@highlab.com>
From: Sebastian Kuzminsky <seb@highlab.com>
Date: Thu, 18 Aug 2005 16:07:32 -0600
> Linux provides 3 non-standard TCP socket options for tweaking the
> keepalive behavior of individual sockets: TCP_KEEPIDLE, TCP_KEEPCNT,
> and TCP_KEEPINTVL. The values set on a socket with these options should
> override the system-wide default.
There is a fourth setting, the SO_KEEPALIVE socket option, which
also must be enabled explicitly by the application to enable keepalives.
It defaults to off. Your application sets this, so all is fine so far.
> The right thing is to wait IDLE seconds, then send CNT probes INTVL
> seconds apart, then reset the TCP connection.
>
> The wrong behavior I'm seeing is the first probe goes out on schedule,
> and sometimes a few more probes go out on schedule, but then it stops
> sending anything at all. It doesnt send the last of the probes, and it
> doesnt send the reset. The connection is stuck in the ESTABLISHED state,
> according to netstat.
Your test case is questionable, because you do not receive even one
ACK in established state, thus the tp->rcv_tstamp variable has no
way to get initialized. The only ACK you receive is the one in
response to the connection setup SYN, and we don't initialize
tp->rcv_stamp for that ACK.
The keepalive time checks absolutely require that tp->rcv_tstamp
has a valid value, and until you process an ACK in ESTABLISHED
state it does not.
If you send successfully or receive successfully at least one byte
over the connection, and thusly process at least one ACK in
ESTABLISHED state, I think you'll find that the keepalives behave
properly.
prev parent reply other threads:[~2005-08-18 22:54 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-18 22:07 Sebastian Kuzminsky
2005-08-18 22:54 ` David S. Miller [this message]
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=20050818.155421.65905823.davem@davemloft.net \
--to=davem@davemloft.net \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®