Follow HTTP stream vs Follow TCP stream bug?
When I view HTTP streams vs TCP streams, the displayed content varies depending on whether I have [Allow TCP subdissector reassembly] turned on or off.
If Reassembly is allowed, follow TCP stream shows correct display but follow HTTP stream doesn't show proper context. It only shows the initial client request with no server reply.
But if reassembly is not allowed, follow TCP stream and follow HTTP stream does show the exact same context with both initial client request and server reply.
My question then is... is this a bug or what? I hate to have to toggle between allow and disallow reassembly just to see the proper follow HTTP display!
Do you see this behavior with every HTTP capture or with a specific capture file? Are you able to share the pcap file on a public file sharing service to have a look at?
(please make sure there is no sensitive data in the capture file if you do share the file)
The file came from an old Malware-Traffic-Analysis.net file. Zipped Sniffer File The zipped file is encrypted. The password is [infected]. I've not tried it with anything more recent and thus don't know for sure whether the problem is only with this file or others as well. Filter on [tcp.stream eq 47] to get a quick view. Perhaps it's just this stream as it works for some other strings, but this string is the one I first noticed it occuring.
Further analysis of that file I previously mentioned, the problem ONLY seems to occur in streams 40, 41, 43, 45, 46 and 47. Streams 38 & 39 are from the same destination IP but the HTTP displays properly. So perhaps a malformed HTTP packet in this trace or perhaps a bug from an older version of Wireshark from 2015!