Ask Your Question
0

Keep-Alive Packets after FIN

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

Anbu gravatar image

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

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

Firefox Capture

Chrome Capture

Anbu gravatar imageAnbu ( 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 gravatar imageChristian_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 gravatar imageAnbu ( 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 gravatar imageChristian_R ( 2019-06-27 21:26:03 +0000 )edit
add a comment

1 Answer

Sort by » oldest newest most voted
0

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

Spooky gravatar image

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

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

tcp_syn_retries value is 6

Anbu gravatar imageAnbu ( 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.

Add Answer

Question Tools

1 follower

subscribe to rss feed

Stats

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

Seen: 2,511 times

Last updated: Jun 25 '19

Related questions

TCP keep-alive ack and finally reset when query Database using TDS Protocol

NO-OP Ethernet Packet - Kind of Keep-Alive

why does Wireshark flag the retransmission of a single byte fragment as a keep-alive? A true keep-[alive is an ACK with no data, tcp.len==0.

What are those TCP Keep Alives

TCP Keep-Alive on Linux - 10 seconds

keep-alive response time

Is TCP Keep-Alive triggered by OTHER THAN default time interval?