I am testing an embedded web server which generally sends the HTTP header in one TCP segment, and the data in subsequent segments. Previous versions of Wireshark through 1.12.10 would reassemble the segments and show "HTTP" in the protocol column for the frame with the last segment along with "N reassembled segments". But Wireshark 2.0.2 shows "HTTP" in the protocol column for the frame with the FIRST data segment - just the header. The other data is there in the later frames. But it is a pain not to filter on "http" and see just the conversation without the TCP overhead. I am using the same "preferences" file on the two versions of Wireshark, and the "Reassemble..." options are all checked. The guy in the cube next to me sees the same behavior. Has anyone else seen this? I have a .pcapng file and screenshots, but I don't see a way to attach them asked 14 Apr '16, 12:06  nomeekgeek |
3 Answers:
Whatever was fixed in 2.0.3 did not include bug 10335. Wireshark still does not correctly identify all HTTP packets. Some HTTP packets are still identified as simply TCP and the contents are not dissected. Bug 10335 affects all versions from 1.12.0, including recently released versions 1.12.11 and 2.0.3. For the original poster, you can accomplish the same goal (seeing the conversation without the TCP overhead) using the display filter "tcp.port==80 and tcp.len > 0". Substitute the correct port, of course, if the HTTP traffic uses an alternate port. If this is something you do a lot, you might want to make this a filter expression button on the display filter toolbar so that this display filter can be quickly applied. answered 25 Apr '16, 10:22  Jim Aragon I do not know whether the problem I saw in 2.0.2 is related to 10335. My experience has been that the HTTP re-assembly:
Jim Aragon's tip about tcp.len>0 is a useful work around if I see the problem again, although it means seeing each chunk-containing frame, rather than the HTTP re-assembly. Better than nothing, though. (25 Apr '16, 10:35) nomeekgeek @nomeekgeek Is there any chance of you making the capture available, it's another point in the possible search for a solution for bug 10335? (25 Apr '16, 10:47) grahamb ♦ @grahamb, I've attached a capture file to bug 10335 that illustrates the problem very dramatically. This is in addition to the one that was previously uploaded when the original bug was filed. (25 Apr '16, 15:09) Jim Aragon |
Fixed by update to 2.0.3 answered 25 Apr '16, 06:35 nomeekgeek |
Upload the capture file somewhere publicly accessible, e.g. Cloudshark, Google Drive, DropBox etc. and then edit your question with a link to the capture file.
I have uploaded a sample capture to https://www.cloudshark.org/captures/9a2309a647ef
There is a GET request in frame 73, with response data in frames 75 (headers) and 76 (body).
When I load the file in Wireshark 2.0.2 and filter on "tcp && http" (http alone also shows SSDP over UDP traffic on our network), it shows "HTTP" for frame 75, with only the header data. Frame 76 isn't shown. If I remove the HTTP filter, I can see the data in TCP frame 76, but lack of a rollup makes it clumsy to interpret the response.
When I load the file in Wireshark 1.12.10 or 2.0.3 and filter on "tcp && http", it shows "HTTP" for frame 76. Details shows “2 reassembled TCP segments #75 and #76” and the data pane shows the entire message for easy reading.
Also shows correctly in CloudShark's view.
I no longer have the 2.0.2 installed, so I can't say whether ALL transactions (such as the GET responses in frames 6 through 12) showed the problem. I believe that it did, but 75/76 is one for which I have got a screen-shot showing the problem (which I now see that CloudShark won't let me upload)