Hi John,
The automated test needs to identify if the specific IEs were populated correctly from the sending device.
I'm actually not involved in this particular automated test development so my understanding of what can and can't be done in pyshark is incomplete. I was under the impression it could be a problem.
Thanks for the help.
James
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@xxxxxxxxxxxxx
To unsubscribe send an email to wireshark-dev-leave@xxxxxxxxxxxxx