Hi folks,
Some time ago (back in August or September) I raised the subject of
being able to filter within specific substructures in a particular
protocol. This has come up in a couple of places now in ieee802.11
where they allow Informational Elements (IEs) (which are TLVs) to
appear in other IEs, and also allow multiple instances of the first
level of IEs.
Specifically this came up in the context of handling the Multi-Link IE
in 802.11be (Draft).
I proposed an approach that used the concept of contexts where a
filter expression could be of the form
"sta_profile_1:wlan.tcprep.trsmt_pow[==28]" for either searching for
frames within "sta_profile_1" (whatever that is) that contain the rest
of the filter string or that actually match the value.
There was some discussion on this but in the spirit of trying
something instead of arguing about it interminably, and because the
user needed it, I went ahead and implemented something in 3.4.8 (which
they have currently standardized on.)
This gave me a lot of understanding of the code in that area and had
the upside that it worked. However, it also has some deficiencies:
1. There was no registration of those contexts so user couldn't easily
find out about them,
2. It required adding special code to the dissectors that wanted to
support this approach,
3. It only allows one level of contexts while it is conceivable that
there will be situations in the future where there would be a need to
say something like "find me packets where field "syz" within field
"abc" within field "def" has value "qrs".
That being the case I thought I would raise the issue again and
propose something slightly different.
The first thing to do is to make it more general by removing the need
for these special contexts and I figured the easiest way to do that
was to actually extend the existing filtering system and extend the
syntax a little. Eg:
"wlan.eht.multi_link.sta_profile==1:wlan.tcprep.trsmt_pow[==28]"
The square brackets are not part of the syntax and just allow me to
express two filters in one string.
The benefit of doing this is that there should be no need to add
special code and everything is registered. Of course the lexical
scanner code will have to be changed to accept such filter strings but
the added flexibility will be worth it, IMO. It will also lend itself
well to allowing multiple levels of context without adding lots of
extra code in dissectors.
One issue with this approach is that you cannot use calls like
proto_tree_add_subtree[_format] to add the substructures because you
do not provide a filter string associated with the subtree you are
adding so dissectors will have to use a combination of
proto_tree_add_item and proto_item_add_subtree.
I have manufactured capture files that have such cases so I can
explore these concepts.
However, there are likely to be many cases where dissector authors
have used proto_tree_add_subtree et al, which means that such
filtering will not always be possible.
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
