TCP keepalive seems to send to only one port

This means that keepalive is useless for keeping alive more than one connection
to a given host.

Quoted 4 lines

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*))

Quoted 6 lines · Cesar Eduardo Barros

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.

Quoted 5 lines

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.

Quoted 4 lines

Quoted 4 lines

This means that keepalive is useless for keeping alive more than one connection
to a given host.

Quoted 4 lines

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*))

Quoted 12 lines · David Schwartz

Quoted 9 lines

Quoted 4 lines

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.

Quoted 1 line

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).

Quoted 7 lines · David Schwartz

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'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.

Quoted 9 lines · Cesar Eduardo Barros

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.