Dear good sir named Graham Bloice,
i love you.
Works perfectly now, exactly what i wanted. Thank god, thank you for having a protocol layout like myself. I was thinking about doing a structure to hold a count number as well, but wasnt sure how it was all going to work. This is brilliant.
For you or anyone else that could answer though, i dont really understand what conversations are, could anyone help explain? I tried looking through the source but i dont really get it.
Thanks so much again,
Greg
*************************************
Greg,
I've watched this conversation from the sidelines for a while because
the only example I know about is the one I did for the DNP 3.0 protocol
(packet-dnp.c) which is complicated enough without having to go through
re-assembly, but I think the bit you need might be clear enough to
understand. I'm not certain that I've done everything correctly but it
seems to work for me. DNP3.0 sends message data (application layer or
AL) in a transport layer message (TL) wrapped in a data link layer (DL)
frame that has heavy CRC checking. The transport layer has a header
with flags indicating the first and last messages in a fragmented sequence.
All line numbers I'm quoting refer to the current trunk version of
packet-dnp (r). The fragments have no common "ID" in the protocol so I
needed to invent one as the re-assembly stuff needs one. To do this I
create a conversation and store a sequence number in the conversation.
Around about line 2512 enough fiddling has been done to extract the
payload from the encapsulating headers. The two header flags tr_fir
(first message in a fragmented sequence), and tr_fin (last message in a
fragmented sequence) have been set from the header. A non-fragmented
message has them both set, so that is the else branch at line 2577.
Around line 2517 If it is a fragmented packet, then pinfo->fragmented is
set to true and a check is made for a conversation. If no conversation
is found a new one is created.
Around line 2529 a pointer to the data structure (dnp3_conv_t) is
retrieved from the conversation. If this is null (i.e. no existing data
structure) a new structure is allocated, a sequence number is stored in
the structure (incrementing a static sequence counter for the next
conversation) and the structure added to the conversation data. Now
there is a data structure the sequence number is extracted from it.
Around line 2548 the message fragment (just the payload remember) is
added using fragment_add_seq_next() noting that tr_fin is passed in to
indicate if this is the last fragment.
Around line 2554 process_reassembled_data() is called to see if
reassembly is complete, a tvb* will be returned if this is the case.
This is checked around line 2558 and an appropriate update done to the
info column.
Finally at the bottom of the loop, line 2594, if the reassembly produced
a tvb or it was a complete message, that is handed off to the
application layer dissector.
I hope this helps.
--
Regards,
Graham Bloice
