CSS keepalive TCP flags

Unanswered Question
Jul 14th, 2008

CSS keepalive TCP flags

Hi. I have a problem with the way an application behaves in response to CSS tcp keepalives, I'd be grateful for any advice.

Using standard TCP keepalives, an application logs a broken connection for every keepalive, filling up the app logs, causing the administrators to complain. If I change the tcp-close type to FIN, the application doesn't log an error, but it still logs the connection, same complaint from the admins.

The application developers feel that it's not their problem, they're comparing the keepalives to nmap probes and indeed, it is possible to confirm that the service is up with nmap, without generating an error/connection log entry on the server.

According to some Wireshark captures, the TCP flags of a CSS keepalive, compared to an nmap probe, are as follows;



CSS --> Syn --> Server

CSS <-- Syn, Ack <-- Server

CSS --> Ack --> Server

CSS --> Rst, Ack --> Server

nmap -sS


NmapPC --> Syn --> Server

NmapPC <-- Syn, Ack <-- Server

NmapPC --> Rst --> Server

So, my question is, can the tcp behaviour of CSS keepalives be modified, to dispense with the arguably superfluous 'ack'ing that's illustrated above?



I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Syed Iftekhar Ahmed Mon, 07/14/2008 - 09:28

If I am remember correctly TCP probe behavior was changed to the current one in 7.2 code.

(Lots of people had to enable tcp-close type Fin due to server errors:)

Prior to that it was similar to the one you mentioned as nmap.

I am afraid there is know way to return to the way it was done before.

One option would be to write a script and use it for probing servers.


Andrew.Gray Tue, 07/15/2008 - 06:16

Thanks for the replies.

I've tried tcp-close fin, it stops an error being logged, but the application still logs the connection.

I wouldn't be concerned, other than the fact it clearly is possible to both establish that the service is running on the server and not log the connection attempt, using Nmap's more abbreviated tcp behaviour.

I am curious, though. What is the CSS acknowledging when it sends an ACK in the RST packet?




This Discussion