Take a look at packet-ip.c
in proto_register_ip() creates the dissector_table_t:
/* subdissector code */
ip_dissector_table = register_dissector_table("ip.proto",
"IP protocol", FT_UINT8, BASE_DEC);
in dissect_ip() does:
if (!dissector_try_port(ip_dissector_table, nxt, next_tvb, pinfo, tree)) {
/* Unknown protocol */
if (update_col_info) {
if (check_col(pinfo->cinfo, COL_INFO))
col_add_fstr(pinfo->cinfo, COL_INFO, "%s (0x%02x)",
ipprotostr(iph->ip_p), iph->ip_p);
}
call_dissector(data_handle,next_tvb, pinfo, tree);
}
take a look at packet-udp.c:
that in proto_reg_handoff_udp() registers in the "ip.proto" table
udp_handle = create_dissector_handle(dissect_udp, proto_udp);
dissector_add("ip.proto", IP_PROTO_UDP, udp_handle);
On Sun, 02 Jan 2005 20:07:32 +0100, Stefano Pettini
<spettini@xxxxxxxxxxxxxxxxxxxxx> wrote:
> Hello,
>
> I have a question about a relationship between some fields and protocols.
>
> I have protocol A (A over UDP) that can transport protocol B (B over A,
> of course) and protocol C (C over A). Protocol A has extensions and
> variable fields, identified by a number.
>
> There are extensions with a number within a known interval that are
> related to A, but there are also additional extensions with a number
> within another known interval related to the upper layer protocol (B, C
> or other protocols).
>
> For example, in protocol A, the extension numbered 64 contains data
> related to protocol B, if A transports B, or to protocol C, if A
> tranports C.
>
> There's no way to understand the protocol of A's payload. This should be
> done manually by the user, using the "decode as ..." window.
>
> Where should I write the code to dissect those extensions?
>
> If I add their dissector in A, how can I know which is the upper layer
> protocol choosen by the user? Also, I think it's not a good idea to add
> the code to dissect B, C or other protocols in A's dissector.
>
> If I add their dissector in B and C, how can I access bytes of A, a
> lower level protocol? And how can I update A protocol tree?
>
> I think there could be a third way: since B and C are very related to A,
> I could consider them as a single protocol, and write 3 dissector: one
> for A (generic, that doesn't dissect those extensions), one for B/A, one
> for C/A.
>
> Any suggestion?
>
> Thanks.
>
> Stefano
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>