#1268 Fix for error in object name/oid when inserted into the expObjectTable in the DISMAN-EXPRESSION-MIB implementation

backport-needed
closed
5
2015-01-31
2013-10-18
No

Net-SNMP Version: 5.7.2
Operating System: Linux hostname 3.2.0-38-generic-pae #61-Ubuntu SMP Tue Feb 19 12:39:51 UTC 2013 i686 i686 i386 GNU/Linux
Distribution: ubuntu 12.04 LTS

Problem Description

I came across the problem while I was trying out the following simple expression (using the DISMAN-EXPRESSION-MIB implementation of net-snmp in agent/mibgroup/disman/expr).

snmpset -uuser -Lo localhost DISMAN-EXPRESSION-MIB::expExpression.'"foo"'.'"bar"' = '$1+$2'

Where one of the objects was IF-MIB::ifInUcastPkts.1 as below:

snmpset -uuser -Lo localhost DISMAN-EXPRESSION-MIB::expObjectID.'"foo"'.'"bar"'.1 = ifInUcastPkts.1

When walking the object table, I noticed that there were lot of leading zeros with the object name, as below:

IF-MIB::ifInUcastPkts.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0

After examining the code I found that when an object is added to the expObjectTable, the length of the expObjectID field is set to a wrong value, i.e. it is set to length in bytes rather than "oids" (a locally defined data type). In the above case, the object (ifInUcastPkts.1) has OID 1.3.6.1.2.1.2.2.1.11.1 which is of length 11 but it is set to 44 instead (1 oid = 4 bytes).

The result is that later when the object is queried it returns no value which ultimately results in expression not being evaluated.

Solution

The length is set to the length in bytes divided by the size of oid data type (i.e. 4 bytes), i.e. the following

entry->expObjectID_len = request->requestvb->val_len;

is replaced with

entry->expObjectID_len = request->requestvb->val_len/sizeof(oid);
1 Attachments

Related

Patches: #1289

Discussion

  • Niels Baggesen

    Niels Baggesen - 2015-01-26

    Thanks for the patch! It has been applied to all active branches of Net-SNMP.

     
  • Niels Baggesen

    Niels Baggesen - 2015-01-26
    • status: open --> closed
    • assigned_to: Niels Baggesen
     

Log in to post a comment.