Wireshark-bugs: [Wireshark-bugs] [Bug 3101] tshark data.data does not display hexdump of 1-byte
Date: Wed, 10 Dec 2008 11:27:01 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3101





--- Comment #4 from Sake <sake@xxxxxxxxxx>  2008-12-10 11:27:00 PDT ---
I can reproduce the issue with your capture file (after disabling the ldap
dissector):

$ tshark -r bug3101.pcap -T fields -e frame.number -e tcp.seq -e tcp.len -e
data.data
1       0       0
2       1       0
3       1       39      41:41:...:41
4       40      65      42:42:...:42
5       105     1
$

The problem in this trace is caused by the lack of packets in the other
direction. This means the window size of the returning flow is not set. That's
why the last packet is treated as an "Zero-Window-Probe" which wireshark
somehow does not treat as real data. This has to be looked into...

As a workaround you can disable tcp.analyze_sequence_numbers:

sablo@BLOK /cygdrive/c/temp
$ tshark -o tcp.analyze_sequence_numbers:FALSE -r bug3101.pcap -T fields -e
frame.number -e tcp.seq -e tcp.len -e data.data
1       3864723446      0
2       3864723447      0
3       3864723447      39      41:41:...:41
4       3864723486      65      42:42:...:42
5       3864723551      1       43
$

BTW which my version of tshark [TShark 1.1.2-SVN-26732 (SVN Rev 26732)] I am
indeed able to show the real sequence numbers by setting
tcp.relative_sequence_numbers to FALSE with -o:

sablo@BLOK /cygdrive/c/temp
$ tshark -o tcp.relative_sequence_numbers:FALSE -r bug3101.pcap -T fields -e
frame.number -e tcp.seq -e tcp.len -e data.data
1       3864723446      0
2       3864723447      0
3       3864723447      39      41:41:...:41
4       3864723486      65      42:42:...:42
5       3864723551      1

$


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.