> > problem, I want to set a filter for the same dissector multiple
> > times.
> Presumably meaning you want to, at time T, specify that your dissector
> should be called for TCP port A and, at time T+delta T, specify that it
> should be called for TCP port B, perhaps based on traffic you see
> between times T and T+delta T (for example, a packet saying "further
> traffic will be on port X").
I mean at time T I'd like to say: "port x is icq_tcp". at time T+delta T I'd
like to say "and port y is icq_tcp" as well. And at time T+more delta T I'd like
to say "forget about all the ports please". That's something different from
what you described. That functionality I can get with the current plugin
semantics.
> > add_plugin, and plugin_release_filter don't offer me a way to
> > set a filter "tcp.port == a" and another "tcp.port == b". If I try to
> > mix it in one filter, I get a lot of bookkeeping when "tcp.port == a ||
> > tcp.port == b || ....". That's something I don't really fancy.
> Hmm.
> If there were a way to fetch the existing filter, you could edit it to
> add the new port, and supply that as the new filter...
Yes. However, it'd mean do some serious bookkeeping on my side. I'd prefer
to have an entry added to the list of filters, so in packet-tcp for instance
the code could become:
while (filter_available) {
if (dissector = passes_filter(f,packet) {
if ((*dissector)(packet) == true)
break; /* packet was dissected ok */
}
}
> ...but that's a bit complicated if all you want to do is add a TCP port.
precisely.
> In addition:
> 1) display filters are very general, but could be expensive to
> evaluate;
They are the most powerful expression method available, even though expensive.
> 2) if a user just wants to specify "for this capture, treat port
> X as protocol Y" (or "treat ATM virtual circuit VPI.VCI as
> protocol Z", or...), allowing them to just specify ports
> might be simpler than having them construct a full-blown
> display filter;
It might.
As an aside, in add_plugin you have to specify a compiled display filter. Can
a NULL be fed into that parameter or will things suddenly break?
> implementation can specify that some other protocol should use
> particular values for its "standard" discriminator field or fields (port
> number, Ethernet protocol number, PPP protocol number, ATM VPI.VCI,
> etc.) to decide whether to call protocol X or not.
That is the better way to do it, computation wise.
