On Tue, Oct 21, 2014 at 8:44 PM, Eduardo Bragatto <edua...@bragatto.com>
wrote:
> 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.
>
No, the IID is the INDEX, as defined in the tableEntry in the MIB.
> 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
>
That's a bug.
Bill
> 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
