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 <g...@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-requ...@wireshark.org?subject=unsubscribe
