On Sat, Nov 16, 2024 at 9:18 PM James Ko <j...@exegin.com> wrote: > In the Wi-SUN packet filters there are some information elements (IEs) > with common/reused field names. > > In the example tree below the US-IE and BS-IE both have Dwell Interval, > Clock Drift, Timing Accuracy, Channel Control, Regulatory Domain, and > Channel Plan ID. > The header_field_info for those fields were created using a > [FIELDFILTERNAME] starting with wisun.usie.* and the dissector reused the > same hfindex when adding the tree item to the different IE trees. > Some automated testing using the Python pyshark library would like to > parse out those fields by the IE it appears in. So the filtername > wisun.usie.dwell would change to wisun.bsie.dwell. > There is also a LCP-IE which also has the same fields. > > Can someone direct me to a way (or the recommended way) to modify the > dissector to improve the filtering and correct the field names without > creating duplicate hf table entries for every variant? >
Can you explain why your automated testing needs to do that? From what I can see, pyshark's documentation says that it uses tshark's XML (PDML and PSML) output (looking at the code it looks like it also can use some of the JSON flavors of output.) Those output formats produce a tree. Does pyshark flatten that for each protocol layer, and provide no way to access the original hierarchical information? If not, then perhaps your automated testing should read the XML or JSON itself instead of going through pyshark if you need the information not flattened. Otherwise, no, there is no way to do this without creating duplicate hfs for each variant, giving them each a unique abbreviation. (Depending on the dissector, some people might not *want* such separate fields, and would view such changes as making the filtering worse, not better. But in other cases people might agree.) John Thacker
_______________________________________________ Wireshark-dev mailing list -- wireshark-dev@wireshark.org To unsubscribe send an email to wireshark-dev-le...@wireshark.org
