>>>>> Guy Harris writes:
Guy> Well, the current code should display the first of those as:
Guy> Object identifier 1: 1.3.6.1.2.1.2.2.1.7.1 (IF-MIB::ifAdminStatus.1)
Guy> Value: up(1)
Guy> I.e., it displays *both* the OID as a string of subids *and* as
Guy> Module:subid-within-module, and displays enumerated types both as
Guy> the enumerated value *and* the raw numeric value; this is similar
Guy> to what Ethereal (and at least some other dissectors) do for a
Guy> number of other fields that can be interpreted symbolically, i.e.
Guy> displays both the symbolic value and the raw numeric value.
Guy> The libsmi version would display the OID the same way, and would
Guy> display the value as
Guy> Value: INTEGER: up(1)
Guy> again showing both the symbolic and numeric value.
Guy> That's what I think is the correct way to handle this.
Showing everything in both formats works nice for enumerations. But
things will look a bit ugly and tend to be hard to read if you do the
same for string based types. If is also unclear whether you display
the type in the protocol or the type used in the MIB. And what happens
if the MIB says it is an enumerated integer, but the payload in your
packet contains say an IpAddress?
Guy> As for the "DateAndTime" and "KBytes" values, I don't see
Guy> anything in the MIB file that would tell Ethereal that they
Guy> should be displayed as anything other than a bunch of octets and
Guy> a number, respectively (there are comments, but those tell a
Guy> human bout the string) - how are you proposing to teach a
Guy> dissector about those definitions in the HOST-RESOURCES-MIB, and
Guy> the proper way to display variables of those types?
In libsmi terms, you check for a format/units string in the smiNode or
in the smiType (hierarchy) associated with the smiNode. This is what
the UCD folks are also doing, I think.
Another idea: Would it enhance readability if the name and value
output is well aligned, e.g. use
1. Name: 1.3.6.1.2.1.2.2.1.7.1 (IF-MIB::ifAdminStatus.1)
Type: INTEGER (Enumeration)
Value: 1 (up)
2. Name: 1.3.6.1.2.1.2.2.1.7.2 (IF-MIB::ifAdminStatus.2)
Type: INTEGER (Enumeration)
Value: 2 (down)
instead of
Object identifier 1: 1.3.6.1.2.1.2.2.1.7.1 (IF-MIB::ifAdminStatus.1)
Value: INTEGER: up(1)
Object identifier 1: 1.3.6.1.2.1.2.2.1.7.2 (IF-MIB::ifAdminStatus.2)
Value: INTEGER: up(2)
Note that this format shows the type contained in the SNMP message and
in addition the type from the MIB (if any).
I am experimenting with this myself - so these are just ideas to get a
discussion going on how to make the output easy to read. I am myself
not totally sure whether my ideas are good or bad. ;-)
/js
--
Juergen Schoenwaelder Technical University Braunschweig
<schoenw@xxxxxxxxxxxxxxx> Dept. Operating Systems & Computer Networks
Phone: +49 531 391 3289 Bueltenweg 74/75, 38106 Braunschweig, Germany
Fax: +49 531 391 5936 <URL:http://www.ibr.cs.tu-bs.de/~schoenw/>