I've been doing some experiments with the keepalive code in 2.4.0-test10 here
(I want to avoid the 2.2.x NAT I'm using (for which I don't have root) from
timing out my connections). To test it, I reduced both tcp_keepalive_time and
tcp_keepalive_intvl to 1. Using ethereal, I saw that the keepalives were sent
as expected, but only for one of the two idle TCP connections I had to a given
host (I was testing with two remote hosts, each with two idle TCP connections,
one in port 5500 and the other in port 5501). I only saw activity on 5500, yet
netstat told me both were still active.
This means that keepalive is useless for keeping alive more than one connection
to a given host.
--
Cesar Eduardo Barros
[email protected]
[email protected]
> This means that keepalive is useless for keeping alive more than
> one connection
> to a given host.
Actually, keepalive is useless for keeping connections alive anyway. It's
very badly named. It's purpose is to detect dead peers, not keep peers
alive.
DS
On Sat, Dec 23, 2000 at 04:19:31PM -0800, David Schwartz wrote:
>
> > This means that keepalive is useless for keeping alive more than
> > one connection
> > to a given host.
>
> Actually, keepalive is useless for keeping connections alive anyway. It's
> very badly named. It's purpose is to detect dead peers, not keep peers
> alive.
Then what do you do when you are behind a NAT? And how do you expire entries in
ESTABLISHED state that could stay lingering forever without some sort of
keepalive? (The FINs might have been lost due to a conectivity transient, so
you can have another perfectly valid and alive connection with the same host,
and application-level timeouts are useless for some applications
(*cough*nc*cough*))
--
Cesar Eduardo Barros
[email protected]
[email protected]
On Sat, 23 Dec 2000, Cesar Eduardo Barros wrote:
> Then what do you do when you are behind a NAT? And how do you expire entries in
> ESTABLISHED state that could stay lingering forever without some sort of
> keepalive? (The FINs might have been lost due to a conectivity transient, so
> you can have another perfectly valid and alive connection with the same host,
> and application-level timeouts are useless for some applications
> (*cough*nc*cough*))
Typically, you choose a practical value for timing out inactive but
otherwise seemingly established TCP connections. The 2.4 connection
tracking code (used for NAT) uses a value of five days for this.
- James
--
James Morris
<[email protected]>
On Sun, Dec 24, 2000 at 12:52:12PM +1100, James Morris wrote:
> On Sat, 23 Dec 2000, Cesar Eduardo Barros wrote:
>
> > Then what do you do when you are behind a NAT? And how do you expire entries in
> > ESTABLISHED state that could stay lingering forever without some sort of
> > keepalive? (The FINs might have been lost due to a conectivity transient, so
> > you can have another perfectly valid and alive connection with the same host,
> > and application-level timeouts are useless for some applications
> > (*cough*nc*cough*))
>
> Typically, you choose a practical value for timing out inactive but
> otherwise seemingly established TCP connections. The 2.4 connection
> tracking code (used for NAT) uses a value of five days for this.
>
Yeah. But I'm stuck with a NAT (which isn't mine, btw) which uses 2.1.xxx-2.2.x
(according to nmap). Which had a default of 15 *minutes* (as I read in a HOWTO
somewhere). I'm trying to convince the sysadmin to raise it to two hours, but I
bet it'll be hard.
--
Cesar Eduardo Barros
[email protected]
[email protected]
On Sat, Dec 23, 2000 at 09:31:56PM -0200, Cesar Eduardo Barros wrote:
>
> I've been doing some experiments with the keepalive code in 2.4.0-test10 here
> (I want to avoid the 2.2.x NAT I'm using (for which I don't have root) from
> timing out my connections). To test it, I reduced both tcp_keepalive_time and
> tcp_keepalive_intvl to 1. Using ethereal, I saw that the keepalives were sent
> as expected, but only for one of the two idle TCP connections I had to a given
> host (I was testing with two remote hosts, each with two idle TCP connections,
> one in port 5500 and the other in port 5501). I only saw activity on 5500, yet
> netstat told me both were still active.
I just tried it and it works fine here with 2.4.0-test13-pre
You should be aware that the sysctls are only picked up after a timer timeout
or when a socket is newly created. When the sockets are already active it
takes a timeout for them to take effect. The default timeout is 2 hours.
-Andi
On Sun, Dec 24, 2000 at 10:14:55AM +0100, Andi Kleen wrote:
> On Sat, Dec 23, 2000 at 09:31:56PM -0200, Cesar Eduardo Barros wrote:
> >
> > I've been doing some experiments with the keepalive code in 2.4.0-test10 here
> > (I want to avoid the 2.2.x NAT I'm using (for which I don't have root) from
> > timing out my connections). To test it, I reduced both tcp_keepalive_time and
> > tcp_keepalive_intvl to 1. Using ethereal, I saw that the keepalives were sent
> > as expected, but only for one of the two idle TCP connections I had to a given
> > host (I was testing with two remote hosts, each with two idle TCP connections,
> > one in port 5500 and the other in port 5501). I only saw activity on 5500, yet
> > netstat told me both were still active.
>
> I just tried it and it works fine here with 2.4.0-test13-pre
>
> You should be aware that the sysctls are only picked up after a timer timeout
> or when a socket is newly created. When the sockets are already active it
> takes a timeout for them to take effect. The default timeout is 2 hours.
>
I noticed that, so I exited the program and reloaded it after each change. I
still don't know why it worked only with the first socket here (both sockets
are opened by the same program). Maybe something changed in the networking code
since test10?
--
Cesar Eduardo Barros
[email protected]
[email protected]
> Yeah. But I'm stuck with a NAT (which isn't mine, btw) which uses 2.1.xxx-2.2.x
> (according to nmap). Which had a default of 15 *minutes* (as I read in a HOWTO
> somewhere). I'm trying to convince the sysadmin to raise it to two hours, but I
> bet it'll be hard.
ipchains -S timeoutval 0 0 is the only way to do this.
Igmar
On Mon, Dec 25, 2000 at 04:27:07PM +0100, Igmar Palsenberg wrote:
>
> > Yeah. But I'm stuck with a NAT (which isn't mine, btw) which uses 2.1.xxx-2.2.x
> > (according to nmap). Which had a default of 15 *minutes* (as I read in a HOWTO
> > somewhere). I'm trying to convince the sysadmin to raise it to two hours, but I
> > bet it'll be hard.
>
> ipchains -S timeoutval 0 0 is the only way to do this.
>
That's the easy part. Convincing the sysadmin (which probably is not very
clueful) is the hard one. But this is getting too OT, EOT.
--
Cesar Eduardo Barros
[email protected]
[email protected]
> On Sat, Dec 23, 2000 at 04:19:31PM -0800, David Schwartz wrote:
> > > This means that keepalive is useless for keeping alive more than
> > > one connection
> > > to a given host.
> > Actually, keepalive is useless for keeping connections
> > alive anyway. It's
> > very badly named. It's purpose is to detect dead peers, not keep peers
> > alive.
>
> Then what do you do when you are behind a NAT?
If the administrator of the NAT meant for you to have a permanent mapping,
she would have put one there. Using keepalives to hold a NAT entry open
indefinitely without activity would be considered abuse in most NAT
configurations. The NAT might not consider a keepalive to be activity anyway
(arguably, it shouldn't).
> And how do you
> expire entries in
> ESTABLISHED state that could stay lingering forever without some sort of
> keepalive? (The FINs might have been lost due to a conectivity
> transient, so
> you can have another perfectly valid and alive connection with
> the same host,
> and application-level timeouts are useless for some applications
> (*cough*nc*cough*))
I don't understand this argument. First you demonstrate the need for
application-level timeouts, then you say application-level timeouts are
useless. Actually, your first argument is correct, protocols layered on top
of TCP that don't provide for timeouts are defective.
DS
On Mon, Dec 25, 2000 at 04:33:07PM -0800, David Schwartz wrote:
>
> > On Sat, Dec 23, 2000 at 04:19:31PM -0800, David Schwartz wrote:
>
> > > > This means that keepalive is useless for keeping alive more than
> > > > one connection
> > > > to a given host.
>
> > > Actually, keepalive is useless for keeping connections
> > > alive anyway. It's
> > > very badly named. It's purpose is to detect dead peers, not keep peers
> > > alive.
> >
> > Then what do you do when you are behind a NAT?
>
> If the administrator of the NAT meant for you to have a permanent mapping,
> she would have put one there. Using keepalives to hold a NAT entry open
> indefinitely without activity would be considered abuse in most NAT
> configurations. The NAT might not consider a keepalive to be activity anyway
> (arguably, it shouldn't).
Well, consider the scenario of an application which opens a control connection
and a data connection, and the data connection remains idle for some hours
while you get to the beginning of the queue, and then the transfer starts. The
data connection is not open forever, and the timeout (and the periodic pings)
is on the control connection.
The problem is that, after four or more hours of waiting, when the other side
finally starts sending, the NAT has already forgotten about the connection.
(In case someone is wondering, the application I'm talking about is fidelio.
Which is pretty useless on busy sites behind a NAT because of that.)
--
Cesar Eduardo Barros
[email protected]
[email protected]
Cesar Barros wrote:
> On Mon, Dec 25, 2000 at 04:33:07PM -0800, David Schwartz wrote:
> > If the administrator of the NAT meant for you to have a
> > permanent mapping,
> > she would have put one there. Using keepalives to hold a NAT entry open
> > indefinitely without activity would be considered abuse in most NAT
> > configurations. The NAT might not consider a keepalive to be
> > activity anyway
> > (arguably, it shouldn't).
> Well, consider the scenario of an application which opens a
> control connection
> and a data connection, and the data connection remains idle for some hours
> while you get to the beginning of the queue, and then the
> transfer starts. The
> data connection is not open forever, and the timeout (and the
> periodic pings)
> is on the control connection.
I would consider that application broken. The data connection should be
opened when it's needed, not left idle for hours and used later. If the data
connection does break somehow, there should be a provision for
re-establishing it without losing all application-level state.
I'm not saying it shouldn't be possible to work around a defective
application protocol. But to expect there to be some easy way to just flip a
switch and fix it is unreasonable.
The NAT may not even consider a keepalive to be activity. There's no
logical reason it should if the timeout is less than many hours.
DS
In article <[email protected]> you wrote:
> Well, consider the scenario of an application which opens a control connection
> and a data connection, and the data connection remains idle for some hours
> while you get to the beginning of the queue, and then the transfer starts. The
> data connection is not open forever, and the timeout (and the periodic pings)
> is on the control connection.
The other way around (idle control connection) is trapped by Linux FTP
Masquerading, it will make sure the control connection does not time out, as
long as the Data connection is transmitting Data. This is even done in PASV
mode (thats why the FTP Masq mdule is uefull even in PASV mode).
Greetings
Bernd