This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

TCP Keep-Alive packets sent after waiting about 29 sec

0

alt text We are experiencing performance issue with one of our application. I ran Wireshark on the server and captured the traffic. I noticed that after a few packets the client sends (TCP Keep-Alive) packet after it waits almost 29 sec. Can someone elaborate in the issue please?

asked 11 Oct '17, 18:38

cnladmin's gravatar image

cnladmin
11●1●1●4
accept rate: 0%

edited 11 Oct '17, 18:42

One Answer:

1

Generally 'keep-alive' packet is a probe to figure out: is other endpoint still active on this particular TCP connection?

In your case some data exchange happens between server and client, then the server sends last data packet 261194 and stops transmitting further. The client ACKs this packet, but because it doesn't receive neither more data nor connection close commands it becomes uncertain - what's happened to other end? So after timeout it sends keep-alives to ask the server: are you still alive or has you been rebooted/got stuck somehow?

The server responds with Keep-alive ACK that means: my TCP stack is still active and is maintaining this TCP connection, BUT I do not receive any data/commands from my own application layer corresponding to this connection. Later it starts to send data again.

So, reasons could be:

  • server app process gets stuck from time to time;
  • server process just has nothing to send;
  • server overload (but timeouts are pretty stable for that reason).

The next we need to know is what app type is it, maybe this is normal behavior? And also it's would be useful to monitor server app process itself.

answered 11 Oct '17, 22:25

Packet_vlad's gravatar image

Packet_vlad
436●1●6●13
accept rate: 20%

edited 11 Oct '17, 22:29

Thank you very much for your great answer. The application name is Bid2Win, it is a construction application for job bidding. I will monitor the app process. Do you recommend any application for the this task? or should we just use Windows process monitor?

Regards,

(12 Oct '17, 13:34) cnladmin

I myself prefer to use Procmon and TCPview utilities from Sysinternals package. In Procmon you can add filter to log only needed process and see it's activity: network, filesystem and so on. Therefore you could spot whether Bid2Win was transmitting data or not at any particular point of time. At the same time you can capture traffic with Wireshark and later do a correlation beetween the two.

Check it out also that data transfer stops for appr. 60 sec, and it looks like some timer (hardcoded or defined somewhere in settings). Maybe you'll be able to spot this number somewhere in the software.

(13 Oct '17, 00:07) Packet_vlad