On 7/30/22 18:35, Richard Sharpe wrote:
On Fri, Jul 29, 2022 at 9:20 AM Richard Sharpe
<realrichardsharpe@xxxxxxxxx> wrote:
Hi folks,
The wonderful people working on 802.11 have started using recursive structures.
That is, they are embedding Info Elements (IEs) within Info Elements
and there can be multiple IEs of the same type within an IE within a
Beacon or Probe etc frame.
Now some people are asking to be able to refer to a specific embedded
IE within an IE.
That would seem to present problems because there is no way to
concatenate filter expressions.
About the best I can think of is pass some context to IE dissectors
via the pinfo field and to insert that into field values via a
proto_item_append_text ...
Are there any other thoughts about how to deal with this issue?
To add more context, here is what I am doing ATM:
1. Passing in info via pinfo to say that we are in particular IE (EHT
Multi-Link) and here is the link-id,
2. In the handling of one of the embedded IEs (EHT Capabilities)
select a different set of header fields that have different filter
expressions.
This is quite complex, however, because I need 17 different sets of
HFs with filter strings like:
wlan.eht.supported_eht_mcs_bss_set.le_80.rx_max_nss_supports_eht_mcs_0_9
wlan.eht.multi_link.sta_profile_0.supported_eht_mcs_bss_set.le_80.rx_max_nss_supports_eht_mcs_0_9
The first is used when we know we are not embedded, while the second
is used when we know we are embedded but requires 16 sets of such
header fields.
It gets very complex ...
Passing the link-id via pinfo (or other method) seems unavoidable.
Having to select a different set of header fields ought to be fixed, maybe.
I think there are two fundamental issues to solve here:
1. Make the protocol field namespace hierarchical.
2. Add a mechanism to search the hierarchy.
Anyway I think you should open a detailed Gitlab issue for this use
case, with requirements and a test capture ideally.