Wireshark-bugs: [Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data
Comment # 31
on bug 12855
from Erik Hjelmvik
(In reply to Michael Mann from comment #30)
> (In reply to Erik Hjelmvik from comment #27)
> > I'd like to open this bug up again. I tried Wireshark 2.2.2 but it did
> > unfortunately not always fix the issue of showing overlapping/duplicate
> > packets.
>
> There was no attempt to fix the overlapping/duplicate packets (which is a
> borderline enhancement more than bug), this was just to restore the
> functionality of 2.0 that was broken on 2.2 release (and master). I think
> it should be tracked as a separate bug. I think bug 13061 is much more
> related to the issue than this one.
Actually bug 13061 is about getting the "tcp.segment.overlap.conflict" display
filter to work as expected. That issue is not related to the Follow TCP Stream
functionality.
Wireshark 2.0.2 was handling Follow TCP Stream for
"hao123-com_packet-injection-filtered.pcap" properly, but the latest build
isn't. My understanding is that this bug (#12855) is that Follow TCP stream is
duplicating data because it isn't honouring the TCP sequence numbers properly
in the TCP reassembly.
This is the (correct) result from Follow TCP Stream in Wireshark 2.0.2 for the
"hao123" PCAP file
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=15078
-------------------
GET / HTTP/1.1
Host: www.02995.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:41.0) Gecko/20100101
Firefox/41.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
HTTP/1.1 302 Found
Location: hxxp://www.hao123[.]com/?tn=93803173_s_hao_pg
0:28 GMT
Content-Type: text/html
Last-Modified: Tue, 01 Mar 2016 07:50:28 GMT
Cache-Control: max-age=1800
Location: hxxp://hao.360[.]cn/?src=""
Age: 857
X-Cache: HIT from ctzjhzs1
Via: 1.0 ctzjhzs1 (squid)
Connection: close
[...]
-------------------
Notice how the first 72 bytes have been removed from the second HTTP response?
This is correct behaviour since those bytes have already been received in the
first HTTP response. I.e. Wireshark 2.0.2 does the TCP reassembly the same way
as the client's TCP stack. Unfortunately this hasn't been fixed as can be seen
in the screenshot in attachment 15079 [details]
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=15079
You are receiving this mail because:
- You are watching all bug changes.
