["Hal Lander" <hal_lander@xxxxxxxxxxx>]

Guy,

Very helful, I can see what is supposed to happen now.
The reason I wanted to loop through the dissectors was just to check I had 
managed to add mine, but I understand why that is not possible.

I am not so sure about not being able to define the order the heuristic 
dissectors are called in because I don't feel able to beef-up a somebody 
elses dissector that is wrongly grabbing packets, Jaap has mentioned 
deleting problem dissectors and I'll pick up in his post.

Thanks
Hal


> From: Guy Harris <guy@xxxxxxxxxxxx>
> Reply-To: Developer support list for Wireshark 
> <wireshark-dev@xxxxxxxxxxxxx>
> To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
> Subject: Re: [Wireshark-dev] Define dissector port
> Date: Sun, 21 Jan 2007 10:04:53 -0800
>
> Hal Lander wrote:
>
> > There is a function
> >      /* Find a dissector table by table name. */
> >      extern dissector_table_t find_dissector_table(const char *name);
> >
> > So after I have added my heuristic dissector I should be able to call
> >     tbl=find_dissector_table("tcp");
> >
> > and see my dissector?
>
> No, because that's the table for dissectors registered with particular
> TCP port numbers.  The call to get the table for heuristic dissectors is
>
> 	tbl = find_heur_dissector_list("tcp");
>
> > Does anybody have a code snippit to show how to loop the table and see 
> the
> > dissectors?
>
> No, because there is currently no way to do that.
>
> > Where is the table structure defined?
>
> Internally to epan/packet.c; it's opaque to dissectors.  That is by
> design and intent.
>
> Dissectors should not need to loop the table and see the dissectors;
> dissectors should be written in such a way as to be completely
> independent of the contents of a heuristic dissector table in which
> they're registered.
>
> > Most importantantly what determines the order in which the heuristic
> > dissectors are called,
>
> The order in which the dissectors are added to that table.
>
> > and how can I make sure mine is called first?
>
> We do not offer any mechanism to control the order in which dissectors
> are added to the table; this is by design and intent.  If another
> dissector happens to be before your dissector in the table, and happens
> to claim a packet that's a packet for your protocol, that means that
> it's claiming a packet that's not a packet for its protocol, which means
> its heuristics are too weak and it needs to be fixed.
> _______________________________________________
> Wireshark-dev mailing list
> Wireshark-dev@xxxxxxxxxxxxx
> http://www.wireshark.org/mailman/listinfo/wireshark-dev

_________________________________________________________________
Turn searches into helpful donations. Make your search count. 
http://click4thecause.live.com/search/charity/default.aspx?source=hmemtagline_donation&FORM=WLMTAG