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 ...
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)