I have noticed that for a specific HTTP Request, Wireshark always displays the Request (frame 63) after the Response (frame 60). However, it turns out the request is actually frame 58, which Wireshark has just labelled as a "TCP segment of a reassembled PDU". On frame 63 you can see that it has included frame 58, it also turns out that frame 63 is a FIN/ACK frame with 0 bytes payload. I should note that the request has a very large HTTP header in it, a https certificate, which is 1738 bytes long, maybe that is what is confusing Wireshark. As a side note, Nginx didn't know what to do the large header either. Why is Wireshark choosing frame 63 for the Request, when it could have used 58? This looks like a bug in Wireshark to me. EDIT: I have attached the packet capture on cloudshark
asked 06 Jul '16, 18:09  Joel Pearson edited 07 Jul '16, 15:57 |
One Answer:
Can you check if turning off the TCP protocol setting "Allow Subdissectors to reassemble TCP streams" makes a difference? My guess is that this is just caused by Wireshark doing reassembly, meaning it's waiting until it has all packets belonging to the request before displaying the info line. This would then not a bug but one of two ways how to display packet content in the info column. answered 07 Jul '16, 01:52  Jasper ♦♦ The explanation suggested by @Jasper is valid if the server has really responded to the request before receiving it completely. This looks like an odd enough behaviour to me, but it seems to be true as the capture seems to be taken on a single machine where both client and server are running, so eventual time shifts in merged files are probably not the explanation. So if I were you, I would be most interested in this odd behaviour of the server, and I'd try to find out which part of the request PDU is so useless that the server doesn't wait for it to arrive before responding. I could maybe understand this if the response was a negative one, but since it is a 200, it is really weird. (07 Jul '16, 03:54) sindy I have attached the capture now on CloudShark. Turning off "Allow Subdissectors to reassemble TCP streams" does fix the problem, but I'm hesitant to not call it a bug. Because it definitely isn't waiting for more data. If you follow the TCP stream it's pretty clear cut, there is nothing after the response. And the 2nd segment in PDU is a TCP FIN/ACK segment with no data. So maybe that means there is a bug in the http subdissector? (07 Jul '16, 16:06) Joel Pearson I justed checked - this problem didn't show up in my Wireshark version, but I am on the latest developer build. So I guess this behavior has already been fixed, but not made it's way into the current stable version yet. (08 Jul '16, 04:15) Jasper ♦♦ 1 Nightly builds of the development version are available at the automated downloads section of the website. (08 Jul '16, 04:26) grahamb ♦ Ahh thanks, I'll check it out (08 Jul '16, 06:33) Joel Pearson @Jasper sorry, I finally got around to trying this out. I downloaded the latest nightly build, and the problem is not fixed. I am using Version 2.1.2-70-g83174a2 (v2.1.2rc0-70-g83174a2 from master) Maybe you already have "Allow Subdissectors to reassemble TCP streams" off? (19 Jul '16, 19:21) Joel Pearson I just re-checked, I had Version 2.1.1-5-g508e0f4, and it works with both reassembly on and off. So I installed the version you mentioned and it still works. Not sure why we have different results... (20 Jul '16, 01:10) Jasper ♦♦ showing 5 of 7 show 2 more comments |
Can you share a capture in a publicly accessible spot, e.g. CloudShark?
@Jaap, done now