[Roland Knall <rknall@xxxxxxxxx>]

One more viewpoint. If you consider not only network specialists but also stack developers a s your target audience, you have no choice of putting all fields in no matter how obscure or rare in general they are. 

That had always been my approach

Cheers

Roland

Am 21.06.2022 um 23:02 schrieb John Thacker <johnthacker@xxxxxxxxx>:



GTP-U has something similar, noted here (where you can see Jaap mention his philosophy as above):

https://gitlab.com/wireshark/wireshark/-/issues/16659

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

On Wed, Jun 22, 2022 at 3:34 AM Uli Heilmeier <uh@xxxxxxxxxxxx> wrote:

What Jaap says: +1

Am 21.06.22 um 20:21 schrieb Jaap Keuter:
> Hi,
>
> Dissect it all I say. That’s what this tool is for.
>
> Jaap
>
>
>> On 21 Jun 2022, at 18:53, Richard Sharpe <realrichardsharpe@xxxxxxxxx> wrote:
>>
>> Hi folks,
>>
>> One of the things I dislike in dissectors is where people don't
>> dissect all the bytes in a packet. Sometimes it is done because the
>> bytes are padding bytes or because the function of those bytes is
>> unknown or what have you.
>>
>> An interesting case relates to radiotap where since the HE (High
>> Efficiency, Wi-Fi 6) version the spec has included an set of 'known'
>> fields in the header. These bits indicate which of the following
>> fields are actually known. Fields that are not known will have values
>> in them but the values did not come from hardware.
>>
>> The question is: Should those fields be displayed but marked as not
>> known? That is, should they be inserted into the tree.
>>
>> Doing so makes filtering easier because you can just filter on the
>> fields of interest instead of having to filter on a known field.
>>
>> Not doing so leaves gaps in the data if you are looking at the data
>> portion of a frame.
>>
>> Any thoughts on how this should be handled?
>>
>> --
>> Regards,
>> Richard Sharpe
>> (何以解憂？唯有杜康。--曹操)(传说杜康是酒的发明者)
>> ___________________________________________________________________________
>> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>> Archives:    https://www.wireshark.org/lists/wireshark-dev
>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>>              mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
>               mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
            mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe