Wireshark-bugs: [Wireshark-bugs] [Bug 592] "Follow TCP Stream" (silently) fails to show a connec
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=592
sake@xxxxxxxxxx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |sake@xxxxxxxxxx
------- Comment #7 from sake@xxxxxxxxxx 2007-03-31 11:50 GMT -------
I am also able to reproduce the issue (Wireshark-SVN-21278 on WinXP). It looks
like your capture-file is incomplete. There are frames missing (see the
expert-messages on "ACKed lost segment). However, the endpoints don't seem to
be missing these frames since no retransmissions and duplicate ack's are seen.
The follow-tcp-stream code tries to reassemble all tcp-data and it puts it in
the proper order (if frames are received out-of-order). I guess the code sees
packet 1912 as out-of-order since there is data missing between frame 1912 and
1907. Up to frame 1907, 1848227 bytes have been seen, the 1848228th byte is
expected (tcp.nxtseq==1848228 if relative seqnr's are used). This is the exact
amount that is shown in the follow-tcp-stream window. After that, it still
waits for the frame with tcp.seq==1848228, which never comes.
OK, so much for the cause of this issue. How to fix it? I see a couple of
possibilities:
1) Add a check for this particular situation in epan/follow.c to set the
boolean incomplete_tcp_stream to TRUE (this will make gtk/follow_dlg.c display
"Stream Content (incomplete)" above the text-widget.
2) Add a pop-up window with a warning that the content of the tcp-stream is
incomplete
3) Make follow-tcp-stream insert [data-missing] (in another color?) at each
spot in the text-widget where data is missing in the tracefile.
I think 1 & 2 are relatively easy to implement, option 3 would be nice, but
needs a lot of work I think.
Cheers, Sake
--
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
