Why would the following command fail to produce a pointer to the dissector?
sccp_handle = find_dissector("sccp");
printf("data=%p, sccp=%p\n", data_handle, sccp_handle);
The 'sccp_handle' is NULL, the data_handle is valid?
> -----Original Message-----
> From: Guy Harris [mailto:guy@xxxxxxxxxxxx]
> Sent: Monday, November 03, 2003 6:41 PM
> To: mlum@xxxxxxxxxxxxx
> Cc: Ethereal
> Subject: Re: [Ethereal-dev] Can I force data into a dissector from below
> ?
>
>
>
> On Nov 3, 2003, at 2:39 PM, Michael Lum wrote:
>
> > It has a configurable port number, defaults to 5000.
>
> OK, so the "plug it into TCP part" is easy. I wasn't sure why the
> "runs over TCP" part was mentioned....
>
> Now, for plugging BSSAP into it....
>
> How are BSSAP packets identified? Do you have to use a heuristic, or
> can the dissector for your protocol determine it based on some field in
> the protocol's data, or is it *always* BSSAP?
>
> If it's always BSSAP, just register "dissect_bssap()" with
> "register_dissector()", and have your dissector get the handle for that
> dissector in its "register_handoff" routine by calling
> "find_dissector()", and then use "call_dissector()" to call it.
>
> If it's based on some field in the protocol's data, you could, for now,
> use the previous technique, but call it based on the value(s) in the
> field or fields, or you could create a dissector table for that field
> and have the BSSAP dissector do
>
> if (find_dissector_table("proto.field") != NULL)
> dissector_add("proto.field", ...);
>
> (which has the risk that if you have a typo in the dissector table
> name, it silently fails to register, which is why we currently abort if
> the table isn't found).
>
> If it's heuristic, we'd either have to
>
> 1) add a "find_heur_dissector_table()" routine, or
> something else to
> let the BSSAP dissector check whether it exists before registering
>
> or
>
> 2) have a "nofail" version of "heur_dissector_add()" that silently
> fails if the dissector table doesn't exist
>
> (I'd prefer to have the default behavior continue to be to abort, for
> the reasons described above).
> > Ethereal-dev@xxxxxxxxxxxx
> > http://www.ethereal.com/mailman/listinfo/ethereal-dev
> >
