CODEWITHSUNDEEP
phplinuxnetwork-programmingcentostcp
Julian P.
Julian P.

Reputation: 11

Server takes too long to send FIN, ACK

I have a mobile app (in capture is 186.18.33.118) Requesting data from some simple http server from php api (200.80.41.246).

When I send request from my app, I can not access to the web server from the same lan That send request, for a minute.

The server is a Centos 7 apache and all updates.

I analize with tcpdump the packets between the server and my application (below show the capture when I request from the app to server and after from my browser to the server to open with wireshark).

The strange all I can see is that the server takes too long to send the FIN packet, ACK

What can be wrong?

EDIT/ADD

Capture with tcpdump

(steps of how I make the capture)

  1. I opened the app in the phone (this app makes consults to the wordpress installed on server 200.80.41.246)

  2. after few seconds i tried to enter from the browser (from the same lan network that is connected to the cellphone) to wordpress

  3. the server brings me a message saying: error timeout (near the packet 45)

  4. so I try many times and after a minute aproximately connection works properly (near the packet 110)

EDIT 2

I made the comparison between the query to the api from the browser and from the app, because when I make the request from the browser does not bring problems, and the difference I found is that the browser sends a RST packet that the app does not send. Below I leave a picture, the top is the query from the browser and the bottom is the query from the app.

analyzed capture by wireshark

Any suggestions?

Upvotes: 0

Views: 3930

Answers (3)

Julian P.
Julian P.

Reputation: 11

In analyzing the configurations of connections in Linux, I found two parameters that allowed reuse previously closed connections, that were enabled. When I wanted to access from another device with the same public IP that was before an open connection conflicted and there would be a new connection, the disable and now works correctly.

The parameters are:
net.ipv4.tcp_tw_recycle
net.ipv4.tcp_tw_reuse
They were to 1 (enabled)

To disable execute commands
Sysctl net.ipv4.tcp_tw_recycle = 0
Sysctl net.ipv4.tcp_tw_reuse = 0

Upvotes: 1

Tomer Petel
Tomer Petel

Reputation: 344

It will be helpful if you'll share the tcpdump. Usually a FIN packet is sent after a certain timeout value which is depends on the OS.

On Linux I the default value is 60 seconds. Look here: TCP parameters, Linux kernel

Edit:

I looked at the capture and there are a few things:

  1. The TCP retrasmissions happens when the server is simply not answering to the SYN request with a [SYN,ACK] packet. It tries to open many sessions to the server but the server is not answering (~20 sessions). The TCP retransmission is part of the TCP protocol where it sends a retransmission after 3, 6, 12, 24 and so on (depends on the TCP stack implementation) when it doesn't receive an answer so that's a normal behavior.

  2. The next time the server answers is after ~48 seconds (from the first SYN with no answer). My guess is that the server doesn't close the session and doesn't accept other sessions during that time.

Upvotes: 0

Jay D
Jay D

Reputation: 3297

You need to know two things here : 1. TCP State Machine for the connection close. 2. TCP timers associated with the connection closure.

There are total 7 TCP timers out of which "maximum segment lifetime" and the "retransmission" timers would come into play in context of connection closure.

Now about the TCP states : client can initiate a connection closure or the server can do it as well.

"The server sends the client a packet with a "FIN" bit set. At this point, the server is in FIN_WAIT_1 state. The client gets the FIN packet and goes into CLOSE_WAIT state, and sends an acknowledgment packet back to the server. When the server gets that packet, it goes into FIN_WAIT_2 state. From the server's perspective, the connection is now closed, and the server can't send any more data. However, under the TCP protocol, the client needs to shut down also by sending a FIN packet, which the server TCP implementation should ACK. The server should close after a period of time defined by the Maximum Segment Lifetime (MSL)."

At any time, if the sender doesn't get an ack it would trigger a retransmission.

You should look for in your specific case :

1 is MSL playing the role in the delay you mentioned. 2 are there any retransmissions? Are there any spurious retransmissions?

Upvotes: 0

Related Questions