Wireshark-dev: Re: [Wireshark-dev] working with header data
From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 14 Oct 2011 13:48:29 -0700
On Oct 14, 2011, at 1:16 PM, Ed Beroset wrote:

> I did two earlier versions of the code that did something like that. One version used knowledge of what the tags are and recalculated the length based on the length of the tvb.  The other one looked attempted to verify that the expected tag really was the expected number of bytes ahead of the data.  Both versions seemed messy and complex to me.

So why does not a #.FN_BODY such as

	int start_offset = offset;
	int length;

	$(DEFAULT_BODY)

	length = offset - start_offset;

	<copy "length" bytes of stuff starting at "start_offset">

work?  No need to know what the tags are, no need to verify anything, from what I can see.

>>> The more serious problem is that to enable filtering based on
>>> crypto results (e.g. "c1222.crypto_good == true"), the code must
>>> also work on packets that haven't yet been parsed.
>> 
>> Why is that the case?  "c1222.crypto_good" is part of the protocol
>> tree, and gets put there as part of the parsing process.  You can put
>> it into the protocol tree at any point in the parsing process,
>> including after all the other parsing has been done.
> 
> I don't know why that is, but it's what I observe.  When I replace this if statement which is in the working code:
> 
>  if (PNODE_FINFO(tree)->hfinfo->id == hf_c1222_user_information)
>    pkt_tree = proto_item_get_parent_nth(tree, 2);
>  else
>    pkt_tree = tree;
> 
> with this one:
> 
>  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?

> The *displayed* values for parsed packets are all correct,

Where is the "c1222.crypto_good" field displayed in the protocol tree?  (Don't make it a hidden field; making it visible

	1) means the user sees it so they don't have to know its name to know how to filter on it in Wireshark - they could just use the "add filter" and "prepare filter" menu items;

	2) the dissection tells you directly whether the crypto is good or not.)