Guy Harris wrote:
Michael J. Lynch wrote:
This question was triggered by a post from someone having trouble
getting message fragment re-assembly working. The basic question I
have is, if I write a dissector for a protocol that rides on top of
another protocol (TCP for example) and the upper level protocol
does not in and of itself fragment messages but does send messages
large enough to cause them to be fragmented by the TCP layer, can
I count on the message being re-assembled by the TCP dissector
before it is handed off to my dissector?
Not unless your dissector tells the TCP dissector to do so.
TCP is a byte-stream protocol, and has no notion of packet boundaries,
just TCP segment boundaries, which don't necessarily correspond to
packet boundaries in packets running atop TCP. As such, TCP cannot
reassemble higher-level packets without help from the dissector for the
protocol for those packets.
Dissectors for protocols running atop TCP get handed TCP segment data;
they are responsible for dealing with a TCP segment containing data from
more than one packet, or containing less than the full data of a packet.
If
1) packets in the protocol are always N bytes or longer;
2) the first N bytes of the packet can always be used to determine
how long the packet is;
then you can have your dissector call tcp_dissect_pdus() to do all that
work - you just need to write a routine that will be handed a tvbuff and
offset and process the "first N bytes", starting at that offset, to
compute the length, and a routine that will be handed a tvbuff
containing a reassembled packet and dissect it, and pass them, along
with the value of N, to tcp_dissect_pdus().
Ah....I can see said the blind man as he fell into a well. When I wrote
my dissector there was this nagging question in the back of my mind
asking, "How the heck does the dissector below me know how much data my
dissector needs for it's variable length PDU's?" This is the answer.
Thanks. Oh...and BTW...thanks for not just saying RTFM. :-)
--
Michael J. Lynch
What if the hokey pokey IS what it's all about -- author unknown