[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

Alexis La Goutte  changed:

   What|Removed |Added

 CC||john.r.fall...@gmail.com

--- Comment #33 from Alexis La Goutte  ---
*** Bug 13458 has been marked as a duplicate of this bug. ***

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #32 from Erik Hjelmvik  ---
Okay, looks like this bug is tracked in Bug 9882. Any progress on this issue?

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #31 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=lm=n4a2f6f3a91
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
https://bugs.wireshark.org/bugzilla/attachment.cgi?id=15079

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

Michael Mann  changed:

   What|Removed |Added

 Status|CONFIRMED   |RESOLVED
 Resolution|--- |FIXED

--- Comment #30 from Michael Mann  ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #29 from Erik Hjelmvik  ---
Created attachment 15079
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=15079=edit
Screenshot from Wireshark 2.2.2 for hao123-com_packet-injection-filtered.pcap

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #28 from Erik Hjelmvik  ---
Created attachment 15078
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=15078=edit
TCP Packet Injection attack with overlapping TCP segments

>From my SharkFest EU presentation
https://sharkfesteurope.wireshark.org/assets/presentations16eu/10.pdf

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

Erik Hjelmvik  changed:

   What|Removed |Added

 Status|RESOLVED|CONFIRMED
 Resolution|FIXED   |---

--- Comment #27 from Erik Hjelmvik  ---
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.

Attached files:

hao123-com_packet-injection-filtered.pcap
TCP packet injection attack from my SharkFest Europe talk
https://sharkfesteurope.wireshark.org/assets/presentations16eu/10.pdf

hao123-com_packet-injection-filtered.png
Screenshot of Wireshark 2.2.2's Follow TCP Stream showing both the injected
packet and the real packet even though they have the same TCP sequence number.
Correct behaviour would be to skip the first 74 bytes of the second overlap,
since we have already read 74 bytes from the first overlapping segment.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #26 from Peter Wu  ---
This is fixed with the next 2.2.2 release (scheduled for 16 November 2016). If
there are any issues, please report them. Thanks!

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #25 from Gerrit Code Review  ---
Change 18736 merged by Peter Wu:
tcp: Fix Follow TCP tap data and when its tapped.

https://code.wireshark.org/review/18736

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #24 from Gerrit Code Review  ---
Change 18736 had a related patch set uploaded by Michael Mann:
tcp: Fix Follow TCP tap data and when its tapped.

https://code.wireshark.org/review/18736

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #23 from Gerrit Code Review  ---
Change 18368 merged by Pascal Quantin:
tcp: Fix Follow TCP tap data and when its tapped.

https://code.wireshark.org/review/18368

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

Gerrit Code Review  changed:

   What|Removed |Added

 Status|IN_PROGRESS |RESOLVED
 Resolution|--- |FIXED

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #22 from Erik Hjelmvik  ---
(In reply to Michael Mann from comment #21)
> (In reply to Erik Hjelmvik from comment #20)
> > The wanted behaviour in the follow TCP stream would be to see only one HTTP
> > response, not two or three. The response shown in the follow TCP stream
> > should contain a 1633 byte valid HTML file.
> 
> Current state of the patch duplicates 2.0 behavior which still has the
> response as 1712 bytes (but the response is only shown once)

If WS now behaves like 2.0, then that's great!
The desired behaviour would be for the follow TCP to interpret the stream data
the same way as the TCP stack at the receiving end, which was working in
version 2.0.x and earlier.

Here's how tshark 2.0.2 nicely performs a follow TCP stream of
145-reordered-filtered3.pcap:

tshark -r 145-reordered-filtered3.pcap -z follow,tcp,ascii,0
  1   0.00  0.0.0.0 -> 113.6.227.240 HTTP 982 GET
/js/6v/biz/common/store-proxy/store-proxy2.html?iframe_delete=true HTTP/1.1 
  2   0.551363 113.6.227.240 -> 0.0.0.0  HTTP 1440 HTTP/1.1 200 OK 
  3   0.547699 113.6.227.240 -> 0.0.0.0  TCP 596 [TCP Retransmission] 80 →
64867 [PSH, ACK] Seq=1 Ack=943 Win=38 Len=556
  4   0.551379 113.6.227.240 -> 0.0.0.0  TCP 358 [TCP segment of a
reassembled PDU]
  5   0.697782 113.6.227.240 -> 0.0.0.0  TCP 46 [TCP Retransmission] 80 →
64867 [PSH, ACK] Seq=555 Ack=943 Win=38 Len=1

===
Follow: tcp,ascii
Filter: tcp.stream eq 0
Node 0: 0.0.0.0:64867
Node 1: 113.6.227.240:80
942
GET /js/6v/biz/common/store-proxy/store-proxy2.html?iframe_delete=true HTTP/1.1
[...HTTP_HEADERS---]
1400
HTTP/1.1 200 OK
Content-Length: 1633
Cache-Control: no-cache
Connection: close

[...HTML...]
318
[...HTML...]
===

Any reassembly different than this should be considered a bug. I.e. Frames 3
and 5 should not be part of the reassembled data.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #21 from Michael Mann  ---
(In reply to Erik Hjelmvik from comment #20)
> The wanted behaviour in the follow TCP stream would be to see only one HTTP
> response, not two or three. The response shown in the follow TCP stream
> should contain a 1633 byte valid HTML file.

Current state of the patch duplicates 2.0 behavior which still has the response
as 1712 bytes (but the response is only shown once)

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

Erik Hjelmvik  changed:

   What|Removed |Added

   Priority|Low |Medium
   Severity|Normal  |Minor

--- Comment #20 from Erik Hjelmvik  ---
You can also test this bug by using the PCAP file
"145-reordered-filtered3.pcap" that I uploaded for Bug 13061
(tcp.segment.overlap.conflict) here:

https://bugs.wireshark.org/bugzilla/attachment.cgi?id=15018

The wanted behaviour in the follow TCP stream would be to see only one HTTP
response, not two or three. The response shown in the follow TCP stream should
contain a 1633 byte valid HTML file.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #19 from Gerrit Code Review  ---
Change 18368 had a related patch set uploaded by Michael Mann:
[WIP] Fix Follow TCP tap data and when its tapped.

https://code.wireshark.org/review/18368

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

Michael Mann  changed:

   What|Removed |Added

 Status|CONFIRMED   |IN_PROGRESS

--- Comment #18 from Michael Mann  ---
(In reply to Michael Mann from comment #17)
> (In reply to Pascal Quantin from comment #16)
> > My patch being far from complete, so my vote is for a revert of the code to
> > previous implementation (for now).
> 
> I just haven't had the time to get to it, but my idea was to turn the
> (original) reassemble_tcp logic into a tap (with tap handling at the UI
> layer).  I have not found a way to handle out of order packets (i.e. Peter's
> samples) with the current tap setup.
> If we're going to revert, I'd like to try to limit it to just TCP, but one
> issue is that the refactoring simplified the code so that TCP/UDP/SCTP are
> all one code path.  I also think the new functionality took at least 2
> commits.

Having some success "refactoring" reassemble_tcp and limiting changes to just
TCP dissector (with maybe some small growth in follow structures).  GUI doesn't
appear to need changing.  I'll post a patch when I have something more concrete
(it's getting a bit late here).

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #17 from Michael Mann  ---
(In reply to Pascal Quantin from comment #16)
> My patch being far from complete, so my vote is for a revert of the code to
> previous implementation (for now).

I just haven't had the time to get to it, but my idea was to turn the
(original) reassemble_tcp logic into a tap (with tap handling at the UI layer).
 I have not found a way to handle out of order packets (i.e. Peter's samples)
with the current tap setup.
If we're going to revert, I'd like to try to limit it to just TCP, but one
issue is that the refactoring simplified the code so that TCP/UDP/SCTP are all
one code path.  I also think the new functionality took at least 2 commits.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #16 from Pascal Quantin  ---
My patch being far from complete, so my vote is for a revert of the code to
previous implementation (for now).

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #15 from Peter Wu  ---
So Erik also reported this problem on SF and there is another post on Ask
wondering about this issue. Would it be possible to revert to the previous
behavior while a long-term fix is being developed?

Or at least take Pascal's patch and hope for the best?

As for your suggestions, tieing seq numbers with the data is effectively what
the reassembly API is doing right?

If you then want to allow for gaps while following the TCP stream, maybe the
TCP window size can be used as a hint on whether data is still expected or not
before attempting partial reassembly.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #14 from Michael Mann  ---
(In reply to Pascal Quantin from comment #13)
> (In reply to Michael Mann from comment #10)
> > With this, I have a harder time determining which is "better". master skips
> > "Third", but includes "Last".  2.0.5 skips/misses "Last".
> 
> Given that there is a definitely lost segment between the fifth and the last
> one, 2.0.x output is the valid one IMHO.

I can understand that.  Another problem that I noticed was that the Follow TCP
stream behavior of "skipping" the "Third" is also exhibited by Export PDU
(layer 4).  So the current implementation of just tapping tvbs (for Follow TCP
and Export PDU) isn't complete enough for the desired behavior.  However, I
would like to have such a solution in the TCP dissector so that it's all in one
place.

Some potential ideas (just thinking out loud)

1. Maybe some combination of the seq/ack analysis tied to the tvbs (ie
appending the existing seq/ack structures to somehow include tvb data)?  Don't
necessarily want all of that data in memory.
2. Have a "putting TCP stream together" "shim" that does the reassembly to pass
the results to Follow TCP stream and Export PDU.  Really trying to avoid
"reverting" to using a file.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #13 from Pascal Quantin  ---
(In reply to Michael Mann from comment #10)
> With this, I have a harder time determining which is "better". master skips
> "Third", but includes "Last".  2.0.5 skips/misses "Last".

Given that there is a definitely lost segment between the fifth and the last
one, 2.0.x output is the valid one IMHO.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #12 from Michael Mann  ---
(In reply to Peter Wu from comment #5)
> tshark
> master:
> ===
> Follow: tcp,hex
> Filter: tcp.stream eq 0
> Node 0: 10.0.0.1:32323
> Node 1:
> 10.0.0.2:80
> 0010  50 55 54 20 2f 20 48 54  54 50 2f 31 2e 31 0d 0a  PUT
> / HT TP/1.1..
> 0020  50 55 54 20 2f 20 48 54  54 50 2f 31 2e 31 0d 0a 
> PUT / HT TP/1.1..
> 0030  50 55 54 20 2f 20 48 54  54 50 2f 31 2e 31 0d 0a
> PUT / HT TP/1.1..
> 0040  43 6f 6e 74 65 6e 74 2d  4c 65 6e 67 74 68 3a 20
> Content- Length:
> 0050  36 0d 0a 
> 6..
> 0053  43 6f 6e 74 65 6e 74 2d  4c 65 6e 67 74 68 3a 20  Content-
> Length:
> 0063  36 0d 0a  6..
> 0066  50 55 54 20 2f 20 48 54  54 50 2f 31 2e 31 0d 0a  PUT / HT
> TP/1.1..
> 0076  43 6f 6e 74 65 6e 74 2d  4c 65 6e 67 74 68 3a 20 
> Content- Length:
> 0086  36 0d 0a 0d 0a   
> 6
> 008B  0d 0a ..
> 008D  32 0a 2.
> 008F  33
> 0a 3.
> ===

The "old" Follow TCP stream (2.0 and older) would write the TCP stream to a
file and then reread it, effectively giving it a "second pass" (regardless of
*shark).  The "current" Follow TCP stream (2.2 and master) uses just the tap
interface, so if you don't specify -2 on the TShark command line, you can get
drastically different results.

Here's what I got with
tshark.exe -2r "c:\Wireshark Test Files\follow_tcp\tcp80.pcap" -z
follow,tcp,hex,0

===
Follow: tcp,hex
Filter: tcp.stream eq 0
Node 0: 10.0.0.1:32323
Node 1: 10.0.0.2:80
  50 55 54 20 2f 20 48 54  54 50 2f 31 2e 31 0d 0a  PUT / HT TP/1.1..
0010  50 55 54 20 2f 20 48 54  54 50 2f 31 2e 31 0d 0a  PUT / HT TP/1.1..
0020  43 6f 6e 74 65 6e 74 2d  4c 65 6e 67 74 68 3a 20  Content- Length:
0030  36 0d 0a  6..
0033  0d 0a ..
0035  32 0a 2.
0037  33 0a 3.
===

Still not correct, but closer to original issue showed by submitter's capture
file.
Pascal's patch (https://code.wireshark.org/review/17749) does correctly affect
the orginal capture file, but doesn't alter the behavior of tcp80.pcap.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #11 from Gerrit Code Review  ---
Change 18035 had a related patch set uploaded by Michael Mann:
tshark: follow streams should start with chunk 1.

https://code.wireshark.org/review/18035

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #10 from Michael Mann  ---
(In reply to Gerrit Code Review from comment #9)
> Change 18034 had a related patch set uploaded by Michael Mann:
tshark:
> follow streams should start with chunk 1.
> https://code.wireshark.org/review/18034

I took Peter's captures and looked at them in Wireshark and got different
output than TShark.  So with the above fix the TShark output for tcp9.pcap on
master (now matching Wireshark) is
===
Follow: tcp,hex
Filter: tcp.stream eq 0
Node 0: 10.0.0.1:32323
Node 1: 10.0.0.2:9
  46 69 72 73 74 0a First.
0006  53 65 63 6f 6e 64 0a  Second.
000D  46 6f 75 72 74 68 0a  Fourth.
0014  46 69 66 74 68 0a Fifth.
001A  4c 61 73 74 0aLast.
===

compared to 2.0.5 (recopied for convenience)

tshark 2.0.5:
===
Follow: tcp,hex
Filter: tcp.stream eq 0
Node 0: 10.0.0.1:32323
Node 1: 10.0.0.2:9
  46 69 72 73 74 0a First.
0006  53 65 63 6f 6e 64 0a  Second.
000D  54 68 69 72 64 0a Third.
0013  46 6f 75 72 74 68 0a  Fourth.
001A  46 69 66 74 68 0a Fifth.
===


With this, I have a harder time determining which is "better". master skips
"Third", but includes "Last".  2.0.5 skips/misses "Last".

tcp80.pcap still doesn't look wrong in master (not sure if its same issue as
OB's trace), but I'll probably start with Pascal's first attempt
(https://code.wireshark.org/review/17749).  I wasn't sure if the buggy TShark
unintentionally discouraged what could be at least a start at the proper fix.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #9 from Gerrit Code Review  ---
Change 18034 had a related patch set uploaded by Michael Mann:
tshark: follow streams should start with chunk 1.

https://code.wireshark.org/review/18034

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

Pascal Quantin  changed:

   What|Removed |Added

Version|2.3.x (Experimental)|2.2.0

--- Comment #8 from Pascal Quantin  ---
So how is the new code supposed to handle reassembly independently of the upper
level protocol (if it exists), and whether the TCP desegmentation option is
activated or not?

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #7 from Michael Mann  ---
(In reply to Pascal Quantin from comment #6)
> For both cases, 2.0.5 behavior seems better (as discussed in Gerrit I'm not
> a fan of the reassembly happening despite missing packets).
> Maybe that's why previous code was not simple ;)
> IMHO the Follow TCP stream feature should not rely on the upper dissector
> having TCP reassembly activated / supported or not.
> Not sure how to move forward. Obviously the current handling needs more
> work, and the previous code was working fine for those use cases. Should we
> revert the change until a more solid version is available? Michael, what's
> your opinion?

I'd really not like to revert if we can avoid it.  My two big issues with the
previous implementation are:
1. Duplicate logic of TCP behavior/dissector.
2. Use of temporary file to collect streams (which doesn't perform as well as
the tap interface)

While the TCP dissector isn't my favorite to modify, I really didn't like
having TCP logic in 2 places.  It sounds like both have their bugs, but I'd
like to continue trying to fix the bugs of the new implementation.
There are certainly some good "test cases" here, but should we start with
trying to compile as many "test cases" as possible (and maybe add them to the
test suite)?  From there we could compare the output and fix the differences in
the new implementation.

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #6 from Pascal Quantin  ---
For both cases, 2.0.5 behavior seems better (as discussed in Gerrit I'm not a
fan of the reassembly happening despite missing packets).
Maybe that's why previous code was not simple ;)
IMHO the Follow TCP stream feature should not rely on the upper dissector
having TCP reassembly activated / supported or not.
Not sure how to move forward. Obviously the current handling needs more work,
and the previous code was working fine for those use cases. Should we revert
the change until a more solid version is available? Michael, what's your
opinion?

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

Peter Wu  changed:

   What|Removed |Added

 CC||mman...@netscape.net,
   ||pascal.quan...@gmail.com

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #5 from Peter Wu  ---
Created attachment 14928
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=14928=edit
crafted packet with retransmitted and out-of-order packets (http)

Another minimal case with HTTP (because that one sets the expected reassembled
size). Created using a modified version of the previous script:
https://git.lekensteyn.nl/peter/wireshark-notes/tree/crafted-pkt/make-tcp.py?id=5a17d2a0a3aa6d7a672bd7cb4bf1362f2ede81e9

tshark 2.0.5:
===
Follow: tcp,hex
Filter: tcp.stream eq 0
Node 0: 10.0.0.1:32323
Node 1: 10.0.0.2:80
  50 55 54 20 2f 20 48 54  54 50 2f 31 2e 31 0d 0a  PUT / HT TP/1.1..
0010  43 6f 6e 74 65 6e 74 2d  4c 65 6e 67 74 68 3a 20  Content- Length:
0020  36 0d 0a  6..
0023  0d 0a ..
0025  31 0a 1.
0027  32 0a 2.
0029  33 0a 3.
===

tshark master:
===
Follow: tcp,hex
Filter: tcp.stream eq 0
Node 0: 10.0.0.1:32323
Node 1: 10.0.0.2:80
0010  50 55 54 20 2f 20 48 54  54 50 2f 31 2e 31 0d 0a  PUT / HT TP/1.1..
0020  50 55 54 20 2f 20 48 54  54 50 2f 31 2e 31 0d 0a  PUT / HT TP/1.1..
0030  50 55 54 20 2f 20 48 54  54 50 2f 31 2e 31 0d 0a  PUT / HT TP/1.1..
0040  43 6f 6e 74 65 6e 74 2d  4c 65 6e 67 74 68 3a 20  Content- Length:
0050  36 0d 0a  6..
0053  43 6f 6e 74 65 6e 74 2d  4c 65 6e 67 74 68 3a 20  Content- Length:
0063  36 0d 0a  6..
0066  50 55 54 20 2f 20 48 54  54 50 2f 31 2e 31 0d 0a  PUT / HT TP/1.1..
0076  43 6f 6e 74 65 6e 74 2d  4c 65 6e 67 74 68 3a 20  Content- Length:
0086  36 0d 0a 0d 0a6
008B  0d 0a ..
008D  32 0a 2.
008F  33 0a 3.
===

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

Peter Wu  changed:

   What|Removed |Added

 CC||pe...@lekensteyn.nl

--- Comment #4 from Peter Wu  ---
Created attachment 14927
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=14927=edit
crafted packet with retransmitted, out-of-order and missing packets

Another example where the new Follow TCP method produces strange
results. This capture was created using Scapy, source is at
https://git.lekensteyn.nl/peter/wireshark-notes/tree/crafted-pkt/make-tcp.py?id=c77414b056e7c9bcc91c9256b463c75e4992e076

tshark -r tcp9.pcap -z follow,tcp,hex,0

tshark 2.0.5:
===
Follow: tcp,hex
Filter: tcp.stream eq 0
Node 0: 10.0.0.1:32323
Node 1: 10.0.0.2:9
  46 69 72 73 74 0a First.
0006  53 65 63 6f 6e 64 0a  Second.
000D  54 68 69 72 64 0a Third.
0013  46 6f 75 72 74 68 0a  Fourth.
001A  46 69 66 74 68 0a Fifth.
===

tshark master:
===
Follow: tcp,hex
Filter: tcp.stream eq 0
Node 0: 10.0.0.1:32323
Node 1: 10.0.0.2:9
0006  53 65 63 6f 6e 64 0a  Second.
000D  46 6f 75 72 74 68 0a  Fourth.
0014  46 69 66 74 68 0a Fifth.
001A  4c 61 73 74 0aLast.
===

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #3 from Gerrit Code Review  ---
Change 17749 had a related patch set uploaded by Pascal Quantin:
TCP: fix follow stream functionality

https://code.wireshark.org/review/17749

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

Erik Hjelmvik  changed:

   What|Removed |Added

 CC||erik.hjelm...@gmail.com

--- Comment #2 from Erik Hjelmvik  ---
This bug seems to apply to version 2.2.0 as well.

I extracted some TCP streams to binary files with Wireshark (follow-tcp-stream,
choose-one-direction, data=raw, save-as). I compared the raw files to the
output from tcpflow on the same PCAP. Unfortunately Wireshark inserts duplicate
segments into the reassembled streams here and there for some reason.

This bug is not present in version 2.0.6, but that version has another major
bug in the follow-tcp-stream feature (segments were instead missing).

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

Michael Mann  changed:

   What|Removed |Added

 Status|UNCONFIRMED |CONFIRMED
   Hardware|x86 |All
 Ever confirmed|0   |1
 OS|Mac OS X 10.11  |All

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe

[Wireshark-bugs] [Bug 12855] Follow TCP Stream shows duplicate stream data

[bugzilla-daemon]

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12855

--- Comment #1 from nobletr...@gmail.com ---
Created attachment 14895
  --> https://bugs.wireshark.org/bugzilla/attachment.cgi?id=14895=edit
screenshot of bug

-- 
You are receiving this mail because:
You are watching all bug changes.
___
Sent via:Wireshark-bugs mailing list 
Archives:https://www.wireshark.org/lists/wireshark-bugs
Unsubscribe: https://wireshark.org/mailman/options/wireshark-bugs
 mailto:wireshark-bugs-requ...@wireshark.org?subject=unsubscribe