Wireshark-dev: Re: [Wireshark-dev] Display Filter Macros of currently selected packet fields?
I've thougth it in the past but I still got a thing to digest...
We need to pass to the Disaplay Filter Macros compiler (DFMC) the
current tree (if any) and have the compiler to replace ${eth.src} with
the representation of the value of ONE "eth.src" finfo (only one! the
first? the last? one in the middle?).
That's (you are right) relatively easy to implement. Being done once
at compile time performance is not an issue here and we could happily
traverse the proto_tree and the user will never notice.
The issue is: first, last, or a middle one?
e.g. For a tunneled IP over IP packet ${ip.addr} would have 4 possible
values: src and dest of the tunneled packet plus src and dst of the
tunnel heads. Which (if any, or all?) is the ONE right value
${ip.addr} should have at evaluation?
the lack of a good answer to that question is the reason that feature
is not yet there.
Luis
On 7/24/07, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
Hi!
When display filtering, I'll often use data from the currently selected packet, e.g. see all packets that also has the same Ethernet address pair as the current packet.
That's why I've implemented the context menu "Conversation Filter" some time ago.
However, my feeling about these filters is, that they are too inflexible for a lot of cases. So I thought about a different approach, and after some time now I've come to the conclusion that the most flexible and still understandable way would be to use fields of the currently selected packet in the filter string. One idea is to use something like:
eth.addr eq ${eth.dst} and eth.addr eq ${eth.src}
to get the same behaviour as the current "Conversation Filter/Ethernet" context menu. In fact, this is what the context menu will do "hardcoded" - get some data from the currently selected packet and build a new filter string out of it. But we would gain a lot more flexibility in the users hand being able to use such macros for the display filter in a generic way here!
Having this flexibility, we could even have user defined GUI elements to filter stuff, e.g. add user definable toolbar buttons for user defined filters. So the user can add a toolbar button to filter the stuff he want's.
Having this two (hopefully small) changes, we would gain a lot of comfort in the everyday work IMO.
Unfortunately, I don't have deep knowledge of the display filter engine, so is there any chance/interest that someone helps me with this approach? If the display filter engine is capable of using such macros, I would happily add the GUI stuff to bring this into life ...
Regards, ULFL
_____________________________________________________________________
Der WEB.DE SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
http://smartsurfer.web.de/?mc=100071&distributionid=000000000066
_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@xxxxxxxxxxxxx
http://www.wireshark.org/mailman/listinfo/wireshark-dev
--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan
