Re: working with header data

[Guy Harris <guy () alum mit edu>]

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