Den 23. jun. 2007 kl. 11.54 skrev Graeme Lunt:
I *think* this can be made a bit more generic and just call dissect_ber_octet_string to extract the data - this will cope better when subsequent fragments useconstructed octet strings.
Yes, this works for all my captures.
Another feature with this patch is that the info column shows info from the RTSE content instead of SES "MAJOR SYNC POINT (MAP) SPDU" :) (p772-transfer-success.pcap)I like this, but I think we may be better using col_set_fence() to achievethis consistently.
This will be a bit strange when the MAJOR SYNC POINT is in its own frame.
I suppose we get Protocol "S4406," and Info "Military ... | ".
One disadvantage is that the last RTSE fragment always is 0 bytes (no data). Any idea how (and if) this can be fixed?I think we can do this by comparing the RTSE fragment size to the negotiatedcheckpoint size (though there may be a better way?).
This will not work for messages where the last fragment has "checkpoint size" bytes, which happens in about 1 of 3072 packages when using 3k size. Of course, it will work in most cases :)
I also have some captures from Microsoft Exchange 2003 (from a customer) which does not follow the 1k limits (the RTSE data segment is 3051, not 3072 as it should be). This messages will not be reassembled correctly with your approach.
In your patch, if you have more than one RTSE fragment in one frame (I have seen this in MS captures) you will have two (or more) reassembled messages which is a bit strange.
Attached a patch to fragment.c with fragment_end_seq_next() to end the fragmented data without adding an empty data fragment. This will still show a reassembled entry when receiving a message smaller than the checkpoint size, but without the 0 bytes fragment.
Also attached a new patch for SES, PRES and RTSE which uses dissect_ber_octet_string() and fragment_end_seq_next().
-- Stig Bjørlykke
fragment_end_seq_next.patch.gz
Description: GNU Zip compressed data
packet-ses-pres-rtse-2.patch.gz
Description: GNU Zip compressed data
_______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
