Bug#617344: wireshark: follow TCP stream doesn't indicate truncated data
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-13Embedded GNU C Library: Shared lib ii libglib2.0-02.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~sid1Layout 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-common1.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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617344: wireshark: follow TCP stream doesn't indicate truncated data
Hi, 2011/3/8 Philipp Marek philipp.ma...@linbit.com: 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617344: wireshark: follow TCP stream doesn't indicate truncated data
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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617344: wireshark: follow TCP stream doesn't indicate truncated data
2011/3/8 Philipp Marek philipp.ma...@linbit.com: 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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
