Hello Wireshark Developers,
When decoding SNMP messages in wireshark (using version 1.4.8 in my case), all "Octet String" values appear as hex strings in the GUI rather then being shown as human-readable strings.
On the mailing-list archive, I found
http://www.wireshark.org/lists/wireshark-users/201007/msg00021.html
which describes the problem, but I couldn't find an answer/resolution anywhere.
So after poking around the source code a bit, I found that
epan/dissectors/packet-snmp.c defines (on line 3283):
{ &hf_snmp_octetstring_value, { "Value (OctetString)", "snmp.value.octets", FT_BYTES, BASE_NONE, NULL, 0, NULL, HFILL }}
If I change this to treat OctetString as "STRING" field-type instead of "BYTES":
{ &hf_snmp_octetstring_value, { "Value (OctetString)", "snmp.value.octets", FT_STRING, BASE_NONE, NULL, 0, NULL, HFILL }}
it does show me the expected human-readable text in the GUI (and tshark).
If there are non-printable characters in the string, they are shows as backslash-escaped octal values, so doesn't behave badly at all.
SNMP only defines OctetString, which could be either binary or ASCII (printable) data, so I suspect Wireshark uses FT_BYTES as a "safe" option, just in case there is binary data in the field.
Since in most cases (at least in my experience) the SNMP Octet String is a human-readable string and non-printable characters are handled gracefully anyway (ie octal notation), I think it would be justified to redefine the OctetString as an FT_STRING field in packet-snmp.c.
Am I overlooking any good reason why FT_BYTES would be more appropriate? If not, could you please consider the change request for a future release?
thanks,
joost
