Re: [Wireshark-dev] working with header data
Guy Harris wrote: crypto. If that can be done in a different fashion, as per my earlier suggestion, that code shouldn't even exist. I implemented your suggestion over the weekend and tested it today on multiple platforms. It has less monkeying around with the packet memory at the expense of more monkeying around within the ASN.1 portion. Thanks for the help! I've resubmitted the patch and attached it to https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5531 The code that actually does the crypto is in dissect_epsem(), which should only be called after all the header fields have been dissected. I'm still unclear as to when that is or how one can tell. The function in question was sometimes called with a pointer to the whole unparsed packet, and sometimes with a pointer to the parsed User-information section. I still don't know why. I've also added doxygen-style documentation on most of the functions in the C12.22 dissector I created. I'd like to continue adding to the doxygen support as well, since it could be a very valuable tool with the proper care and feeding. Ed ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] working with header data
On Oct 14, 2011, at 2:05 PM, Ed Beroset wrote: > Guy Harris wrote: >> >> On Oct 14, 2011, at 1:16 PM, Ed Beroset wrote: >> >>> if (PNODE_FINFO(tree)->hfinfo->id == hf_c1222_user_information) >>> pkt_tree = proto_item_get_parent_nth(tree, 2); else return FALSE; >> >> None of that has anything to do with adding hf_c1222_crypto_good to >> the protocol tree, which is what is relevant for making a >> "c1222.crypto_good" field work; where is the code that adds that to >> the tree? > > It does, but it's a bit indirect. If the call to that function returns > false, it's an indication that the encryption validation failed for some > reason. If "that function" is canonify_unencrypted_header(), then, if it returns false, it's an indication that the canonicalization of the header failed for some reason, so you can't even try to do the crypto. If that can be done in a different fashion, as per my earlier suggestion, that code shouldn't even exist. The code that actually does the crypto is in dissect_epsem(), which should only be called after all the header fields have been dissected. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
