> I couldn't find anything on this list (might have overlooked). I went
> off with the plugin interface which was supposed (right?) to offer a
> dynamic allocation service (at least, when looking at the dissect_tcp
> function, it kinda gives that impression). However, I'm having a small
> 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").
> 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...
...but that's a bit complicated if all you want to do is add a TCP port.
In addition:
1) display filters are very general, but could be expensive to
evaluate;
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;
so perhaps we should have both the fully-general display filter
mechanism and simpler, more specialized mechanisms by which a protocol
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.
