Hi Bill,
Your point is valid, but I always had the impression that the iid always
comes down to the last numeric value in the complete OID. That way, just
based just on logic, we wouldn't require the MIB definitions to always get
the same behaviour just based on the OID.
Even on IP-MIB, where the entire IP could be considered to be the iid, that
does not happen, and the last IP octet is set as the iid:
$ snmpwalk -v 2c -c public -On myhost IP-MIB::ipAddressIfIndex.ipv4
.1.3.6.1.2.1.4.34.1.3.1.4.10.254.1.10 = INTEGER: 8
.1.3.6.1.2.1.4.34.1.3.1.4.10.254.1.255 = INTEGER: 8
.1.3.6.1.2.1.4.34.1.3.1.4.127.0.0.1 = INTEGER: 1
Executing the same script from the last e-mail, with debug enabled, this is
the relevant output:
netsnmp_walk: filling response: .1.3.6.1.2.1.4.34.1.3.1.4.10.254.1:10
netsnmp_walk: filling response: .1.3.6.1.2.1.4.34.1.3.1.4.10.254.1:255
netsnmp_walk: filling response: .1.3.6.1.2.1.4.34.1.3.1.4.127.0.0:1
So, if the iid is just the last number, why would it be merged with "tag"
at all (in other words, why would the iid be empty at all)? Wouldn't it
make sense, if the MIB isn't loaded, that if iid is empty, it should be
initialized with the last number from "tag" (and have it also removed from
"tag")?
I apologize if I'm going over some obvious topic. Please refer me to any
available documentation you know of, that could help me to make sense of it.
Best regards,
Eduardo Bragatto
On Tue, Oct 14, 2014 at 6:04 PM, Bill Fenner <fen...@gmail.com> wrote:
> On Mon, Oct 13, 2014 at 5:53 PM, Eduardo Bragatto <edua...@bragatto.com>
> wrote:
>
>> Hi,
>>
>> I just started experimenting with the Python bindings and I noticed a
>> behaviour that looks like a bug when I’m using snmpwalk().
>>
>> This is under Net-SNMP 5.5.2 on CentOS 6, 64 bits and python 2.7.
>>
>> First I’ll show an example of everything working as expected:
>>
>>
>> If I “walk” through an index, for example: IF-MIB::ifIndex
>>
>> — begins —
>> import netsnmp
>>
>> oid = netsnmp.VarList(netsnmp.Varbind('IF-MIB::ifIndex'))
>> s = netsnmp.Session(DestHost=‘myhost', Community=‘mycommunity', Version=2)
>> s.walk(oid)
>> — ends —
>>
>> I get the following output (debug enabled):
>>
>> $ python2.7 test.py
>> netsnmp_walk: filling request: IF-MIB::ifIndex::10:0
>> netsnmp_walk: filling response: ifIndex:1
>> netsnmp_walk: filling response: ifIndex:2
>> netsnmp_walk: filling response: ifIndex:3
>> netsnmp_walk: filling response: ifIndex:4
>> netsnmp_walk: filling response: ifIndex:5
>>
>> In that case, I get “tag” is the same for all returned OIDs, and “iid” is
>> incrementing. The same behaviour happens if I use “UseNumeric” and
>> “UseLongNames”:
>>
>> — begins —
>> import netsnmp
>>
>> oid = netsnmp.VarList(netsnmp.Varbind('IF-MIB::ifIndex'))
>> s = netsnmp.Session(DestHost=‘myhost', Community=‘mycommunity', Version=2)
>> s.UseLongNames = 1
>> s.UseNumeric = 1
>> s.walk(oid)
>> — ends —
>>
>> The output is:
>>
>> $ python2.7 test.py
>> netsnmp_walk: filling request: IF-MIB::ifIndex::10:0
>> netsnmp_walk: filling response: .1.3.6.1.2.1.2.2.1.1:1
>> netsnmp_walk: filling response: .1.3.6.1.2.1.2.2.1.1:2
>> netsnmp_walk: filling response: .1.3.6.1.2.1.2.2.1.1:3
>> netsnmp_walk: filling response: .1.3.6.1.2.1.2.2.1.1:4
>> netsnmp_walk: filling response: .1.3.6.1.2.1.2.2.1.1:5
>>
>>
>>
>> However, if instead of IF-MIB, I use Dell’s "MIB-Dell-10892” (without the
>> MIB actually being installed, using numeric OID), here’s what I get:
>>
>> First, without “UseLongNames” and “UseNumeric”:
>>
>> — begins —
>> import netsnmp
>>
>> oid =
>> netsnmp.VarList(netsnmp.Varbind('.1.3.6.1.4.1.674.10892.1.1100.30.1.1.1'))
>> s = netsnmp.Session(DestHost=‘myhost', Community=‘mycommunity', Version=2)
>> s.walk(oid)
>> — ends —
>>
>> Output:
>>
>> $ python2.7 test.py
>> netsnmp_walk: filling request:
>> .1.3.6.1.4.1.674.10892.1.1100.30.1.1.1::14:0
>> __get_type_str:FAILURE(0)
>> __get_type_str:FAILURE(0)
>> netsnmp_walk: filling response: enterprises.674.10892.1.1100.30.1.1.1.1:
>> __get_type_str:FAILURE(0)
>> __get_type_str:FAILURE(0)
>> netsnmp_walk: filling response: enterprises.674.10892.1.1100.30.1.1.1.2:
>>
>> Note that in this case, “tag” was merged with “iid” and “iid” was left
>> blank, however, if I use “UseNumeric” and “UseLongNames”, it works as
>> expected:
>>
>> — begins —
>> import netsnmp
>>
>> oid =
>> netsnmp.VarList(netsnmp.Varbind('.1.3.6.1.4.1.674.10892.1.1100.30.1.1.1'))
>> s = netsnmp.Session(DestHost=‘myhost', Community=‘mycommunity', Version=2)
>> s.UseLongNames = 1
>> s.UseNumeric = 1
>> s.walk(oid)
>> — ends —
>>
>> $ python2.7 test.py
>> netsnmp_walk: filling request:
>> .1.3.6.1.4.1.674.10892.1.1100.30.1.1.1::14:0
>> __get_type_str:FAILURE(0)
>> __get_type_str:FAILURE(0)
>> netsnmp_walk: filling response: .1.3.6.1.4.1.674.10892.1.1100.30.1.1.1:1
>> __get_type_str:FAILURE(0)
>> __get_type_str:FAILURE(0)
>> netsnmp_walk: filling response: .1.3.6.1.4.1.674.10892.1.1100.30.1.1.1:2
>>
>>
>> Has anyone else encountered this kind of behaviour? I’m willing to go
>> through the “client_intf.c” and try to fix this, but I’d like to hear from
>> people with a similar setup and/or more experience with the python bindings.
>>
>
> Without the MIB being loaded, how can you expect the manager to know what
> is the object and what is the iid? If anything, it sounds like it's a bug
> that the iid is filled in in any scenario without a MIB to support it.
>
> Bill
>
>
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
Net-snmp-users mailing list
Net-snmp-users@lists.sourceforge.net
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users
