Wireshark-bugs: [Wireshark-bugs] [Bug 4615] New: SNMP decoder no longer shows getNext response v
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4615
Summary: SNMP decoder no longer shows getNext response values
Product: Wireshark
Version: 1.3.x (Experimental)
Platform: x86
OS/Version: Fedora
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: fulko.hew@xxxxxxxxx
Build Information:
[root@localhost wireshark-1.3.3]# ./wireshark -v
wireshark 1.3.3
Copyright 1998-2010 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.12.8, with GLib 2.14.6, with libpcap 0.9-PRE-CVS, with
libz
1.2.3, with POSIX capabilities (Linux), without libpcre, without SMI, without
c-ares, without ADNS, without Lua, without Python, with GnuTLS 1.6.3, with
Gcrypt 1.2.4, with MIT Kerberos, without GeoIP, without PortAudio, without
AirPcap, with new_packet_list.
Running on Linux 2.6.26.8-57.fc8, with libpcap version 0.9-PRE-CVS, GnuTLS
1.6.3, Gcrypt 1.2.4.
Built using gcc 4.1.2 20070925 (Red Hat 4.1.2-33).
--
While investigating an issue using wireshark 1.0.3 I wanted to see if the
latest version exhibited the same behavior.
The original issue was: responses that containined empty OCTET STRINGS as their
values would be shown as "<MISSING>". This was misleading. The value was
present as an 'empty string'. If anything, the decoder should more correctly
display it as "<EMPTY>".
To see if this behavior had changed in a more recent version of Wireshark, I
built version 1.3.3 from source, and I read in the saved capture file
containing an SNMP walk, When looking at the fully expanded sub-trees of the
SNMP get_response packet it shows the 'Object Name' field but not the 'Value'
field.
Both the GUI and the exported text file is now missing this field.
Below is an extract of a sample packet decode dump:
Simple Network Management Protocol
version: version-1 (0)
community: public
data: get-response (2)
get-response
request-id: -1903097565
error-status: noError (0)
error-index: 0
variable-bindings: 1 item
1.3.6.1.2.1.1.1.0:
Object Name: 1.3.6.1.2.1.1.1.0 (iso.3.6.1.2.1.1.1.0)
NOTE: I was unable to test against a capture from version 1.3.3 because the
version (as built) reported:
dumpcap: There are no interfaces on which a capture can be done
...Probably because of the 'older (incompatible?) version of pcap' (from
wireshark v1.0.3 vintage) that is currently installed on my machine.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
