First time here? Check out the FAQ!
THIS IS A TEST INSTANCE. Feel free to ask and answer questions, but take care to avoid triggering too many notifications.
Ask Your Question
0

Keep-Alive Packets after FIN

I have started to capture TCP packets with wireshark.

I'm using chrome for my testing:

        I have sent a http request to my local tomcat server.

        I have seen TCP handshake and data packets in wireshark.

        The server closed the connection by sending FIN flag,after 20 sec. Server's Keepalive timeout is 20 sec.

        But after sometime(45 sec) client is sending keepalive packets to server and server acknowledging the same. After 45 sec client is sending another keepalive packet, this time server responds with RST flag.

Chrome Packet

I have tried the same in firefox

        In firefox the trace is completely different

        Keep-Alive packet has been sent after 10 sec.

        Server sent the FIN,ACK after 20 sec and client immediately responds with FIN,ACK.

Firefox Packet

My Question is:

            Why Keep-alive packet is sent from chrome, after server closing the connection? And why the server is acknowledging since it's already closed ?

            Why the RST packet was not sent for first keep alive packet itself(in chrome)?

            Why the FIN,ACK was not sent from Chrome?

PS: I'm new to networking and Wireshark. Please correct me if anything wrong.

Anbu's avatar
1
Anbu
asked 2019-06-25 11:41:06 +0000
edit flag offensive 0 remove flag close merge delete

Comments

The Screenshot for looks a little bit strange... Without a trace no deeper analysis is possible. Could you please share a trace with us at public accessible place?

Christian_R's avatar Christian_R (2019-06-25 22:12:55 +0000) edit
more
  • delete

Hi Christian, Please find the capture file in below links.

Firefox Capture

Chrome Capture

Anbu's avatar Anbu (2019-06-26 06:20:09 +0000) edit
more
  • delete

Sorry but I cannot spot the sessions from the screenshot (127.0.0.1 with server port 7171) inside the trace.

Christian_R's avatar Christian_R (2019-06-26 20:32:20 +0000) edit
more
  • delete

Sorry I have changed the port to 8080, Can you check with 8080 port. I have reattached the required trace alone, Please download it again.

Anbu's avatar Anbu (2019-06-27 06:38:42 +0000) edit
more
  • delete

Well the trace for Chrome looks now different. But in your cases the server closes the connection. So from end user point of view it is very polite from the Browser to keep the session as long open as possible or the user closes the connection.

Christian_R's avatar Christian_R (2019-06-27 21:26:03 +0000) edit
more
  • delete
add a comment see more comments

1 Answer

0

Hi Anbu,

In both your capture the server closes the TCP connection.

Firefox closes the TCP connection with a correct three-way FIN-ACK, FIN-ACK, ACK after the server initiates the closing.

Chrome receives the FIN-ACK from the server and ACK's it. This looks like a four-way closure where Chrome should then send it's own FIN-ACK and have the server ACK it.

Chrome does not seem to be in a hurry to close the connexion! It seems like Chrome thinks the connection should continue and that is why it is not sending RST.

I don't know if there are other devices between the browser and Tomcat but they could be blocking Chrome FIN-ACK.

You could also try another version of Chrome.

Hope this helps.

Cheers

JFD

Spooky's avatar
191
Spooky
answered 2019-06-25 15:36:39 +0000
edit flag offensive 0 remove flag delete link
more

Comments

Hi Spooky, There is no devices/server between Browser and tomcat. I have tried the same in my another machine with same verison of chrome, this time chrome sent FIN,ACK like firefox.

I'm not sure why this happening in my machine. It might be some issue in my machine/chrome. However, why the server is acknowledging Keep-Alive packet, since it's already closed the connection? Why RST packet is being sent for second Keep-Alive.

Anbu's avatar Anbu (2019-06-26 06:54:46 +0000) edit
more
  • delete

Hello, looking at the TTL, of the IP 216.52.73.xxx has a value of 48, assuming it started at 64 for a Linux OS, it may be 6 hops away. 172.24.118.yyy has a TTL of 64, which may be the linux client. Assuming you did the capture on the Linux PC client. Would this information help to check what it is middle, and looking at the loadbalancing or firewall server.

xinxolHH's avatar xinxolHH (2019-06-26 13:01:38 +0000) edit
more
  • delete

Hi, I'm running tomcat server in my local machine only. I have reattached the required trace alone , Please download it again. Please ignore old capture.

Anbu's avatar Anbu (2019-06-27 07:13:57 +0000) edit
more
  • delete

Hello Anbu, could you provide more details of your current linux machine, Linux flavors, or can you print the output of the the following command for the timeouts: cat /proc/sys/net/ipv4/tcp_syn_retries (6 or larger)

xinxolHH's avatar xinxolHH (2019-06-27 07:47:26 +0000) edit
more
  • delete

tcp_syn_retries value is 6

Anbu's avatar Anbu (2019-06-27 09:47:11 +0000) edit
more
  • delete
add a comment see more comments

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account. This space is reserved only for answers. If you would like to engage in a discussion, please instead post a comment under the question or an answer that you would like to discuss.

Add Answer