Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Sub_dissectors assertion failed

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Mon, 24 May 2010 10:57:16 -0700
On May 24, 2010, at 9:40 AM, Scott wrote:

> Hi Guy!  I hope your weekend was enjoyable.

Thanks!  I hope yours was enjoyable, too.

> On Sat, May 22, 2010 at 2:39 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>> So presumably the IP protocol rider protocol has fields of its own.
>> 
>> Does the IP protocol rider have an IP protocol number assigned to it, so that you have:
>>        link-layer protocol
>>        IP, with the IP protocol number having the value for the IP protocol rider protocol
>>        IP protocol rider protocol
>>        custom protocol
>>        some protocol that normally runs directly atop IP
>> 
>> or is this a non-standard encapsulation where you have:
>>        link-layer protocol
>>        IP, with the IP protocol number having the value for the protocol that's above the custom protocol
>>        IP protocol rider protocol
>>        custom protocol
>>        some protocol that normally runs directly atop IP
>> 
> 
> The former.

So that means that either the IP protocol rider protocol, or the custom protocol, needs to have a field giving the protocol number of the protocol that runs top the custom protocol.  Which of of them has that field?

> I overcame the problem of the protocols not matching by seeing that the protocol number copied over from IP to my IP rider and *supposedly* stored in hf_[IPR protocol] field was incorrect.  It was 65,000 something when printf'd.  What does hf_register_info do with that variable (hf_[IPR protocol])?

What do you mean by "hf_[IPR protocol]"?

A protocol *does* have a gint value that corresponds to it, but it's not put into the hf_register_info array for that protocol; it's separately returned by the call to proto_register_protocol().  That value is used in the protocol dissector's proto_tree_add_item() or proto_tree_add_protocol_format() call that adds the top-level item in the protocol tree for that protocol's data.

In the array of hf_register_info values are structures that have information about various fields in packets for that protocol; that includes pointers to hf_ variables for those fields.  Those hf_ variables are set by the proto_register_field_array() call.

Both the proto_ values returned by proto_register_protocol(), and the hf_ values set by proto_register_field_array(), are used as indices into a big table of structures giving information about protocols and fields.  Those indices are passed to various routines that add items to protocol trees, as well as some other routines.

> I suppose telling it that it is an FT_UINT8 tells it how to read it from the tvbuff_t.

The type field of an hf_register_info structure indicates, for octal and hex values, how many digits to display.  proto_tree_add_item() will fetch the value from the tvbuff, but the call it uses depends on the length field, not the type of the field - there are, I think, some dissectors where a field of a given FT_UINTn or FT_INTn type doesn't always have the same length in the packet.