Client closing the connection by sending FIN, ACK before server sends HTTP OK response

This question isn't really Wireshark related so it's probably better asked elsewhere: stackexchange ?

That being said:

"From the wireshark traces we can observe 3 way TCP handshake is happening. After that client is sending GET HTTP request & HTTP ACK is sent by web server. Now client is sending FIN, ACK to web server without waiting for HTTP OK response."

Looking quickly at the capture and at each of the 3 TCP "conversations", the above is somewhat incorrect:

1. In each case, the client does wait some amount of time after sending the GET before timing out and sending the FIN.

======

So: to me the real question: Is the server replying and the reply is being lost or is the server not replying.

I'm not familiar with troubleshooting GPRS connections so I can't provide any further info.

There are 3 TCP streams in your tracefile, each with a different pattern:

1. In the first stream (tcp.stream eq 0), the client sends it's request, the server ACKs the request, but an answer never comes. Then after 60 seconds the client sends a FIN. If the server did send a response which got lost, it would have sent retransmissions in this interval. So either:
   • the server never responded
   • all transmissions of the response are "blocked"
   • or all communication from the server to the client was lost by then.

2. In the second stream (tcp.stream eq 1), the client sends the request. SInce it does not get an ACK, it retransmits the request until it finally gives up and sends a FIN. In this case it seems that all communication from the server to the client is lost.

3. In the third stream (tcp.stream eq 2), The client sends it's request, the server ACKs, but a response does not come. The client times out after 10 seconds and sends a FIN. Then the server sends a FIN back, but with a sequence number that tells us that it has been sending data before. So there is still communication, but the response from the server somehow got lost.

When looking at the MSS values in the TCP SYN packets, the client advertises a MSS of 1420, which may or may not be lowered by intermediate devices on the way to the server. Then the server advertises a MSS of 1400 which might already have been lowered by devices in between the server and the capture point.

Combining that with the FIN/ACK in frame 26, there might be an issue in adjusting the MSS value on intermediate devices because the server seems to have sent a TCP segment of length 1401. The only way to verify this hypothesis is to make traces at multiple points in the network including one as close to the server as you can get (even if it is just the INternet exit point from the mobile network).

(In this analysis I just focussed on the TCP part of the tracefiles as I do not have any experience with mobile protocols)