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 <[EMAIL PROTECTED]> >Reply-To: Developer support list for Wireshark ><[email protected]> >To: Developer support list for Wireshark <[email protected]> >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 >[email protected] >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 _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
