https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4624
Summary: TCP reassembly can call subdissector with incorrect
TCP sequence number
Product: Wireshark
Version: 1.2.6
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: jmmikkel@xxxxxxx
Created an attachment (id=4458)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=4458)
set tcpinfo->seq in desegment_tcp() before calling process_tcp_payload()
Build Information:
TShark 1.2.6
Copyright 1998-2010 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GLib 2.22.3, with libpcap 0.9.4, with libz 1.2.3, without POSIX
capabilities, with libpcre 7.8, with SMI 0.4.8, without c-ares, without ADNS,
without Lua, with GnuTLS 2.8.3, with Gcrypt 1.4.3, with Heimdal Kerberos,
without GeoIP.
Running on NetBSD 5.0_STABLE, with libpcap version 0.9.4, GnuTLS 2.8.3, Gcrypt
1.4.3.
Built using gcc 4.1.3 20080704 prerelease (NetBSD nb2 20081120).
--
I have a dissector trying to use the TCP desegmentation. But the TCP sequence
numbers aren't coming through correctly. For simplicity, imagine two packets
with 100-byte TCP payloads, covering higher-level protocol messages of lengths
50, 100, 50 bytes.
Using the TCP desegmentation, I would expect my subdissector to be called three
times with complete messages (that is, ignoring calls where the subdissector
requests further desegmentation), with tcpinfo->seq set to 0, 50, and 150.
Instead it is called with 0, 50, and 50. When there is a message in a packet
that completed a message started in an earlier segment, the subdissector will
subsequently get the *next* message in that completing packet with the sequence
number claimed to be the previous message's.
Without the correct sequence numbers my plugin has to do its own
desegmentation, which is exactly what it was doing before because the TCP
desegmentation was not good with protocols that didn't know the message length
a
fixed distance into each message. Maintaining that separate desegmentation is
turning into a hassle as Wireshark changes, which is why I wanted to switch to
the TCP desegmentation now that it "works" for this protocol, except for the
sequence numbers being wrong.
I looked through the TCP dissector a bit and found that desegment_tcp() does
set the tcpinfo->seq after a reassembly (which is where the 50 comes from). But
when there is more data, it goes around the loop without setting tcpinfo->seq
again (which is where the second, incorrect 50 comes from). The included change
appears to work.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.