Wireshark-dev: Re: [Wireshark-dev] Undissected reserved fields
From: Jeff Morriss <[email protected]>
Date: Fri, 27 Feb 2015 13:28:43 -0500
On 02/27/15 11:40, Dario Lombardo wrote:
I'm playing with the "undissected bytes" functionality of wireshark,
patching some dissectors that clearly lack some fields. But now I've
found some of them that fall in a "grey area" and I'd lilke to discuss
with other devels the best way to go on.

I've found that many dissectors lack decoding of "reserved/unused"
fields. An example of them is the ISL dissector and an example file
is provabis.pcap (found it in the wiki).
This field is reserved but is part of the specifications of the protocol
(have a look here
http://www.cisco.com/c/en/us/support/docs/lan-switching/8021q/17056-741-4.html).
It is clearly stated that the field is 0x0 in ethernet, but can have
values in token ring or FDDI.

So the general question is: is it correct to leave "reserved/unused"
fields udecoded? Or would it better to decode them as described in the
actual specifications (reserved of unused)?
My opinion (which I've voiced on this list many times over the past ~10 
years) is that such fields SHOULD be dissected.  Even better they should 
have an Expert Info if they are supposed to be 0 and aren't (Guy had 
suggested on a bug or somewhere that we should have an API with a name 
that includes "mbz"--for Must Be Zero--which would add the Expert Info 
automatically).
Why do I have this opinion?

Because most of the time the specs say "must be set to 0 on transmission and ignored on receipt" but I have seen *numerous* cases of senders that *don't* set the field to 0 talking to receivers that *don't* ignore it. Of course the result is an interop problem. (As a result of these I've committed changes to several dissectors to dissect spare fields; in some cases I think Expert Infos are also raised.)