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

Package:
wireshark
Source:
wireshark
Description:
network traffic analyzer - meta-package
Submitter:
"Ph. Marek"
Date:
2011-07-10 13:03:20 UTC
Severity:
wishlist
#617344#5
Date:
2011-03-08 09:47:18 UTC
From:
To:
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.
#617344#10
Date:
2011-03-08 10:29:48 UTC
From:
To:
Correction: It *does* show truncations (at least sometimes - I've surely had
data missing and didn't see the indicator).
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??
This is still true.
#617344#15
Date:
2011-03-08 11:29:30 UTC
From:
To:
Hi,

2011/3/8 Philipp Marek <philipp.marek@linbit.com>:
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.
Reported to upstream as:
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1678

Cheers,
Balint
#617344#20
Date:
2011-03-08 11:36:18 UTC
From:
To:
Hello Bálint,

thanks for the quick answer.
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.
...
Thank you for this hint.
Well, but that does not work for simply missing packets.
Thank you.


Regards,

Phil
#617344#25
Date:
2011-03-09 00:27:03 UTC
From:
To:
2011/3/8 Philipp Marek <philipp.marek@linbit.com>:
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