TCP-Keepalive & RST

[Timo J]

System X initiates socket connection with system Y. System Y is hpux. After two hours (exact time 7199.727956 seconds) with no activity on connection, system X sends keepalive message and hpux replies with ack. Everything ok this far.

After that, there's still no activity on connection and after 7200.046245 seconds system X sends again keepalive message. To that second message, hpux replies with RST.

TCP-parameter tcp_keepalive_interval in hpux is 7200 seconds. (But ain't that just for hpux initiated connections on this case?)

What might be causing this? Is there something to do with that TCP-parameter in hpux, because
those times matches to that?

I thought that the system which initiates the connection, sends also the keepalives and the remote system (hpux) just answers to those but doesn't send any keepalive messages.

[Jim Keeble]

The keep-alive probe can be sent by either system or both, depending on whose timer pops first. The application (on either side) can enable keep-alive by calling setsockopt() on it's own socket and setting the keep-alive option.

In your case, it seems like the HP system may have powered off or closed the connection during a time when the network was broken and couldn't deliver the FIN, etc, to server X.

Or, there could have been a device on the HP's subnet trying to use the HP's IP address. When server X's keep-alive send the keep-alive packet the second time, it happens to be delivered to the wrong host, who replies with RST because he has no knowledge of the connection. Or, if it's a serviceguard environment, the package IP could have moved to an alternate server.

Difficult to say for sure without traces on both sides, but you might check the nettl log on the HP for a message that indicates someone is trying to use his IP address. You can read the log file with "netfmt -f /var/adm/nettl.LOG00" .

[vijay_37]

Hi,

Please check whether Keepalive is enabled in HP-UX. If you have software running in HP-UX, that should call setsockopt with KEEPALIVE. By default, KEEPALIVE is disabled. RST is kind of error signal that happens when Intermediate routers can crash and reboot, phone lines may go down and back up, but as long as neither host at the ends of the connection reboots, the connection remains established.
A common example showing the need for the keepalive feature nowadays is when personal computer users use TCP/IP to login to a host using Telnet. If they just power off the computer at the end of the day, without logging off, they leave a half-open connection. In Figure 18.16 we showed how sending data across a half-open connection caused a reset to be returned, but that was from the client end, where the client was sending the data. If the client disappears, leaving the half-open connection on the server's end, and the server is waiting for some data from the client, the server will wait forever. The keepalive feature is intended to detect these half-open connections from the server side.

[rick jones]

Unless suppressed with the ndd setting tcp_text_in_resets, when an HP-UX 11.X TCP sends a RST segment, there will be some number of bytes in the RST segment with an ASCII-encoded (man ascii if you don't have the codes memorized :) reason message. That may help further diagnose the reason(s) behind the second keepalive probe eliciting a RST segment.

As already pointed-out, keepalives are independent on either side. What is tied to the initiator is who is supposed to track TIME_WAIT. That goes to the first system to send a FIN segment.

In HP-UX 11 there is also a tcp_keepalive_detached_interval which defaults to 120 seconds (two minutes). This is how soon after an application calls close() will TCP start sending keepalives if it does not receive segments from the remote.

ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_ndd.txt