Re: Sub_dissectors assertion failed

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

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 () alum mit edu> 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.
___________________________________________________________________________
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