On Tue, Apr 29, 2003 at 01:46:11PM +0200, Ana Rodríguez wrote:
> I'm programming a DSR dissector
Is that DSR as in the Dynamic Source Routing protocol, i.e.:
http://www.ietf.org/internet-drafts/draft-ietf-manet-dsr-09.txt
If so, then:
> and I have problems calling next
> dissector. The question is that I want to call ICMP protocol, because I
> have ICMP in the packet. The order I want it apears in the Ethereal tree
> is: Ethernet, IP, DSR and ICMP.
> This is the code I made, and it doesn't work:
>
> static dissector_handle_t icmp_handle;
>
> next_tvb=tvb_new_subset(tvb,offset,-1,-1);
> call_dissector(icmp_handle,next_tvb,pinfo,dsr_tree);
>
> void proto_reg_handoff_dsr(void)
> {
> dissector_handle_t dsr_handle;
>
> icmp_handle=find_dissector("icmp");
>
> dsr_handle = create_dissector_handle(dissect_dsr,proto_dsr);
> dissector_add("ip.proto", IP_PROTO_DSR, dsr_handle);
> }
I'm not sure you want to do that; the I-D in question says
6. DSR Options Header Format
The Dynamic Source Routing protocol makes use of a special header
carrying control information that can be included in any existing
IP packet. This DSR Options header in a packet contains a small
fixed-sized, 4-octet portion, followed by a sequence of zero or more
DSR options carrying optional information. The end of the sequence
of DSR options in the DSR Options header is implied by total length
of the DSR Options header.
For IPv4, the DSR Options header MUST immediately follow the IP
header in the packet. (If a Hop-by-Hop Options extension header, as
defined in IPv6 [7], becomes defined for IPv4, the DSR Options header
MUST immediately follow the Hop-by-Hop Options extension header, if
one is present in the packet, and MUST otherwise immediately follow
the IP header.)
To add a DSR Options header to a packet, the DSR Options header is
inserted following the packet's IP header, before any following
header such as a traditional (e.g., TCP or UDP) transport layer
header. Specifically, the Protocol field in the IP header is used
to indicate that a DSR Options header follows the IP header, and the
Next Header field in the DSR Options header is used to indicate the
type of protocol header (such as a transport layer header) following
the DSR Options header.
so you don't want to check the Next Header field for specific values,
you want to use the same handoff table that IP uses (because there's
more than just ICMP following the DSR header). If you do that, it'll
automatically call the appropriate dissector, whether it be the TCP
dissector, the UDP dissector, the SCTP dissector, the ICMP dissector,
etc..
You can get that handoff table by calling
find_dissector_table("ip.proto")
and using the return value in a call to "dissector_try_port()", using
the protocol number from the Next Header field.