Description of problem: Impossible to get counter64 value from agentx subagent with multi-oid snmpget. Version-Release number of selected component (if applicable): 5.3.2.2-17 - affected - 5.8 5.3.2.2-14 - affected - 5.7 How reproducible: create agentx application, register few counter64 counters with it. make query like a snmpget counter1 counter2 (2 counters within one query) Actual results: snmpd drops agentx subagent, no response to user. Expected results: actual counters values. Additional info: fix from [1] works for me. [1] http://www.mail-archive.com/net-snmp-users@lists.sourceforge.net/msg19301.html
Created attachment 580431 [details] subagent for reproducer Steps to reproduce: 1. compile attached subagent net-snmp-config --compile-subagent subagent subagent.c 2. enable agentx echo "master agentx" >> /etc/snmp/snmpd.conf 3. start everything service snmpd restart ./subagent -f -Lo 4. check the subagent works snmpwalk localhost 1.3.6.1.4.1.2021.1.1 5. reproduce the bug snmpget localhost UCD-SNMP-MIB::ucdavis.1.1.1.0 UCD-SNMP-MIB::ucdavis.1.1.3.0 UCD-SNMP-MIB::ucdavis.1.1.4.0 -> you should *not* get "Error in packet" or timeout but two 64bit numbers
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Previously, snmpd used wrong length of COUNTER64 values in AgentX protocol and therefore was not able to decode two consecutive COUNTER64 values in one AgentX packet. In this update, snmpd uses correct COUNTER64 size and can process two or mode COUNTER64 values in AgentX communication.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0124.html