Luis EG Ontanon schrieb:
On 7/24/07, Luis EG Ontanon <luis.ontanon@xxxxxxxxx> wrote:
The issue is: first, last, or a middle one?
the lack of a good answer to that question is the reason that feature
is not yet there.
A good answer can be: in that case we fail with an "macro can have
more values" error.
Sounds ok. I've thought about a dialog asking the user which of the
possibilities to choose, but simply throwing an error is good enough for
a good start.
Still there are more issues that come:
Such a macro would yield an error "non existent value" when there's no
capture open, so there's no current frame, idem for tshark.
You wouldn't apply a filter if you don't have a capture file, don't you ;-)
And that would happen yet again if such a macro is used for a color filter.
I don't think this can work for a color filter, as color filters will be
applied before any packet is selected. Something similiar applies for
tshark, as there's no currently selected packet, at least AFAIK.
And yet again that would happen if the selected frame does not have an
${eth.src} value (an MTP3 capture).
Yes, the value from the selected packet might not be existing (e.g.
happens simply when currently all packets are hidden), so in this case
an error has to be thrown as well.
If we consider this dynamic condition that a filter can be correct or
incorrect depending on when it is compiled this is feasable (and a
nice feature too!)...
This is obviously the case, e.g. you cannot filter on the TCP port, if
the current packet is only UDP - so this filter can fail depending on
circumstances.
Regards, ULFL