tcp keep alive

[Brian DelPizzo]

I would like to enable tcp keepalive packets for a particular socket. The reason is to keep the company firewall from blasting our idle connection after 1 hour of idle time. (Can't change the Firewall). I have set the tcp_keepalive_interval to 30 minutes (down from 2 hour default). Now, in order for a port to take advantage of this feature, the SO_KEEPALIVE flag needs to be flipped on for the port. This is typically done with the setsockopt() function call. Pretty simple.

The problem is that I am using a propriatary piece of software and can't modify the code. So, how do I tell the socket to utilize the tcp_keepalive_interval and start sending keepalive packets???? Any thoughts would be welcomed.

Thanks,
Brian

[Brian Bergstrand]

There may be a setting in ndd (man ndd) to force keep alive on all sockets, but I don't think you can force it on a single socket only. As you said you'd need the source code.

HTH.

[Andrew Cowan]

Hi Brian,

If the firewall is ignoring the "ndd", why not just set up a cron job to send a couple of "pings" every twenty or so minutes and that will force the firewall to reset its keepalive counters.

[Brian DelPizzo]

Sadly, ndd only sets the global paramater for keepalive. You still need to enable it at the socket level or the ndd tcp_keepalive_interval is just ignored.

Thanks for the ping idea. I have a few similar work arounds, but would much rather take advantage of the integrated tcp driver functionality. Hey HP... how about extending ndd to turn on the SO_KEEPALIVE bit!

-Brian

[rick jones · Accepted solution]

Indeed, there is no direct way to force keepalives for a given connection from outside the application which setup or is using the connection.

I suspect the firewall is doing stateful stuff on a connection by connection basis, so simply pinging the remote IP address, while a good idea, is unlikely to keep the individual connection going.

So, getting the application modified is the way to go. The _best_ modification would be for the application to use its own application-level keepalives and not rely on the TCP stack. That would be the most portable way to go as it would not rely on being able to alter TCP/IP settings, which as you have seen here is not always possible. Having the application make the setsockopt() call for SO_KEEPALIVE is only second best.

If there is a way to induce the client-end of the application to do some operataion that is essentially a noop or at least "safe" (say like an ls in and ftp or telnet session) you might try that.

If you are _really_ confident in your abilities to write code, you could in theory write a "shim library" that intercepted say calls to connect() or accept() and added a call to setsockop(). You would then have to LD_PRELOAD this library into your application.

Again, that is not for the programming faint of heart. And, it would be at the 10th best option at best. I suppose you could contract to HP Services to have them write one for you if the need were really pressing.