This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

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

0

Hi,

We are facing a peculiar issue in our network. When trying to access mail.indiatimes.com (223.165.24.14) website 80% of time it doesn't open. We have to keep disconnect and try again to open the web page. 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.

In what scenarios this will happen?

Uploaded the wireshark -> http://www.4shared.com/file/hgI1MERD/ITC-Fail.html

With Regards, Balaguru S

asked 28 Sep '11, 09:44

sbalagru6's gravatar image

sbalagru6
1111
accept rate: 0%

closed 28 Sep '11, 23:57

helloworld's gravatar image

helloworld
3.1k42041

I reopened the question as I think it is ON-topic. We have been helping people with analyzing their protocols in the past. And I don't see why we should not continue to do so in the future.

(29 Sep '11, 00:54) SYN-bit ♦♦

2 Answers:

0

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.

answered 28 Sep '11, 10:31

Bill%20Meier's gravatar image

Bill Meier ♦♦
3.2k1850
accept rate: 17%

edited 28 Sep '11, 11:19

0

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)

answered 29 Sep '11, 00:30

SYN-bit's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

Hi SYNbit,

Thanks for your valuable input. We have started troubleshooting by bypassing one by one the network elements. Finally when we bypassed the traffic from Juniper SRX3400 firewall we were able to access the website without any issues. Then we put the traffic back on SRX and tried setting different tcp-mss values (1200,1300,1400,1402 & 1420). But still problem is not solved.

We have raised a case with JTAC, they were also not able to find anything. JTAC has escalated the case to ATAC and they have collected some logs & will come back with findings.

Now we are sure that problem with SRX firewall only (Done multiple testings bypassing firewall). Will keep you guys posted on Juniper's findings.

Really appreciate your inputs.

With Regards, Balaguru S

(29 Sep '11, 08:50) sbalagru6

(I converted your "answer" to a "comment", please see the FAQ for details)

Does your SRX do any application level filtering or IDS? There might be something in the responses from the server that triggers these filters?

(29 Sep '11, 09:50) SYN-bit ♦♦