On Jul 16, 2008, at 9:58 AM, Richard Achmatowicz wrote:
Qualifier: Concerning the fact that TCP segments are never
reassembled in my example, I think I found the answer.
JGroups generally writes a length field followed by data when
writing to the TCP stream - except in
one case - when it initially opens a TCP connection. It does it's
own little handshake with the
remote peer, and this handshake packet does not include a length
field. I assume that my dissector
is interpreting it as a length field (and it turns out to be a huge
length) and so segment
reassembly is failing for that reason.
If your "get PDU length" routine (the one you hand to
tcp_dissect_pdus()) assumes that the beginning of the handshake is a
length field, then, yes, your dissector is interpreting that stuff as
a length field, and if it's a large value, then tcp_dissect_pdus()
will just keep consuming TCP segments until it reassembles that large
number of bytes (if it ever does).
Unfortunately, we don't currently provide enough information to
dissectors of protocols running atop TCP to indicate whether a given
TCP segment contains the initial data in that direction or not. We'd
need to add that to the TCP dissector in order for the JGroups
dissector to be able to handle the handshake specially, unless it can
look at the packet data and determine whether it looks like a
handshake or a regular packet, in which case the "get PDU length"
should use that heuristic and return a length appropriate for the
handshake packet if the packet is a handshake packet.