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.