On Wed, Aug 17, 2022 at 6:31 AM Richard Sharpe
<realrichardsharpe@xxxxxxxxx> wrote:
>
> On Sun, Jul 31, 2022 at 3:36 AM João Valverde <j@xxxxxx> wrote:
> >
> > Maybe we could add wildcards?
> >
> > |diameter.*.Result-Code
> >
> > The star represents "any nesting level", not "any number of characters".
> > I.e: it's not a text match, it matches levels on the protocol tree.
> >
> > It's not trivial at all to implement though. I think it would have to
> > use a loop in DFVM code.
>
> It looks like I am going to have to revisit this.
>
> I did think of using wild cards, however, I now think it is going to
> be easier to do something like:
>
> 1. In the code indicate that the filter expression supplied by the HF
> should have a string prepended. In the use case I am thinking of it
> would be something like "sta_profile_<b>" without the angle brackets.
> There will be well known points in the code where this should be done.
> This makes it easy to understand how to derive the filter expressions.
> 2. Carry around with the field in the tree the prefix that applies.
> 3. Modify the DFVM code to use the prepended string.
OK, it turns out this approach will not work either, or at least the
simple version.
I was thinking of setting up the names like
"sta_profile_1.wlan.eht.multi_link..." but since sta_profile_1 would
not be part of the filter expression for any header field and making
it so would wildly increase the total number of header fields and
require touching lots of code, I looked at an alternative.
The alternative I am looking at ATM is:
'sta_profile_1:wlan.eht.multi_link...' and have made some progress on
the dfilter grammar etc to support this.
A problem is that if there is further recursion in these things I
might have to add support for something like
'sta_profile_1:<some_other_context>:wlan.eht.multi_link...'
The context info would be added by the appropriate dissector(s).
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)