On May 24, 2010, at 12:18 PM, Scott wrote:
> On Mon, May 24, 2010 at 11:57 AM, Guy Harris <[email protected]> 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.
OK, so that's a little more complicated. There are (at least) three ways of
handling that:
1) dissect the IP rider and the custom protocol as separate protocols,
and use the standard mechanisms for handing off from the IP rider dissector to
the custom protocol dissector;
2) dissect the IP rider and the custom protocol as separate protocols,
and use a specialized mechanism for handing off from the IP rider dissector to
the custom protocol dissector;
3) dissect them as a single protocol.
For 1), you would have to pass the IP protocol number from the IP rider
protocol to the custom protocol. What you would do there is:
In the IP rider dissector:
in its register-handoff routine, register it in the "ip.proto"
dissector table with its IP protocol number, and fetch a handle for the custom
protocol dissector with find_dissector(), using the name the custom dissector
uses to register itself;
in its dissection routine, fetch the IP protocol number field's value
into a local variable, and, when you want to call the custom protocol's
dissector, set "pinfo->private_data" to point to the local variable and call
the custom protocol dissector, using its handle, with call_dissector().
In the custom protocol dissector:
in its register routine, register the dissector handle with
register_dissector(), using the same name that the IP rider dissector uses to
find it;
in its register-handoff routine, fetch the "ip.proto" dissector table
with find_dissector_table();
in its dissection routine, when it is to call the dissector for its
payload, use dissector_try_port(), using the IP protocol number pointed to by
pinfo->private_data.
2) could be done similar to 1), except that you could just directly call the
custom protocol dissector and have it take an additional argument, the IP
protocol number, as an argument, or you could just dissect both protocol layers
in the same routine. That would, however, mean that some of the work done for
you by call_dissector(), such as saving and restoring some state (which might
not matter if your dissector doesn't change it), setting the current protocol
name that shows up in some messages, and updating the list-of-protocols field,
won't be done. I wouldn't recommend doing it that way.
How 3) would be done should be obvious, but there might be reasons not to do
that.
>>> 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.
Yes - not all fields *have* integral values, so the hf_ variable couldn't be
used for that purpose.
> If this is still the wrong format (calling dissector_try_port twice or
> otherwise), please let me know!
Yes, it is - see above for the right way to handle those two protocols.
> Otherwise, here comes another question. I solved the problem exhibited in:
> http://img80.imageshack.us/img80/5582/malformed.gif
You mean the problem that Wireshark thinks that 0x1bc4 is not equal to 0x1bc4?
:-)
> 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).
That's odd - the reported_length value for the tvbuff handed to the IPR
dissector should be the total length value from the IP header unless this is an
IP fragment, so changing the value of the length shouldn't matter.
Is the packet in question the first fragment of an IP datagram?
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
