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 :
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 :
---> 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 |
2 Answers:
Disable "Allow subdissector to reassemble TCP streams" and you will see the 200 OK in frame 6. answered 16 May '15, 04:17  Roland 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 |
The server stops sending data in the middle of the HTTP response. See "Follow TCP Stream", at the end: 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 answered 17 May '15, 06:21  Kurt Knochner ♦ 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 |
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 ;-)
Hi Kurt,
Youl'll find the capture here :
https://www.cloudshark.org/captures/514808940107
Thanks in advance for your help.
/Xavier
When you troubleshoot HTTP you have to capture the full packet.
Hi Roland,
You could download the full packet capture here :
http://ovh.to/VxNXj6d
Thanks in advance for your help.
/Xavier