Re: Undissected reserved fields

[Jeff Morriss <jeff.morriss.ws () gmail com>]

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

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