easysnmp does not translate the index part of the OID in textual form to numeric form

[tonusoo]

For example, an OID in textual form of ipAddressIfIndex.ipv6 has to translate to .1.3.6.1.2.1.4.34.1.3.2 in numerical form:

$ snmptranslate -m IP-MIB -IR -On ipAddressIfIndex.ipv6
.1.3.6.1.2.1.4.34.1.3.2
$ 

However, the easysnmp seems to ignore the index part altogether and replaces it with 0. For example, both session.walk("ipAddressIfIndex.ipv6") and session.walk(("ipAddressIfIndex", "ipv6")) or even an arbitrary session.walk(("ipAddressIfIndex", "abcde")) supply the OID of .1.3.6.1.2.1.4.34.1.3.0 with the GetNextRequest query. When I run my Python script using strace utility and look for open, openat and read system calls, then the InetAddressType definition in INET-ADDRESS-MIB is read. InetAddressType definition determines the numerical value of ipv6 .

Currently I set the index part numerically(for example, session.walk(("ipAddressIfIndex", 2))), but is there a reason why easysnmp does not translate the index part of the OID in textual form to numeric form?

I'm running easysnmp version 0.2.5 under Python 3.7.3. NET-SNMP version is 5.7.3.

[kamakazikamikaze]

Odd. I ran your queries and easysnmp returned an empty list, however a tcpdump capture shows a noError response with 10 variable bindings. I am very much rusty on my SNMP knowledge but I don't think those results should just be "discarded". Will definitely need to investigate further.

[kamakazikamikaze]

Looking at this today, it does indeed appear that we're requesting .1.3.6.1.2.1.4.34.1.3.0 instead of .1.3.6.1.2.1.4.34.1.3.2. Using GDB to print the members of pdu->variables on line 2954 of interface.c shows that we have a 0 instead of a 2.

Breaking on line 2854 shows that both tag and iid are parsed properly. However on lines 2861 and 2871, printing pdu->variables and oid_arr[varlist_ind] shows that we don't have children properly identified. So my current suspicion is that __tag2oid is not properly fetching child OID(s)