Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 4615] New: SNMP decoder no longer shows getNext response v

Date: Thu, 25 Mar 2010 07:54:59 -0700 (PDT)
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.