It looks like reassembly is not your favourite topic ;-)
Never mind, I'll keep talking to myself, feel free to join in...
Thus wrote Martin Kaiser (lists@xxxxxxxxx):
> I now think I know what happens, I'd appreciate your opinion how to deal
> with it properly:
> a tdpu looks like
> header | body | trailer
> Depending on header info, the body may contain a fragment of an spdu.
> body_len is (no surprise) the body's length.
> I go to the beginning of the body and do the following for each and
> every message
> frag_msg = fragment_add_seq_next(tvb, offset, pinfo,
[...]
> -> I put the current body into the fragementation mechanism.
> payload_tvb = process_reassembled_data(tvb, offset, pinfo,
[...]
> And see if things can be reassembled.
> If multiple fragments were reassembled, things work ok. payload_tvb contains
> (body_len #1 + ... + body_len #n) bytes.
> The problem occurs when there's no fragments, i.e. the message can be
> "reassembled" straight away. In this case, payload_tvb contains
> body | trailer !
An obvious approach is to put the body into a separate tvbuff and pass
this tvbuff to fragment_add_seq_next() and process_reassembled_data().
body_tvb = tvb_new_subset(tvb, offset, body_len, body_len);
frag_msg = fragment_add_seq_next(body_tvb, 0, pinfo,
SEQ_ID_TRANSPORT_LAYER,
spdu_fragment_table,
spdu_reassembled_table,
body_len,
hdr_tag == T_DATA_MORE ? 1 : 0);
payload_tvb = process_reassembled_data(body_tvb, 0, pinfo,
"Reassembled SPDU", frag_msg, &tpdu_frag_items,
NULL, trans_tree);
This seems to do the trick. payload_tvb never contains any spurious
trailer.
I was wondering what the purpose of process_reassembled_data()'s first
parameter is. The function reassembles the data in the fragment_data *
if possible, what's the point in passing a tvbuff_t *?
The comments in the code explain that <result tvb> is marked as parent of
<input tvb> to allow for easier cleanup. Not sure I understand that...
Best regards,
Martin
