[Graham Bloice <graham.bloice@xxxxxxxxxxxxx>]

On 27 February 2015 at 18:28, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:

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.)

How do we handle the case where a protocol has many reserved fields, do they each need an hf and a name?

--

Graham Bloice