#2702 Triple indexes of ALARM-MIB confuse mib.c:_add_strings_to_oid()

[Richard Perrin]

The valid OIDs .1.3.6.1.2.1.118.1.2.3.1.1.115 and greater cannot be parsed.

Reproduced in latest (5.7.3) on linux:

~/code/net-snmp-5.7.3 $ ./apps/snmptranslate -m +ALARM-MIB -M mibs:/var/lib/mibs/iana:/var/lib/mibs/ietf .1.3.6.1.2.1.118.1.2.3.1.1.114
ALARM-MIB::alarmActiveVariableIndex.114
~/code/net-snmp-5.7.3 $ ./apps/snmptranslate -m +ALARM-MIB -M mibs:/var/lib/mibs/iana:/var/lib/mibs/ietf .1.3.6.1.2.1.118.1.2.3.1.1.115
.1.3.6.1.2.1.118.1.2.3.1.1.115: Unknown Object Identifier (Index out of range: 115 (alarmListName))

The following ugly workaround fixes the issue:

--- ./snmplib/mib.c.orig    2016-03-23 16:32:27.343895083 -0400
+++ ./snmplib/mib.c 2016-03-23 16:32:30.927896535 -0400
@@ -5394,6 +5394,12 @@ _add_strings_to_oid(void *tp, char *cp,
         tp = NULL;
     }

+    /* Workaround for ALARM-MIB */
+    if (in_dices && strcmp(in_dices->ilabel, "alarmListName") == 0) {
+       if (in_dices->next)
+           in_dices = in_dices->next->next;
+    }
+
     while (cp && in_dices) {
         fcp = cp;

The source of the problem seems to be that "while (cp && tp && tp->child_list) {" loop resolves the objid array all the way down to "1.3.6.1.2.1.118.1.2.3.1.1.", leaving only "115" pointed to by cp. However, the in_dices list retrieved from the alarmActiveVariableEntry tree node contains the following:

(gdb) print *in_dices
$82 = {next = 0x6b41e0, ilabel = 0x6b2130 "alarmListName", isimplied = 0 '\000'}
(gdb) print *in_dices->next
$83 = {next = 0x6b45d0, ilabel = 0x6b0920 "alarmActiveIndex", isimplied = 0 '\000'}
(gdb) print *in_dices->next->next
$84 = {next = 0x0, ilabel = 0x6a2df0 "alarmActiveVariableIndex", isimplied = 0 '\000'}

This then fails the inappropriate *objidlen + len + 1 >= maxlen test under case TYPE_OCTETSTR, resulting in the error .1.3.6.1.2.1.118.1.2.3.1.1.115: Unknown Object Identifier (Index out of range: 115 (alarmListName))

[Bill Fenner]

The *objidlen + len + 1 >= maxlen test is correct. You can not have a string (alarmListName) of length 115, when you already have an oid that is 13 sub-identifiers long, because that exceeds the 128-sub-identifier limit on OIDs.

The INDEX of the alarmActiveVariableTable must always be <alarmListName length>.sub-identifiers of alarmListName.alarmActiveIndex.alarmActiveVariableIndex. You seem to want to just supply the alarmActiveVariableIndex, but that is not how the INDEX is specified.

[Bill Fenner]

Sorry, maybe this would be more clear with an example.

snmptranslate -IR -m +ALARM-MIB alarmActiveVariableIndex.5.104.101.108.108.111.42.115
-->
ALARM-MIB::alarmActiveVariableIndex."hello".42.115

i.e., we are translating 3 index values:
5.104.101.108.108.111 -> alarmListName="hello"
42 -> alarmActiveIndex=42
115 -> alarmActiveVariableIndex=115