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 ([email protected]): > 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 ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
