Ask Your Question

Follow HTTP stream vs Follow TCP stream bug?

asked 2019-12-13 00:31:07 +0000

wbenton gravatar image

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!

edit retag flag offensive close merge delete


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)

SYN-bit gravatar imageSYN-bit ( 2019-12-14 12:37:44 +0000 )edit

The file came from an old 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 [ 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.

wbenton gravatar imagewbenton ( 2019-12-14 12:52:15 +0000 )edit

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!

wbenton gravatar imagewbenton ( 2019-12-14 13:39:23 +0000 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2019-12-14 14:15:26 +0000

SYN-bit gravatar image

TCP stream 47 does not contain a full HTTP response (as the client sends a TCP/RST right after the request). This means the HTTP dissector will not be able to reassemble the HTTP response, as there is data missing. You can see that there is no HTTP response in the packet-list. As follow-http-stream relies on the http dissector to collect full HTTP requests and responses it can't show the snippet of the http response that was sent before the TCP/RST was received by the server.

The reason it does work with reassembly turned off, is that then the http dissector only needs the first part of the response to mark that packet as the http-response.

edit flag offensive delete link more


Makes sense. Thanks for the explanation.

wbenton gravatar imagewbenton ( 2019-12-14 14:40:32 +0000 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2019-12-13 00:31:07 +0000

Seen: 1,986 times

Last updated: Dec 14 '19