Wireshark-dev: Re: [Wireshark-dev] Sub_dissectors assertion failed
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: Scott <theerickson@xxxxxxxxx>
Date: Mon, 24 May 2010 13:18:00 -0600
On Mon, May 24, 2010 at 11:57 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
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?

The IP Rider contains 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]"?

Sorry, I wasn't especially clear.  I meant one of the variables declared as:
static int hf_IPR_protocol = -1;
that is used in the hf_register_info struct.  I didn't know what those were for (I thought they stored the actual value extracted from the packet), but you answered my question with:
 
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.


If this is still the wrong format (calling dissector_try_port twice or otherwise), please let me know!  Otherwise, here comes another question.  I solved the problem exhibited in:
by hardcoding a value into the reported_length parameter of tvb_new_subset() instead of using -1.  This is obviously not a long term solution, so what I need to get at is the IP header's value for "Total Length" (ip.len).  Is there a function for that?

Thank you,
Scott