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.
