Why are 0 length TCP packets returned on some HTTP / TCP sessions? We have a mini-httpd server embedded in an application. Sometimes after a HTTP request for a resource the underlying TCP connection doesn't work. It only returns TCP packets of message length 0. It's on localhost. The only thing that gets it working again (most times) is to stop & start the http client. link textWhy? asked 17 May '16, 18:54  WireBananaSlug edited 17 May '16, 19:36 |
One Answer:
Wireshark can help you answer the question "why" only in terms that it shows you which party in communication has stopped responding at a given layer. But the question "why has it stopped responding" may have two answers:
A "zero-length" TCP packet merely means that the party sending it had no payload to send but needed to inform the other one about something, e.g. about successful reception of data or, vice versa, about missing data which need to be retransmitted. In your case, it is hard to say whether the receiving side (the http server) acknowledges the whole http GET packet or only a part of it, because we cannot click to another packet and see what is inside on a screenshot. While "zero-length" TCP packets have 94 bytes of eth + ip + tcp overhead, the GET has total length of 456 bytes and the ACK to it says 181 bytes of payload have been received in it. 94 + 181 = 275; that means there are another 181 bytes in that packet which may be TCP options but these are normally limited to 40 bytes. So it seems that the server asks the client to retransmit some data but that is really odd given that the "received" and "still missing" data came in a single packet. Or the 181 unknown bytes in the GET packet are not payload but some extra TCP options, and in that case the server application would have some problem preventing it from sending a (positive or negative) response. But both the above are just guesses. We cannot move further in analysis until you back it properly, by posting the capture from which you've taken your screenshot (you can use answered 17 May '16, 21:56  sindy |
OK, I've uploaded the captured packets filtered for the port 7888 and it includes 2 sessions. The 1st one that failed and the 2nd one the worked.
In this case the Unity 3D client requests initially the file that the mini-httpd server that is started by the Unity editor and when it fails that same file gets requested over and over and when it works the Unity 3D client continues to ask for the rest of the files based on the contents of the original file it requested from the Unity 3D mini-httpd server.
Here is a link to the filtered packets: link text
Thanks very much.
Hm, that's really weird. WinPcap, like libpcap, stores two frame sizes: the real one as it was "on the wire", and the second is how many bytes of the frame it has stored to the capture file. Different applications (tcpdump and Wireshark) use different default settings: unless you say otherwise manually, Wireshark wants WinPcap to store everything that was on the wire, and tcpdump wants libpcap to store only first 60 bytes.
In your case, the "stored" length matches the tcp paload size plus headers, while the "on the wire" size is bigger, which doesn't seem reasonable. Therefore, I really would like to know whether you've captured that using npcap (i.e. directly from Wireshark) on the loopback virtual interface or using rawcap.
If the frame really has 456 bytes on the "wire", it might confuse the receiving chain of the stack and application; otherwise it is most likely a bug of the capturing driver. You should be able to find out by comparing this GET packet with the one in the "good" capture; if for the "good" capture, the first line of the packet dissection pane also says "bytes on wire: N, bytes captured: M" and N>M, then this is most likely just an additional issue but not the root cause of the mini-server's silence in response.
I have been working with WireBananaSlug on this too and have pretty much identical results from another (Win7) machine with the same WireShark NpCap combo installation. For me the GET on both the failed test and the successful is 452 bytes on wire and 233 bytes captured...
So have you got any ideas what sort of thing I should look for that might be causing these extra bytes on the wire, that you say might be 'confusing the receiving chain of the stack and application' - I appreciate you cannot say exactly, but any generic ideas about the sort of things that cause this would be really helpful :)
None at all, but I suspect that discrepancy between "on the wire" and "captured" packets to be an issue of npcap or the loopback virtual interface, which implies that there is no way you could affect it directly.
But as there are two of you dealing with the issue, may I suppose that as you have got two computers, you could run the server on one of them and the client on the other one, capture on their physical network interfaces, and see whether the discrepancy exists in that case too?
(and yes, I've missed that the capture published already contained both the bad and the good case and that in both of them the difference in frame sizes exists, which most likely means it is a red herring and the actual issue lays somewhere else).
@sindy - thanks. I guess I will look at some lower level debug error return codes in the OS system, particularly for the file the httpd server is requesting.