Francisco Alcoba (TS/EEM) wrote:
The patch in
http://www.ethereal.com/lists/ethereal-dev/200502/msg00451.html
introduced a protocol-independent filter based on frame numbers.
So is the purpose of this to set the display to show all packets in the
VoIP conversation, regardless of the protocol?
A general mechanism a tap can use, where it can request a "filter"
operation in which it either
1) calls a routine that scans through the packets, calls back to the
tap to ask whether the frame should or shouldn't be included and, if it
should be included, dissects the frame to generate the column data and
adds it to the display
or
2) calls a routine to clear out the "passed_dfilter" flag on all
frames, loops over the frames and calls a routine to set that flag on
frames it wants in the display, and then calls another routine that
scans over all the frames and puts the ones with that flag set into the
display
would probably be the best way to handle this.
The tap should probably also be able to add to the drop-down list of
filters an entry with a string (used as the text in the drop-down list
as well as in the filter field), a function pointer for a callback, and
a pointer passed to that callback, so you can select that item from the
drop-down list and re-apply the "filter" by calling back the function.
(The function pointer could be null - that'd put the text into the
filter field, but not in the drop-down list, and would be used if it's
infeasible to re-apply the "filter".) Those entries would be removed
when the capture file is closed.
The attached patch tries with frame number based filters; if it gets longer than
2048 characters -that seems to be the limit for display filters- it reverts to
the old code -which do not cover some cases, like MGCP, but is better than nothing-.
Checked in as a short-term workaround.