On Jun 21, 2022, at 10:23 PM, Roland Knall <rknall@xxxxxxxxx> wrote:
> One more viewpoint. If you consider not only network specialists but also stack developers a s your target audience,
That's how I got started as a Wireshark user/developer - I was a stack developer at NetApp.
> you have no choice of putting all fields in no matter how obscure or rare in general they are.
For non-padding and non-reserved fields that are specified in a protocol specification, and are always present, I'd say "absolutely, yes, regardless of the audience" - but I suspect the only case where this are absent are cases where somebody just didn't get around to adding the fields.
For reserved fields, those are probably *also* specified, and I'd vote for them being present as well. "Reserved" generally mean "we may use tis in the future", which generally means "must, for now, be written/sent as 0 and ignored by readers/receivers, but we may use it in the future". In that case, *dissectors* should show it and perhaps do a check for zero and provide a warning or error, especially if the protocol spec explicitly indicates that.
For padding fields, those are either:
- reserved fields, in effect, if the amount of padding is a constant, e.g. a 2-byte integral field, followed by 2 bytes of padding, followed by a 4-byte integral field, with the padding putting the 4-byte field on a 4-byte boundary, or unused bits of an N-byte field divided into bit-aligned subfields, as those could be used in future versions of the protocol without requiring a complete redefinition of the packet layout;
- extra empty space if the amount of padding is *not* a constant, e.g. a counted string, followed by a 4-byte integral field, with 0 to 3 bytes of padding between them to put the 4-byte field on a 4-byte boundary, as the padding isn't guaranteed to exist.
In the latter case, it should be *possible* to see the padding, so either it should always be displayed or there should be a preference for displaying it if displaying it makes it more annoying for non-developer network specialists.
A case could be made that it should *also* be checked for non-zero values, at least in "stack developer mode", with a warning if it's non-zero, as that might, for example, be the result of data leaking from the writer/sender when it shouldn't leak.
The cases Richard Sharpe and John Thacker bring up are not any of those; those are fields whose *values* are not always present but for which the *bytes* are always present.
Those could be thought of as being similar to padding, in that they presumably exist either to make a structure fixed-length or to ensure that the next field is always at the same offset relative to an earlier field, which would argue that they should be treated the same as padding.