Subject: Bug#617344: wireshark: "follow TCP stream" doesn't indicate truncated data

From: "Ph. Marek" <[email-masked]>
Date: Tue, 08 Mar 2011 10:47:18 +0100

Package: wireshark
Version: 1.4.4-1
Severity: normal

When using a limited capture length "Follow TCP stream" shows no indicator that
there's data missing.
Not even the "Save to File" in hexdump gives holes in the addresses.

I'd expect some visually marked hint "<data missing>" or something like that,
in both packet loss and truncated captures.

The hexdump should at least show correct addresses for the data - holes in the
dump would be unavoidable anyway.

Another, smaller nuisance are the empty lines in hexdump output.

-- System Information:
Debian Release: wheezy/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.34-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_AT.UTF-8, LC_CTYPE=de_AT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages wireshark depends on:
ii  libc6                   2.11.2-13        Embedded GNU C Library: Shared lib
ii  libglib2.0-0            2.28.1-1+b1      The GLib library of C routines
ii  libgtk2.0-0             2.20.1-2         The GTK+ graphical user interface
ii  libpango1.0-0           1.28.3-2~sid1    Layout and rendering of internatio
ii  libpcap0.8              1.1.1-2          system interface for user-level pa
ii  libportaudio2           19+svn20110302-1 Portable audio I/O - shared librar
ii  libwireshark0           1.4.4-1          a network packet dissection librar
ii  libwiretap0             1.4.4-1          a network packet capture library -
ii  libwsutil0              1.4.4-1          network packet dissection utilitie
ii  wireshark-common        1.4.4-1          network traffic analyzer - common
ii  zlib1g                  1:1.2.3.4.dfsg-3 compression library - runtime

wireshark recommends no packages.

wireshark suggests no packages.

---

From: Philipp Marek <[email-masked]>
Date: Tue, 8 Mar 2011 11:29:48 +0100

On Tuesday 08 March 2011, Ph. Marek wrote:
> When using a limited capture length "Follow TCP stream" shows no
> indicator that there's data missing.
> I'd expect some visually marked hint "<data missing>" or something like
> that, in both packet loss and truncated captures.
Correction: It *does* show truncations (at least sometimes - I've surely had 
data missing and didn't see the indicator).

> The hexdump should at least show correct addresses for the data - holes
> in the dump would be unavoidable anyway.
The indicator in the hexdump is a string like this:

 [2169 bytes missing in capture file]

This has neither the correct length (even more so if only a few bytes are 
missing!!), and the addresses are still wrong.

The "Flow Graph" shows no missing data, though??

> Another, smaller nuisance are the empty lines in hexdump output.
This is still true.

---

From: [email-masked] (Debian Bug Tracking System)
Date: Tue, 08 Mar 2011 10:39:10 +0000

Thank you for the additional information you have supplied regarding
this Bug report.

This is an automatically generated reply to let you know your message
has been received.

Your message has not been forwarded to the package maintainers or
other interested parties; you should ensure that the developers are
aware of the problem you have entered into the system - preferably
quoting the Bug reference number, #617344.

If you wish to submit further information on this problem, please
send it to [email-masked].

Please do not send mail to [email-masked] unless you wish
to report a problem with the Bug-tracking system.

-- 
617344: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=617344
Debian Bug Tracking System
Contact [email-masked] with problems

---

From: Bálint Réczey <[email-masked]>
Date: Tue, 8 Mar 2011 12:29:30 +0100

Hi,

> data missing and didn't see the indicator).
Could you please attach the problematic capture file?

When working with truncated packets one has to be prepared for such problems.
Every truncated packet is marked in tree-view:
...
    Destination port: db-lsp-disc (17500)
    Length: 147
    Checksum: 0xd861 [unchecked, not all data available]
        [Good Checksum: False]
        [Bad Checksum: False]
Dropbox LAN sync Discovery Protocol
[Packet size limited during capture: DB-LSP-DISC truncated]

Display filter "short" will match those packets.

>> Another, smaller nuisance are the empty lines in hexdump output.
Reported to upstream as:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1678

Cheers,
Balint

---

From: Philipp Marek <[email-masked]>
Date: Tue, 8 Mar 2011 12:36:18 +0100

Hello Bálint,

thanks for the quick answer.

On Tuesday 08 March 2011, Bálint Réczey wrote:
> > Correction: It *does* show truncations (at least sometimes - I've
> > surely had data missing and didn't see the indicator).
> 
Hmmm, this one I can't attach.

Perhaps it's a bug regarding merging of multiple capture files, finding 
duplicates (see also #616415) and/or out-of-order packets ...

I'll try to get something to show.

> When working with truncated packets one has to be prepared for such
> problems. Every truncated packet is marked in tree-view:
...
> Display filter "short" will match those packets.
Thank you for this hint.
Well, but that does not work for simply missing packets.

> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1678
Thank you.

Regards,

Phil

---

From: Bálint Réczey <[email-masked]>
Date: Wed, 9 Mar 2011 01:27:03 +0100

> Well, but that does not work for simply missing packets.
Honestly I can't think of any practical use of the exported TCP data
in case we limit capture length, because of the missing bytes.

Cheers,
Balint