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

Browser send FIN + ACK packet before getting 200 HTTP/OK answer (partial transfer)

0

Hi,

We are currently experiencing a strange behavior : when we try to access an embedded web server (running on an ARM box / 10.73.109.155) from a Google Chrome Browser (192.168.154.44) we get a partial transfert.

When we analyze the wireshark traces we get :

alt text

It's seem that the browser send an FIN + ACK packet before receiving an "200 HTTP/OK answer" from the server. We only get a piece of the webpage.

The browser send the FIN + ACK packet after 3.68s of inactivity (the server seem to stop transmitting data). I think it was a kind of timeout but i don't find any literature about that.

My analysis is as follows :

  • server stop transmitting (for any reason) after packet #10
  • client acknowledge the last packet in #11
  • client don't see any new packet for 3,68s and decide to send an FIN + ACK (#12)
  • client don't see any ACK for packet #12 so it retransmits FIN + ACK five times (#13,14,15,16,17)
  • client still got no answer afer 5 retry (and 22 seconds) and send a final RST + ACK packet (#18)

---> It's a server-side problem

Does anyone help me by confirming this analysis ?

I know it is not a subject directly related to wireshark but if anyone has an idea ;-)

/Xavier

asked 15 May '15, 08:04

xaviercm's gravatar image

xaviercm
6113
accept rate: 0%

Can you please upload the capture file somewhere (google drive, dropbox, cloudshark.org) and post the link here?

It's next to impossible to do any meaningful troubleshooting based on screenshots ;-)

(15 May '15, 09:59) Kurt Knochner ♦

Hi Kurt,

Youl'll find the capture here :

https://www.cloudshark.org/captures/514808940107

Thanks in advance for your help.

/Xavier

(15 May '15, 10:14) xaviercm

When you troubleshoot HTTP you have to capture the full packet.

(15 May '15, 10:45) Roland

Hi Roland,

You could download the full packet capture here :

http://ovh.to/VxNXj6d

Thanks in advance for your help.

/Xavier

(16 May '15, 00:59) xaviercm

2 Answers:

1

Disable "Allow subdissector to reassemble TCP streams" and you will see the 200 OK in frame 6.

answered 16 May '15, 04:17

Roland's gravatar image

Roland
7642415
accept rate: 13%

Hi Roland,

A really big thanks for your answer.

Effectively, now, with your advice i could see the 200 OK.

Do you have any idea why the client/browser send a FIN + ACK after about 4 seconds without receiving any data from the server (the web page is not completed as you could see in the capture). Do you think is a timeout build into Chrome ? it seems to me very short.

Thanks again for your help :-)

/Xavier

(16 May '15, 08:53) xaviercm

Does it work with other browsers? The server (not sure about this device) can still transmit after the client sent the FIN, but it doesn't. If there is nothing between the client-server that can block/drop packets, then I would blame the server.

(16 May '15, 10:46) Roland

0

The server stops sending data in the middle of the HTTP response.

See "Follow TCP Stream", at the end:

src="batterie.png" style="vertical-align:middle;" title=" Batterie

In Frame #10 you see the erie of Batterie and that's it from the server. The client closes the connection after 3.5 seconds, because it does not get any response from the server.

Looks clearly like a problem on the server, either within the TCP stack or within the HTTP server code. You won't find the reason for that with Wireshark. What could help is debugging on the embedded device.

Regards
Kurt

answered 17 May '15, 06:21

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

Hi Kurt,

A very big thanks for your answer and your help.

You confirm exactly what I thought initially.

We'll look at the server side more closely (not so simple because of the real-time OS used on this box ...).

Thanks again !

/Xavier

(17 May '15, 07:24) xaviercm