Subject: wireshark: "follow TCP stream" doesn't indicate truncated data
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.
Information stored
: Bug#617344; Package wireshark.
(Tue, 08 Mar 2011 10:39:10 GMT) (full text, mbox, link).
Acknowledgement sent
to Philipp Marek <[email protected]>:
Extra info received and filed, but not forwarded.
(Tue, 08 Mar 2011 10:39:10 GMT) (full text, mbox, link).
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.
> 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.
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.
Hi,
2011/3/8 Philipp Marek <[email protected]>:
> 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.
>> 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.
> Correction: It *does* show truncations (at least sometimes - I've surely had
> 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.
>
>
>
>> 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.
Reported to upstream as:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1678
Cheers,
Balint
Acknowledgement sent
to Philipp Marek <[email protected]>:
Extra info received and forwarded to list. Copy sent to Balint Reczey <[email protected]>.
(Tue, 08 Mar 2011 11:48:06 GMT) (full text, mbox, link).
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).
>
> Could you please attach the problematic capture file?
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.
> >> Another, smaller nuisance are the empty lines in hexdump output.
> > This is still true.
> Reported to upstream as:
> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1678
Thank you.
Regards,
Phil
2011/3/8 Philipp Marek <[email protected]>:
> 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).
>>
>> Could you please attach the problematic capture file?
> 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.
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
Debbugs is free software and licensed under the terms of the GNU General
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.