Re: Informing user of incomplete dissection

[Michael Mann <mmann78 () netscape net>]

DISSECTOR_ASSERT is definitely wrong, that's intended for detecting coding screw ups not for anything the wire 
generates.
 
You should always put all bytes in some sort of field so that the user has access to them.  Fieldname could be a clue, 
like my_dissector.undissected_bytes.
 
Expert info is probably the best way to go because it should color some fields of your protocol differently to make the 
user aware of the incomplete dissection.  There's even a specific expert info type, PI_UNDECODED to note such an 
occurrence (typically PI_WARN)
 
 
 
-----Original Message-----
From: Mike Morrin <morrinmike () gmail com>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Sent: Fri, Mar 4, 2016 7:55 pm
Subject: [Wireshark-dev] Informing user of incomplete dissection


    I have a dissector which does not yet dissect all of the possible    information elements of a protocol.
    
    What should the dissector do when it recognises that an IE cannot be    handled?
    
      
Ignoring the un-dissected octets leaves the user with a false        sense of believing the dissection was complete
      
DISSECTOR_ASSERT is much too invasive.
      
Expert info, would seem to be the best option, but I recall        that it was intended to be used for providing 
information about        the captured packets, rather than about dissector deficiencies.
    
    What is the generally accepted solution?
   
  
        
                
This email has been sent from a virus-free computer protected by Avast. 
www.avast.com           
        
 

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

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