GTP-U has something similar, noted here (where you can see Jaap mention his philosophy as above):
There are three fields whose presence is indicated by bits being set. If at least one bit is set, then space for all three fields are present, but the bytes for the fields not present are supposed to be ignored by clients. The GTP dissector skips over the 1-3 present but unused bytes in the case where one or two of the bits are set.
Does "Fields that are not known will have values in them but the values did not come from hardware," mean that the values in those fields are nonsense and should be ignored?
There's at least three different ways to handle that kind of situation:
1. Don't put anything into the tree, skip those bytes.
2. Put something into the tree that is a different field and filter name than the real version of the field, and which covers those bytes.
3. Put the real field into the tree anyway, but mark it with an expert info PI_UNDECODED or something that indicates that the field is not to be interpreted normally.
Generally I prefer the second option, I'm ok with the first option though I think it's less than optimal, and I think that the third option is wrong. If the field isn't really there, I don't want filters to match against it (except for filters that are about checking the non-existence of a field, like "gtp and !gtp.npdu_number"), and if it means something different based on another bit, then I want to have different filter names.
The comment "Doing so makes filtering easier because you can just filter on the fields of interest instead of having to filter on a known field," makes it sound like you're suggesting the third option, but maybe I misunderstand. Are you trying to filter on the exact values of "not known" fields?
John Thacker