Keep-Alive Packets after FIN

keep-alive

asked 2019-06-25 11:41:06 +0000

Anbu
1 ●1 ●1 ●1

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.

edit retag flag offensive 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 ( 2019-06-25 22:12:55 +0000 )edit

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

Firefox Capture

Chrome Capture

Anbu ( 2019-06-26 06:20:09 +0000 )edit

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

Christian_R ( 2019-06-26 20:32:20 +0000 )edit

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 ( 2019-06-27 06:38:42 +0000 )edit

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 ( 2019-06-27 21:26:03 +0000 )edit

add a comment

answered 2019-06-25 15:36:39 +0000

Spooky

191 ●47 ●7 https://www.wireshark.org

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

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 ( 2019-06-26 06:54:46 +0000 )edit

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 ( 2019-06-26 13:01:38 +0000 )edit

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 ( 2019-06-27 07:13:57 +0000 )edit

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 ( 2019-06-27 07:47:26 +0000 )edit

tcp_syn_retries value is 6

Anbu ( 2019-06-27 09:47:11 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Keep-Alive Packets after FIN

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Keep-Alive Packets after FIN edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

Keep-Alive Packets after FIN