pysnmp-users — PySNMP usage issues

[pysnmp-users] GETNEXT and maxRows

[Frédéric P. <fr...@fp...>]

Hi list,

It seems that nextCmd() always sends one request too many. IOW, with the
following:

>>> print cmdgen.CommandGenerator().nextCmd(
...     cmdgen.CommunityData("public"),
...     cmdgen.UdpTransportTarget(("192.168.100.240", 161)),
...     "1.3.6.1.2.1.1.4.0",
...     lexicographicMode = True,
...     maxRows = 1)
(None, Integer('noError'), Integer(0), [[(ObjectName(1.3.6.1.2.1.1.5.0),
OctetString('dut-1'))]])

Wireshark shows two GETNEXT being sent (and responded to), even though
only the first response is returned to me. I was expecting only one
request to be sent, as per maxRows.

Am I doing something wrong? Or is there an off-by-one somewhere in
pysnmp?

I'm running with python-pysnmp4 4.2.5-1 on Debian Sid.

Cheers,
-- 
Fred

[pysnmp-users] Agent for Complex MIB

[Houck, R. J. <rob...@sw...>]

Good day,

I have a MIB that we need to prove by creating an agent for. I have been scouring the mailing list and internet for a few days trying to make a working agent with pysnmp.

DISCLAIMER: This is my first time making an agent and using pysnmp.

I was originally going to use snmpsim to simulate the MIB but was unable to get mib2dev.py to work. After using smidump -f python MY-MIB.txt | libsmi2pysnmp > MY-MIB.py I kept getting a an error:


$ mib2dev.py --pysnmp-mib-dir="." --mib-module=MY-MIB

Traceback (most recent call last):

  File "/usr/local/bin/mib2dev.py", line 4, in <module>

    __import__('pkg_resources').run_script('snmpsim==0.2.4', 'mib2dev.py')

  File "build/bdist.macosx-10.10-x86_64/egg/pkg_resources/__init__.py", line 696, in run_script

  File "build/bdist.macosx-10.10-x86_64/egg/pkg_resources/__init__.py", line 1614, in run_script

  File "/usr/local/lib/python2.7/site-packages/snmpsim-0.2.4-py2.7.egg/EGG-INFO/scripts/mib2dev.py", line 240, in <module>

    [ builder.ZipMibSource(m).init() for m in mibDirs ]

  File "/Library/Python/2.7/site-packages/pysnmp-4.2.5-py2.7.egg/pysnmp/smi/builder.py", line 45, in init

  File "/Library/Python/2.7/site-packages/pysnmp-4.2.5-py2.7.egg/pysnmp/smi/builder.py", line 103, in _init

ValueError: Empty module name

As such, I am trying to build the MIB on my own. I made a copy of MY-MIB.py, named MY-AGENT.py and have been editing that file. I have a complex mib, which I do not see any examples of. I only seem to find examples of scalar only or table only examples. My mib has a good amount a scalars, two tables (with duel indexes), and notifications/traps.

I have been able to the a skeleton down but am still having issues.

First: I still have an issue with accessing the agent. From what I have gathered, the following should provide read/write access as needed:

# Set up access
config.addV1System(snmpEngine, 'agent', 'public') <- for internal testing, not worried about security at this point (would use v3 for that anyway)
config.addVacmUser(snmpEngine, 2, 'agent', 'noAuthNoPriv', readSubTree=(1, 3, 6, 1, 4, 1), writeSubTree=(1, 3, 6, 1, 4, 1))

When I do a snmpget, it returns the following:


snmpget -v2c -c public localhost 1.3.6.1.4.1.41192.1.1.1.1

Error in packet

Reason: noAccess

Failed object: SNMPv2-SMI::enterprises.41192.1.1.1.1

Second: How do I set the default values? I have seen two ways and am getting errors on both. The auto generated code from libsmi2pysnmp provided:

myOid = MibScalar((1, 3, 6, 1, 4, 1, 41192, 1, 1, 1, 1), DisplayString().subtype(subtypeSpec=ValueSizeConstraint(0, 24))).setMaxAccess("readonly")

How I'm trying to set and the errors I am getting:

mibInstrum.writeVars((1, 3, 6, 1, 4, 1, 41192, 1, 1, 1, 1), 'A string')

Traceback (most recent call last):

  File "VICTORY-SDR-AGENT.py", line 122, in <module>

    mibInstrum.writeVars((1, 3, 6, 1, 4, 1, 41192, 1, 1, 1, 1), 'My Radio ID')

  File "/Library/Python/2.7/site-packages/pysnmp-4.2.5-py2.7.egg/pysnmp/smi/instrum.py", line 247, in writeVars

  File "/Library/Python/2.7/site-packages/pysnmp-4.2.5-py2.7.egg/pysnmp/smi/instrum.py", line 184, in flipFlopFsm

  File "/Library/Python/2.7/site-packages/pysnmp-4.2.5-py2.7.egg/pysnmp/smi/instrum.py", line 140, in __indexMib

  File "<string>", line 244, in registerSubtrees

pysnmp.smi.error.SmiError: MIB subtree (1, 3, 6, 1, 6, 3, 10, 2, 1, 4, 0) already registered at MibScalar((1, 3, 6, 1, 6, 3, 10, 2, 1, 4), Integer32())


MibScalarInstance((1, 3, 6, 1, 4, 1, 41192, 1, 1, 1, 1), "A string")

Traceback (most recent call last):

  File "VICTORY-SDR-AGENT.py", line 337, in <module>

    setDefaults()

  File "VICTORY-SDR-AGENT.py", line 40, in setDefaults

    MibScalarInstance((1, 3, 6, 1, 4, 1, 41192, 1, 1, 1, 1), "A string")

TypeError: __init__() takes exactly 4 arguments (3 given)

For the MibScalarInstance, it am not sure why it is asking for another argument. Your documentation only has two.

Any help would be appreciated.

Thank you,

Robert Houck
Analyst
Southwest Research Institute
210 522 3615
rob...@sw...

Re: [pysnmp-users] bulkCmd walking up the tree

[Ilya E. <il...@gl...>]

I concur, but consider trying out the latest development pysnmp code — it attempts to strip excessive OIDs from returned var-bindings table:

http://pysnmp.cvs.sourceforge.net/viewvc/pysnmp/pysnmp/?view=tar

The only problem so far is that it takes a N*M loop (worst case) over var-binds table for that. But that still can be improved with a less clumsy algorithm.

Anyway, please, let me know in case of any issues with this code:

-ilya

> On 01 Jan 2015, at 08:50, Craig Small <cs...@en...> wrote:
> 
> On Wed, Dec 31, 2014 at 01:15:30PM -0500, Dennis Olvany wrote:
>>   My expectation is that results will be confined to 1.3.6.1.2.1.2.2.1.2.x
>>   and 1.3.6.1.2.1.2.2.1.3.x. What I get includes much more, as if pysnmp is
>>   walking up and back down other branches of IF-MIB. It doesn't seem right
>>   that this behavior would be by design.
> This is actually pretty standard SNMP behaviour.  Generally the caller
> will need to check that what is being returned is under the requested
> OID.
> 
> - Craig

Re: [pysnmp-users] bulkCmd walking up the tree

[Craig S. <cs...@en...>]

On Wed, Dec 31, 2014 at 01:15:30PM -0500, Dennis Olvany wrote:
>    My expectation is that results will be confined to 1.3.6.1.2.1.2.2.1.2.x
>    and 1.3.6.1.2.1.2.2.1.3.x. What I get includes much more, as if pysnmp is
>    walking up and back down other branches of IF-MIB. It doesn't seem right
>    that this behavior would be by design.
This is actually pretty standard SNMP behaviour.  Generally the caller
will need to check that what is being returned is under the requested
OID.

 - Craig

-- 
Craig Small (@smallsees)   http://enc.com.au/       csmall at : enc.com.au
Debian GNU/Linux           http://www.debian.org/   csmall at : debian.org
GPG fingerprint:        5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

[pysnmp-users] bulkCmd walking up the tree

[Dennis O. <den...@gm...>]

I am having quite a difficult time fetching the intended data with pysnmp.
I would like to enumerate all of the interface names on a device. I am
using the script from
http://pysnmp.sourceforge.net/examples/current/v3arch/oneliner/manager/cmdgen/getbulk-v2c.html,
modifying only the target as follows.


from pysnmp.entity.rfc3413.oneliner import cmdgen

cmdGen = cmdgen.CommandGenerator()

errorIndication, errorStatus, errorIndex, varBindTable = cmdGen.bulkCmd(
    cmdgen.CommunityData('public'),
    cmdgen.UdpTransportTarget(('10.0.1.1', 161)),
    0, 25,
    '1.3.6.1.2.1.2.2.1.2',
    '1.3.6.1.2.1.2.2.1.3',
)

if errorIndication:
    print(errorIndication)
else:
    if errorStatus:
        print('%s at %s' % (
            errorStatus.prettyPrint(),
            errorIndex and varBindTable[-1][int(errorIndex)-1] or '?'
            )
        )
    else:
        for varBindTableRow in varBindTable:
            for name, val in varBindTableRow:
                print('%s = %s' % (name.prettyPrint(), val.prettyPrint()))


My expectation is that results will be confined to 1.3.6.1.2.1.2.2.1.2.x
and 1.3.6.1.2.1.2.2.1.3.x. What I get includes much more, as if pysnmp is
walking up and back down other branches of IF-MIB. It doesn't seem right
that this behavior would be by design.


PS H:\> python C:\Users\dolvany\Desktop\snmp.py
1.3.6.1.2.1.2.2.1.2.1 = b'mgi0'
1.3.6.1.2.1.2.2.1.3.1 = 6
1.3.6.1.2.1.2.2.1.2.2 = b'mgi1'
1.3.6.1.2.1.2.2.1.3.2 = 6
1.3.6.1.2.1.2.2.1.2.3 = b'mv0'
1.3.6.1.2.1.2.2.1.3.3 = 71
1.3.6.1.2.1.2.2.1.2.4 = b'mv1'
1.3.6.1.2.1.2.2.1.3.4 = 71
1.3.6.1.2.1.2.2.1.2.5 = b'lo0'
1.3.6.1.2.1.2.2.1.3.5 = 24
1.3.6.1.2.1.2.2.1.2.6 = b'wlan0'
1.3.6.1.2.1.2.2.1.3.6 = 6
1.3.6.1.2.1.2.2.1.2.7 = b'wlan1'
1.3.6.1.2.1.2.2.1.3.7 = 6
1.3.6.1.2.1.2.2.1.2.8 = b'bridge0'
1.3.6.1.2.1.2.2.1.3.8 = 209
1.3.6.1.2.1.2.2.1.2.9 = b'stf0'
1.3.6.1.2.1.2.2.1.3.9 = 215
1.3.6.1.2.1.2.2.1.3.1 = 6
1.3.6.1.2.1.2.2.1.4.1 = 1500
1.3.6.1.2.1.2.2.1.3.2 = 6
1.3.6.1.2.1.2.2.1.4.2 = 1500
1.3.6.1.2.1.2.2.1.3.3 = 71
1.3.6.1.2.1.2.2.1.4.3 = 2290
1.3.6.1.2.1.2.2.1.3.4 = 71
1.3.6.1.2.1.2.2.1.4.4 = 2290
1.3.6.1.2.1.2.2.1.3.5 = 24
1.3.6.1.2.1.2.2.1.4.5 = 33172
1.3.6.1.2.1.2.2.1.3.6 = 6
1.3.6.1.2.1.2.2.1.4.6 = 1500
1.3.6.1.2.1.2.2.1.3.7 = 6
1.3.6.1.2.1.2.2.1.4.7 = 1500
1.3.6.1.2.1.2.2.1.3.8 = 209
1.3.6.1.2.1.2.2.1.4.8 = 1500
1.3.6.1.2.1.2.2.1.3.9 = 215
1.3.6.1.2.1.2.2.1.4.9 = 1280
1.3.6.1.2.1.2.2.1.4.1 = 1500
1.3.6.1.2.1.2.2.1.5.1 = 10000000
1.3.6.1.2.1.2.2.1.4.2 = 1500
1.3.6.1.2.1.2.2.1.5.2 = 10000000
1.3.6.1.2.1.2.2.1.4.3 = 2290
1.3.6.1.2.1.2.2.1.5.3 = 300000000
1.3.6.1.2.1.2.2.1.4.4 = 2290
1.3.6.1.2.1.2.2.1.5.4 = 300000000
1.3.6.1.2.1.2.2.1.4.5 = 33172
1.3.6.1.2.1.2.2.1.5.5 = 0
1.3.6.1.2.1.2.2.1.4.6 = 1500
1.3.6.1.2.1.2.2.1.5.6 = 300000000
1.3.6.1.2.1.2.2.1.4.7 = 1500
1.3.6.1.2.1.2.2.1.5.7 = 300000000
PS H:\>

Re: [pysnmp-users] [PySNMP] tutorial for a newbie

[Ilya E. <il...@gl...>]

Hi Russo,

Have you taken a look at the tutorial at pysnmp web site:

http://pysnmp.sourceforge.net/docs/current/index.html

Then I’d suggest looking at high-level examples:

http://pysnmp.sourceforge.net/examples/current/v3arch/oneliner/manager/cmdgen/get-v2c.html

There’s also a few books on the subject, for instance:

http://www.amazon.com/SNMP-SNMPv2-SNMPv3-RMON-Edition/dp/0201485346/ref=pd_sim_b_3?ie=UTF8&refRID=1S8RT6QBVPE8GESY25SJ

-ilya

> On 13 Nov 2014, at 23:08, Russo <aru...@mu...> wrote:
> 
> Hi,
> 
> I have to prepare a project for SNMP, the idea is implement a very basic 
> SNMP manager. I decide to make it in python with the py-snmp library.
> 
> I'm just starting to understand SNMP and of course Py-SNMP, I would like 
> to know how do think could be a start point. Could you recomend a good 
> tutorial for SNMP and Py-SNMP?.
> 
> 
> Regards
> Russo

[pysnmp-users] [PySNMP] tutorial for a newbie

[Russo <aru...@mu...>]

Hi,

I have to prepare a project for SNMP, the idea is implement a very basic 
SNMP manager. I decide to make it in python with the py-snmp library.

I'm just starting to understand SNMP and of course Py-SNMP, I would like 
to know how do think could be a start point. Could you recomend a good 
tutorial for SNMP and Py-SNMP?.


Regards
Russo

[pysnmp-users] Comments in datafiles

[Simon C. <sim...@gm...>]

Hi Ilya,

I have implemented a change that allows us to put comment lines and blank
lines in snmprec datafiles, effectively ignoring them.

I notice this was on the feature list. Do you have any idea when this will
be?

It is so useful being able to comment datafiles to give an explanation of
what that OID is for.

Thanks,

Simon.

Re: [pysnmp-users] bulkCmd Results Overrun OID

[Craig S. <cs...@en...>]

On Wed, Sep 24, 2014 at 10:37:01AM +0400, Ilya Etingof wrote:
>    Alternatively, you may try to pass maxRows=147 parameter to bulkCmd to
>    make sure you are getting the exact number of OIDs. That is not a
>    generally save practice as average Agent may add or remove some OIDs over
>    time.
You can also go through each line and do something like
  request_oid.is_prefix_of(return_oid)

-- 
Craig Small (@smallsees)   http://enc.com.au/       csmall at : enc.com.au
Debian GNU/Linux           http://www.debian.org/   csmall at : debian.org
GPG fingerprint:        5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Re: [pysnmp-users] bulkCmd Results Overrun OID

[Ilya E. <il...@gl...>]

Hi Jacob,

Try the latest pysnmp (download latest CVS snapshot), there were some fixes in this respect.

In general, when you ask SNMP Agent to send you response OIDs in 200-OIDs chunk, it is very likely that excessive OIDs will arrive to your end. I think that the latest pysnmp tries to filter them out before returning the whole response to the caller.

Alternatively, you may try to pass maxRows=147 parameter to bulkCmd to make sure you are getting the exact number of OIDs. That is not a generally save practice as average Agent may add or remove some OIDs over time.

-ilya

On 23 Sep 2014, at 23:25, Jacob Uecker <ja...@ju...> wrote:

> Hi,
> 
> I'm having a problem with bulkCmd. I'm trying to gather what I know to be 147 rows but my results appear to flow into the next OID. This is true no matter which OID I use. 
> 
> Here is my code:
> 
> ---------
> 
> from pysnmp.entity.rfc3413.oneliner import cmdgen
> 
> cmdGen = cmdgen.CommandGenerator()
> 
> errorIndication, errorStatus, errorIndex, varBindTable = cmdGen.bulkCmd(
>     cmdgen.CommunityData('public'),
>     cmdgen.UdpTransportTarget(('10.0.1.207', 161)), 0, 200,
>     '1.3.6.1.4.1.14179.2.2.1.1.3'
> )
> 
> # Check for errors and print out results
> if errorIndication:
>     print(errorIndication)
> elif errorStatus:
>     print(errorStatus)
> else:
>     for varBindTableRow in varBindTable:
>         for name, val in varBindTableRow:
> 			print('%s = %s' % (name.prettyPrint(), val.prettyPrint()))
> 
> ---------
> 
> Here are the results. Notice that the results flow into 1.3.6.1.4.1.14179.2.2.1.1.4 
> 
> 1.3.6.1.4.1.14179.2.2.1.1.3.12.104.3.50.3.96 = NYN-POL-003
> 1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.56.78.80 = NYN-CHI-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.191.105.0 = NYN-NFI-003
> 1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.191.105.32 = NYN-GAL-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.191.130.208 = NYN-HIL-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.191.231.0 = NYN-CAS-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.236.30.80 = NYN-CHI-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.236.30.160 = NYN-CAS-021
> 1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.236.46.192 = NYN-NFI-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.16.189.24.109.234.224 = NYN-SPA-004
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.140.7.160 = NYN-VIP-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.178.207.176 = NYN-ZUM-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.178.231.112 = NYN-ARC-007
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.178.233.128 = FEST-AP-80
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.179.144.32 = NYN-5MR-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.179.145.112 = NYN-5MR-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.179.183.96 = MOB-MEDIA-AP-2
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.179.185.176 = NYN-NFI-004
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.2.192 = NYN-REG-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.11.160 = NYN-FCA-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.16.32 = NYN-GAL-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.18.16 = NYN-IFR-003
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.31.32 = NYN-MEZ-005
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.43.240 = NYN-ARC-003
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.73.64 = MOB-MEDIA-AP-1
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.149.176 = NYN-HIL-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.194.176 = NYN-ZUM-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.199.208 = NYN-SPA-005
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.240.96 = NYN-4MR-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.241.240 = NYN-STAR-1-1
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.1.192 = NYN-NFI-005
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.17.192 = NYN-ARC-004
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.104.192 = NYN-3MR-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.123.192 = NYN-SPA-003
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.148.192 = NYN-SHG-008
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.151.160 = NYN-3MR-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.158.144 = NYN-SHG-007
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.164.64 = NYN-SHG-006
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.164.112 = NYN-REG-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.164.208 = NYN-SHG-009
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.169.0 = NYN-GAL-003
> 1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.182.0 = NYN-CAS-011
> 1.3.6.1.4.1.14179.2.2.1.1.3.68.173.217.6.188.32 = NYN-SIM-007
> 1.3.6.1.4.1.14179.2.2.1.1.3.68.173.217.6.190.80 = NYN-CAS-009
> 1.3.6.1.4.1.14179.2.2.1.1.3.68.173.217.6.198.80 = NYN-NFI-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.68.173.217.7.129.192 = NYN-MR2-005
> 1.3.6.1.4.1.14179.2.2.1.1.3.68.173.217.7.202.128 = NYN-CAS-015
> 1.3.6.1.4.1.14179.2.2.1.1.3.92.164.138.214.229.224 = NYN-EXTE-1-5
> 1.3.6.1.4.1.14179.2.2.1.1.3.112.16.92.30.229.48 = NYN-NFI-006
> 1.3.6.1.4.1.14179.2.2.1.1.3.136.117.86.20.163.224 = NYN-CHI-003
> 1.3.6.1.4.1.14179.2.2.1.1.3.136.117.86.20.165.240 = NYN-CAU-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.136.117.86.20.213.0 = NYN-CAU-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.136.117.86.20.217.160 = NYN-ARC-006
> 1.3.6.1.4.1.14179.2.2.1.1.3.136.117.86.21.28.80 = NYN-ARC-005
> 1.3.6.1.4.1.14179.2.2.1.1.3.136.117.86.76.242.80 = MOB-MEDIA-AP-3
> 1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.57.48 = NYN-EXTE-1-1
> 1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.60.192 = NYN-EXTE-1-13
> 1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.61.144 = NYN-EXTE-1-3
> 1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.65.16 = NYN-EXTE-1-15
> 1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.65.240 = NYN-EXTE-1-6
> 1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.72.128 = NYN-EXTE-1-2
> 1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.118.160 = NYN-EXTE-1-8
> 1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.119.144 = NYN-EXTE-1-7
> 1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.119.224 = NYN-EXTE-1-4
> 1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.120.208 = NYN-EXTE-1-9
> 1.3.6.1.4.1.14179.2.2.1.1.3.208.199.137.103.122.112 = FEST-AP-62
> 1.3.6.1.4.1.14179.2.2.1.1.3.236.225.169.107.105.80 = FEST-AP-75
> 1.3.6.1.4.1.14179.2.2.1.1.3.240.37.114.60.60.240 = SingleDigits-RemoteAP
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.30.42.80 = NYN-MR2-010
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.30.58.64 = NYN-FOD-010
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.30.68.176 = NYN-FOD-003
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.136.128 = NYN-AMR-005
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.148.160 = NYN-MR2-008
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.154.16 = NYN-IFR-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.157.176 = NYN-MEZ-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.159.16 = NYN-MR2-012
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.177.16 = NYN-AMR-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.211.240 = NYN-CAS-029
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.225.176 = NYN-CAS-027
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.167.76.0 = NYN-POL-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.167.205.192 = NYN-POL-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.1.96 = NYN-CAS-013
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.2.192 = NYN-CAS-007
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.12.0 = NYN-AMR-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.14.0 = NYN-FOD-006
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.36.96 = NYN-MR2-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.40.160 = NYN-MEZ-004
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.48.192 = NYN-MR2-006
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.49.160 = NYN-MR2-004
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.64.64 = NYN-CAS-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.74.176 = NYN-MR2-007
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.100.64 = NYN-CAS-012
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.114.48 = NYN-CAS-016
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.122.224 = NYN-MR2-009
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.157.112 = NYN-CAS-003
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.171.240 = NYN-CAS-018
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.91.192 = NYN-ARC-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.91.224 = NYN-MR2-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.91.240 = NYN-MEZ-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.92.16 = NYN-CAS-023
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.92.80 = NYN-MR2-016
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.92.112 = NYN-FOD-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.93.112 = NYN-MEZ-003
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.94.176 = NYN-IFR-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.95.0 = NYN-FOD-007
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.95.16 = NYN-FOD-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.95.160 = NYN-MR2-015
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.96.16 = NYN-SIM-004
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.98.96 = NYN-SIM-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.98.192 = NYN-SPA-002
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.98.224 = NYN-FOD-004
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.99.0 = NYN-SIM-005
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.99.64 = NYN-ARC-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.99.224 = NYN-SIM-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.100.208 = NYN-MR2-014
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.101.144 = NYN-FOD-009
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.101.160 = NYN-FOD-005
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.103.0 = NYN-CAS-020
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.103.112 = NYN-CAS-022
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.109.208 = NYN-FOD-008
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.116.64 = NYN-CAS-008
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.116.128 = NYN-CAS-019
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.117.64 = NYN-SPA-001
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.121.128 = NYN-CAS-030
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.121.144 = NYN-CAS-010
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.121.176 = NYN-CAS-025
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.121.192 = NYN-CAS-006
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.121.240 = NYN-CAS-014
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.122.32 = NYN-CAS-024
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.122.48 = NYN-CAS-005
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.123.64 = NYN-FOD-011
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.123.112 = NYN-AMR-004
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.123.176 = NYN-CAS-028
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.124.80 = NYN-CAS-026
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.124.208 = NYN-CAS-004
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.124.224 = NYN-AMR-003
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.130.64 = NYN-ARC-008
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.131.48 = NYN-SIM-006
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.131.64 = NYN-MR2-013
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.131.176 = NYN-SIM-003
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.131.192 = NYN-MR2-018
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.132.16 = NYN-MR2-017
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.133.0 = NYN-CAS-017
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.133.96 = NYN-FOD-012
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.133.144 = NYN-MR2-011
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.135.0 = NYN-MR2-003
> 1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.135.112 = NYN-MR2-019
> 1.3.6.1.4.1.14179.2.2.1.1.4.12.104.3.50.3.96 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.56.78.80 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.191.105.0 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.191.105.32 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.191.130.208 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.191.231.0 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.236.30.80 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.236.30.160 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.236.46.192 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.16.189.24.109.234.224 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.140.7.160 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.178.207.176 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.178.231.112 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.178.233.128 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.179.144.32 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.179.145.112 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.179.183.96 = Media Shift Offices
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.179.185.176 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.2.192 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.11.160 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.16.32 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.18.16 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.31.32 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.43.240 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.73.64 = Media Shift Offices
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.149.176 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.194.176 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.199.208 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.240.96 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.241.240 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.1.192 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.17.192 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.104.192 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.123.192 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.148.192 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.151.160 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.158.144 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.164.64 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.164.112 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.164.208 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.169.0 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.182.0 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.68.173.217.6.188.32 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.68.173.217.6.190.80 = default location
> 1.3.6.1.4.1.14179.2.2.1.1.4.68.173.217.6.198.80 = default location
> 
> 

[pysnmp-users] bulkCmd Results Overrun OID

[Jacob U. <ja...@ju...>]

Hi,

I'm having a problem with bulkCmd. I'm trying to gather what I know to be
147 rows but my results appear to flow into the next OID. This is true no
matter which OID I use.

Here is my code:

---------

from pysnmp.entity.rfc3413.oneliner import cmdgen

cmdGen = cmdgen.CommandGenerator()

errorIndication, errorStatus, errorIndex, varBindTable = cmdGen.bulkCmd(
    cmdgen.CommunityData('public'),
    cmdgen.UdpTransportTarget(('10.0.1.207', 161)), 0, 200,
    '1.3.6.1.4.1.14179.2.2.1.1.3'
)

# Check for errors and print out results
if errorIndication:
    print(errorIndication)
elif errorStatus:
    print(errorStatus)
else:
    for varBindTableRow in varBindTable:
        for name, val in varBindTableRow:
print('%s = %s' % (name.prettyPrint(), val.prettyPrint()))

---------

Here are the results. Notice that the results flow into
1.3.6.1.4.1.14179.2.2.1.1.4

1.3.6.1.4.1.14179.2.2.1.1.3.12.104.3.50.3.96 = NYN-POL-003
1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.56.78.80 = NYN-CHI-001
1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.191.105.0 = NYN-NFI-003
1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.191.105.32 = NYN-GAL-002
1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.191.130.208 = NYN-HIL-001
1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.191.231.0 = NYN-CAS-001
1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.236.30.80 = NYN-CHI-002
1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.236.30.160 = NYN-CAS-021
1.3.6.1.4.1.14179.2.2.1.1.3.12.217.150.236.46.192 = NYN-NFI-002
1.3.6.1.4.1.14179.2.2.1.1.3.16.189.24.109.234.224 = NYN-SPA-004
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.140.7.160 = NYN-VIP-001
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.178.207.176 = NYN-ZUM-002
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.178.231.112 = NYN-ARC-007
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.178.233.128 = FEST-AP-80
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.179.144.32 = NYN-5MR-002
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.179.145.112 = NYN-5MR-001
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.179.183.96 = MOB-MEDIA-AP-2
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.179.185.176 = NYN-NFI-004
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.2.192 = NYN-REG-002
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.11.160 = NYN-FCA-001
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.16.32 = NYN-GAL-001
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.18.16 = NYN-IFR-003
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.31.32 = NYN-MEZ-005
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.43.240 = NYN-ARC-003
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.73.64 = MOB-MEDIA-AP-1
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.149.176 = NYN-HIL-002
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.194.176 = NYN-ZUM-001
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.199.208 = NYN-SPA-005
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.240.96 = NYN-4MR-001
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.226.241.240 = NYN-STAR-1-1
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.1.192 = NYN-NFI-005
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.17.192 = NYN-ARC-004
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.104.192 = NYN-3MR-002
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.123.192 = NYN-SPA-003
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.148.192 = NYN-SHG-008
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.151.160 = NYN-3MR-001
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.158.144 = NYN-SHG-007
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.164.64 = NYN-SHG-006
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.164.112 = NYN-REG-001
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.164.208 = NYN-SHG-009
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.169.0 = NYN-GAL-003
1.3.6.1.4.1.14179.2.2.1.1.3.52.189.200.227.182.0 = NYN-CAS-011
1.3.6.1.4.1.14179.2.2.1.1.3.68.173.217.6.188.32 = NYN-SIM-007
1.3.6.1.4.1.14179.2.2.1.1.3.68.173.217.6.190.80 = NYN-CAS-009
1.3.6.1.4.1.14179.2.2.1.1.3.68.173.217.6.198.80 = NYN-NFI-001
1.3.6.1.4.1.14179.2.2.1.1.3.68.173.217.7.129.192 = NYN-MR2-005
1.3.6.1.4.1.14179.2.2.1.1.3.68.173.217.7.202.128 = NYN-CAS-015
1.3.6.1.4.1.14179.2.2.1.1.3.92.164.138.214.229.224 = NYN-EXTE-1-5
1.3.6.1.4.1.14179.2.2.1.1.3.112.16.92.30.229.48 = NYN-NFI-006
1.3.6.1.4.1.14179.2.2.1.1.3.136.117.86.20.163.224 = NYN-CHI-003
1.3.6.1.4.1.14179.2.2.1.1.3.136.117.86.20.165.240 = NYN-CAU-002
1.3.6.1.4.1.14179.2.2.1.1.3.136.117.86.20.213.0 = NYN-CAU-001
1.3.6.1.4.1.14179.2.2.1.1.3.136.117.86.20.217.160 = NYN-ARC-006
1.3.6.1.4.1.14179.2.2.1.1.3.136.117.86.21.28.80 = NYN-ARC-005
1.3.6.1.4.1.14179.2.2.1.1.3.136.117.86.76.242.80 = MOB-MEDIA-AP-3
1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.57.48 = NYN-EXTE-1-1
1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.60.192 = NYN-EXTE-1-13
1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.61.144 = NYN-EXTE-1-3
1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.65.16 = NYN-EXTE-1-15
1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.65.240 = NYN-EXTE-1-6
1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.72.128 = NYN-EXTE-1-2
1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.118.160 = NYN-EXTE-1-8
1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.119.144 = NYN-EXTE-1-7
1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.119.224 = NYN-EXTE-1-4
1.3.6.1.4.1.14179.2.2.1.1.3.192.123.188.47.120.208 = NYN-EXTE-1-9
1.3.6.1.4.1.14179.2.2.1.1.3.208.199.137.103.122.112 = FEST-AP-62
1.3.6.1.4.1.14179.2.2.1.1.3.236.225.169.107.105.80 = FEST-AP-75
1.3.6.1.4.1.14179.2.2.1.1.3.240.37.114.60.60.240 = SingleDigits-RemoteAP
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.30.42.80 = NYN-MR2-010
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.30.58.64 = NYN-FOD-010
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.30.68.176 = NYN-FOD-003
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.136.128 = NYN-AMR-005
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.148.160 = NYN-MR2-008
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.154.16 = NYN-IFR-002
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.157.176 = NYN-MEZ-002
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.159.16 = NYN-MR2-012
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.177.16 = NYN-AMR-002
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.211.240 = NYN-CAS-029
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.31.225.176 = NYN-CAS-027
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.167.76.0 = NYN-POL-001
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.167.205.192 = NYN-POL-002
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.1.96 = NYN-CAS-013
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.2.192 = NYN-CAS-007
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.12.0 = NYN-AMR-001
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.14.0 = NYN-FOD-006
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.36.96 = NYN-MR2-002
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.40.160 = NYN-MEZ-004
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.48.192 = NYN-MR2-006
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.49.160 = NYN-MR2-004
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.64.64 = NYN-CAS-002
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.74.176 = NYN-MR2-007
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.100.64 = NYN-CAS-012
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.114.48 = NYN-CAS-016
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.122.224 = NYN-MR2-009
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.157.112 = NYN-CAS-003
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.182.171.240 = NYN-CAS-018
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.91.192 = NYN-ARC-002
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.91.224 = NYN-MR2-001
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.91.240 = NYN-MEZ-001
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.92.16 = NYN-CAS-023
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.92.80 = NYN-MR2-016
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.92.112 = NYN-FOD-002
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.93.112 = NYN-MEZ-003
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.94.176 = NYN-IFR-001
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.95.0 = NYN-FOD-007
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.95.16 = NYN-FOD-001
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.95.160 = NYN-MR2-015
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.96.16 = NYN-SIM-004
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.98.96 = NYN-SIM-002
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.98.192 = NYN-SPA-002
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.98.224 = NYN-FOD-004
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.99.0 = NYN-SIM-005
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.99.64 = NYN-ARC-001
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.99.224 = NYN-SIM-001
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.100.208 = NYN-MR2-014
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.101.144 = NYN-FOD-009
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.101.160 = NYN-FOD-005
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.103.0 = NYN-CAS-020
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.103.112 = NYN-CAS-022
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.109.208 = NYN-FOD-008
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.116.64 = NYN-CAS-008
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.116.128 = NYN-CAS-019
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.117.64 = NYN-SPA-001
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.121.128 = NYN-CAS-030
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.121.144 = NYN-CAS-010
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.121.176 = NYN-CAS-025
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.121.192 = NYN-CAS-006
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.121.240 = NYN-CAS-014
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.122.32 = NYN-CAS-024
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.122.48 = NYN-CAS-005
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.123.64 = NYN-FOD-011
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.123.112 = NYN-AMR-004
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.123.176 = NYN-CAS-028
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.124.80 = NYN-CAS-026
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.124.208 = NYN-CAS-004
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.124.224 = NYN-AMR-003
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.130.64 = NYN-ARC-008
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.131.48 = NYN-SIM-006
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.131.64 = NYN-MR2-013
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.131.176 = NYN-SIM-003
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.131.192 = NYN-MR2-018
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.132.16 = NYN-MR2-017
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.133.0 = NYN-CAS-017
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.133.96 = NYN-FOD-012
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.133.144 = NYN-MR2-011
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.135.0 = NYN-MR2-003
1.3.6.1.4.1.14179.2.2.1.1.3.244.31.194.183.135.112 = NYN-MR2-019
1.3.6.1.4.1.14179.2.2.1.1.4.12.104.3.50.3.96 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.56.78.80 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.191.105.0 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.191.105.32 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.191.130.208 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.191.231.0 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.236.30.80 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.236.30.160 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.12.217.150.236.46.192 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.16.189.24.109.234.224 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.140.7.160 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.178.207.176 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.178.231.112 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.178.233.128 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.179.144.32 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.179.145.112 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.179.183.96 = Media Shift Offices
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.179.185.176 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.2.192 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.11.160 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.16.32 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.18.16 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.31.32 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.43.240 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.73.64 = Media Shift Offices
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.149.176 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.194.176 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.199.208 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.240.96 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.226.241.240 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.1.192 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.17.192 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.104.192 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.123.192 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.148.192 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.151.160 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.158.144 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.164.64 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.164.112 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.164.208 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.169.0 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.52.189.200.227.182.0 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.68.173.217.6.188.32 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.68.173.217.6.190.80 = default location
1.3.6.1.4.1.14179.2.2.1.1.4.68.173.217.6.198.80 = default location

Re: [pysnmp-users] Inconsistent responses between API's/versions

[Ilya E. <il...@gl...>]

Hi Adam,

Use lexicographicMode=True and maxRows=1 options to bulkCmd() to allow bulkCmd() walking past initial OID prefix and terminate once at least a single response OID per each request OID is received:

errorIndication, errorStatus, errorIndex, varBindTable = cmdGen.bulkCmd(
    cmdgen.CommunityData('public'),
    cmdgen.UdpTransportTarget(('195.218.195.228', 161)),
    5, 0,
    '1.3.6.1.2.1.1.1.0',
    '1.3.6.1.2.1.1.7.0',
    '1.3.6.1.2.1.2.2.1.1.2',
    '1.3.6.1.2.1.2.2.1.3.2',
    '1.3.6.1.2.1.2.2.1.11.1',
    lexicographicMode=True,
    maxRows=1
)

What exactly appears incompatible with CVS code? My tests do not reveal that so far. The new code was designed with API-level backward compatibility in mind.

Thanks,
ilya


On 14 Sep 2014, at 19:41, Adam Bishop <Ada...@ja...> wrote:

> I'm trying to poll 5 discontiguous OIDs, and have found some inconsistent behaviour. I created 2 tests based on the examples bundled with PySNMP:
> 
>  Test 1:
>    https://gist.github.com/anonymous/e30027e633e21dcdeb74
> 
>  Test 2:
>    https://gist.github.com/anonymous/ad9f73b2dd3ead20b1a5
> 
> Using SVN head, test 1 results in what I want, using a single GetBulk/GetResponse pair:
> 
>  (env)[root@hyperion ~]# python3 test1.py
>  1.3.6.1.4.1.2021.4.5.0 = 501920
>  1.3.6.1.4.1.2021.4.11.0 = 167532
>  1.3.6.1.4.1.2021.4.12.0 = 16000
>  1.3.6.1.4.1.2021.4.13.0 = 29148
>  1.3.6.1.4.1.2021.4.14.0 = 54840
> 
> Test 2 results in the entire tree being walked (this output is taken from tcpdump:
> 
>  11:21:17.001849 IP localhost.60083 > localhost.snmp:  GetBulk(89)  N=5 M=0 E:2021.4.5 E:2021.4.11 E:2021.4.12 E:2021.4.13 E:2021.4.14
>  11:21:17.002378 IP localhost.snmp > localhost.60083:  GetResponse(107)  E:2021.4.5.0=501920 E:2021.4.11.0=158660 E:2021.4.12.0=16000 E:2021.4.13.0=29180 E:2021.4.14.0=55016
>  11:21:17.014072 IP localhost.60083 > localhost.snmp:  GetBulk(89)  N=5 M=0 E:2021.4.5 E:2021.4.11 E:2021.4.12 E:2021.4.13 E:2021.4.14
>  11:21:17.014421 IP localhost.snmp > localhost.60083:  GetResponse(107)  E:2021.4.5.0=501920 E:2021.4.11.0=158660 E:2021.4.12.0=16000 E:2021.4.13.0=29180 E:2021.4.14.0=55016
>  11:21:17.021031 IP localhost.60083 > localhost.snmp:  GetBulk(89)  N=5 M=0 E:2021.4.5 E:2021.4.11 E:2021.4.12 E:2021.4.13 E:2021.4.14
>  11:21:17.021392 IP localhost.snmp > localhost.60083:  GetResponse(107)  E:2021.4.5.0=501920 E:2021.4.11.0=158660 E:2021.4.12.0=16000 E:2021.4.13.0=29180 E:2021.4.14.0=55016
>  11:21:17.028028 IP localhost.60083 > localhost.snmp:  GetBulk(89)  N=5 M=0 E:2021.4.5 E:2021.4.11 E:2021.4.12 E:2021.4.13 E:2021.4.14
>  11:21:17.028438 IP localhost.snmp > localhost.60083:  GetResponse(107)  E:2021.4.5.0=501920 E:2021.4.11.0=158660 E:2021.4.12.0=16000 E:2021.4.13.0=29180 E:2021.4.14.0=55016
>  11:21:17.034881 IP localhost.60083 > localhost.snmp:  GetBulk(89)  N=5 M=0 E:2021.4.5 E:2021.4.11 E:2021.4.12 E:2021.4.13 E:2021.4.14
>  11:21:17.035280 IP localhost.snmp > localhost.60083:  GetResponse(107)  E:2021.4.5.0=501920 E:2021.4.11.0=158660 E:2021.4.12.0=16000 E:2021.4.13.0=29180 E:2021.4.14.0=55016
>  ...
> 
> Using the 4.2.5 release, test 1 doesn't run due to BulkCommandGenerator's signature being different.
> 
> Test 2 runs to completion, but does not return the correct values, and uses 2 GetBulk/GetResponse pair:
> 
>  (env)[root@hyperion ~]# python3 test2.py
>  1.3.6.1.4.1.2021.4.5.0 = 501920
>  1.3.6.1.4.1.2021.4.11.0 = 170476
>  1.3.6.1.4.1.2021.4.12.0 = 16000
>  1.3.6.1.4.1.2021.4.13.0 = 29180
>  1.3.6.1.4.1.2021.4.14.0 = 52692
>  1.3.6.1.4.1.2021.4.6.0 = 170476
>  1.3.6.1.4.1.2021.4.12.0 = 16000
>  1.3.6.1.4.1.2021.4.13.0 = 29180
>  1.3.6.1.4.1.2021.4.14.0 = 52692
>  1.3.6.1.4.1.2021.4.15.0 = 119764
> 
> I would have expected the same results from both tests under both versions - is there a difference between the standard and oneshot API's that I've overlooked?
> 
> Thanks,
> 
> Adam Bishop

[pysnmp-users] Inconsistent responses between API's/versions

[Adam B. <Ada...@ja...>]

I'm trying to poll 5 discontiguous OIDs, and have found some inconsistent behaviour. I created 2 tests based on the examples bundled with PySNMP:

  Test 1:
    https://gist.github.com/anonymous/e30027e633e21dcdeb74

  Test 2:
    https://gist.github.com/anonymous/ad9f73b2dd3ead20b1a5

Using SVN head, test 1 results in what I want, using a single GetBulk/GetResponse pair:

  (env)[root@hyperion ~]# python3 test1.py
  1.3.6.1.4.1.2021.4.5.0 = 501920
  1.3.6.1.4.1.2021.4.11.0 = 167532
  1.3.6.1.4.1.2021.4.12.0 = 16000
  1.3.6.1.4.1.2021.4.13.0 = 29148
  1.3.6.1.4.1.2021.4.14.0 = 54840

Test 2 results in the entire tree being walked (this output is taken from tcpdump:

  11:21:17.001849 IP localhost.60083 > localhost.snmp:  GetBulk(89)  N=5 M=0 E:2021.4.5 E:2021.4.11 E:2021.4.12 E:2021.4.13 E:2021.4.14
  11:21:17.002378 IP localhost.snmp > localhost.60083:  GetResponse(107)  E:2021.4.5.0=501920 E:2021.4.11.0=158660 E:2021.4.12.0=16000 E:2021.4.13.0=29180 E:2021.4.14.0=55016
  11:21:17.014072 IP localhost.60083 > localhost.snmp:  GetBulk(89)  N=5 M=0 E:2021.4.5 E:2021.4.11 E:2021.4.12 E:2021.4.13 E:2021.4.14
  11:21:17.014421 IP localhost.snmp > localhost.60083:  GetResponse(107)  E:2021.4.5.0=501920 E:2021.4.11.0=158660 E:2021.4.12.0=16000 E:2021.4.13.0=29180 E:2021.4.14.0=55016
  11:21:17.021031 IP localhost.60083 > localhost.snmp:  GetBulk(89)  N=5 M=0 E:2021.4.5 E:2021.4.11 E:2021.4.12 E:2021.4.13 E:2021.4.14
  11:21:17.021392 IP localhost.snmp > localhost.60083:  GetResponse(107)  E:2021.4.5.0=501920 E:2021.4.11.0=158660 E:2021.4.12.0=16000 E:2021.4.13.0=29180 E:2021.4.14.0=55016
  11:21:17.028028 IP localhost.60083 > localhost.snmp:  GetBulk(89)  N=5 M=0 E:2021.4.5 E:2021.4.11 E:2021.4.12 E:2021.4.13 E:2021.4.14
  11:21:17.028438 IP localhost.snmp > localhost.60083:  GetResponse(107)  E:2021.4.5.0=501920 E:2021.4.11.0=158660 E:2021.4.12.0=16000 E:2021.4.13.0=29180 E:2021.4.14.0=55016
  11:21:17.034881 IP localhost.60083 > localhost.snmp:  GetBulk(89)  N=5 M=0 E:2021.4.5 E:2021.4.11 E:2021.4.12 E:2021.4.13 E:2021.4.14
  11:21:17.035280 IP localhost.snmp > localhost.60083:  GetResponse(107)  E:2021.4.5.0=501920 E:2021.4.11.0=158660 E:2021.4.12.0=16000 E:2021.4.13.0=29180 E:2021.4.14.0=55016
  ...

Using the 4.2.5 release, test 1 doesn't run due to BulkCommandGenerator's signature being different.

Test 2 runs to completion, but does not return the correct values, and uses 2 GetBulk/GetResponse pair:

  (env)[root@hyperion ~]# python3 test2.py
  1.3.6.1.4.1.2021.4.5.0 = 501920
  1.3.6.1.4.1.2021.4.11.0 = 170476
  1.3.6.1.4.1.2021.4.12.0 = 16000
  1.3.6.1.4.1.2021.4.13.0 = 29180
  1.3.6.1.4.1.2021.4.14.0 = 52692
  1.3.6.1.4.1.2021.4.6.0 = 170476
  1.3.6.1.4.1.2021.4.12.0 = 16000
  1.3.6.1.4.1.2021.4.13.0 = 29180
  1.3.6.1.4.1.2021.4.14.0 = 52692
  1.3.6.1.4.1.2021.4.15.0 = 119764

I would have expected the same results from both tests under both versions - is there a difference between the standard and oneshot API's that I've overlooked?

Thanks,

Adam Bishop

   gpg: 0x6609D460

Janet, the UK's research and education network.


Janet(UK) is a trading name of Jisc Collections and Janet Limited, a 
not-for-profit company which is registered in England under No. 2881024 
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

Re: [pysnmp-users] Dealing with odd indexes

[Ilya E. <il...@gl...>]

Hi Bryan,

I’d check with Ciena MIB to figure out the right syntax for their indices. Or just snmpwalk the whole device to see how their indices look like in OIDs.

-ilya

On 07 Sep 2014, at 02:29, Bryan Fuselier <dig...@gm...> wrote:

> I'm working with Ciena devices collecting SLA statistics. When configuring the SLA service, a service tag is used. Usually it's 4 digits. On Cisco devices, I have no problem with being able to simple query with OID of the SLA statistic with the service tag as the index. On Ciena however, they split the index into a single digit.3 digit index. So I end up having to query the device with something like 
> 
> wwpLeosCfmExtMEPDMMMaxDelay.1.234 that I need to query. It works if I use the snmpget command line, but get an error about the index can't be converted to an integer when I send 1.234 as the index. I also attempted to send wwpLeosCfmExtMEPDMMMaxDelay.1 and 234 as the index, but no such symbol error came up.
> 
> Any ideas how to approach this?
> 
> Thank you in advance.
> ------------------------------------------------------------------------------

[pysnmp-users] Dealing with odd indexes

[Bryan F. <dig...@gm...>]

I'm working with Ciena devices collecting SLA statistics. When configuring
the SLA service, a service tag is used. Usually it's 4 digits. On Cisco
devices, I have no problem with being able to simple query with OID of the
SLA statistic with the service tag as the index. On Ciena however, they
split the index into a single digit.3 digit index. So I end up having to
query the device with something like

wwpLeosCfmExtMEPDMMMaxDelay.1.234 that I need to query. It works if I use
the snmpget command line, but get an error about the index can't be
converted to an integer when I send 1.234 as the index. I also attempted to
send wwpLeosCfmExtMEPDMMMaxDelay.1 and 234 as the index, but no such symbol
error came up.

Any ideas how to approach this?

Thank you in advance.

Re: [pysnmp-users] bulkCmd max-repetions stop

[Ilya E. <il...@gl...>]

Hi Alexey,

If you take the latest development pysnmp version from here:

http://pysnmp.cvs.sourceforge.net/viewvc/pysnmp/pysnmp/?view=tar

you could use the ‘maxCalls=1’ parameter to limit the number of request-response iterations:

errorIndication, errorStatus, errorIndex, varBindTable = cmdGen.bulkCmd(
    cmdgen.CommunityData('public'),
    cmdgen.UdpTransportTarget(('demo.snmplabs.com', 161)),
    0, 25, 
    '1.3.6',
    maxCalls=1,
    lexicographicMode=True
)   

If you are stuck with an older pysnmp version you could descend to the native v3Arch API and base your app on the BulkCommandGeneratorSingleRun class. Let me know if you need more help on this.

-ilya


On 15 Aug 2014, at 11:39, Alexey Vaganov <po...@gm...> wrote:

> Hello,
> 
> Net-SNMP have two commands for bulk: snmpbulkget and snmpbulkwalk. First command stops on max-repetions, second one on OIDs leave the scopes of initial OIDs.
> PySNMP cmdgen.CommandGenerator().bulkCmd - works as snmpbulkwalk. How to force bulkCmd works like snmpbulkget?

[pysnmp-users] bulkCmd max-repetions stop

[Alexey V. <po...@gm...>]

Hello,

Net-SNMP have two commands for bulk: snmpbulkget and snmpbulkwalk. First
command stops on max-repetions, second one on OIDs leave the scopes of
initial OIDs.
PySNMP cmdgen.CommandGenerator().bulkCmd - works as snmpbulkwalk. How to
force bulkCmd works like snmpbulkget?

Re: [pysnmp-users] MIB variable in GetCommandGenerator

[Ilya E. <il...@gl...>]

Hi Chris,

Although MibVariable is designed to work with pysnmp’s ‘one-liner’ API, you should be able to use MibVariable for your purposes:

————————

from pysnmp.smi import builder, view
from pysnmp.entity.rfc3413.oneliner import mibvar

mibViewController = view.MibViewController(builder.MibBuilder())

# this only stores MIB symbol in an object but does not resolve it
# either MIB symbol into OID:
mv = mibvar.MibVariable('SNMPv2-MIB', 'sysDescr', 0)
# or OID into MIB symbol (need to load one or more MIBs)
mv = mibvar.MibVariable('1.3.6.1.2.1.1.1.0').loadMibs('SNMPv2-MIB')

# this resolves unresolved MIB variable against mibViewController&mibBuilder
mv.resolveWithMib(mibViewController)

# human-oriented representation
print mv.prettyPrint()

# OID in dotted notation
print str(mv)

# OID as Python tuple
print tuple(mv)

# also MibVariable instance could be passed to pysnmp methods
# instead of OID

# data type associated with MIB variable could be used for casting
# a more generic types
specificValue = mv.getMibNode().getSyntax().clone('my generic string')

print specificValue.prettyPrint()

——————————

Hope this helps,
Ilya


On 09 Jul 2014, at 16:55, Chris <cp...@vi...> wrote:

> Hi,
> I'm working on code that grabs four OIDs using the GetCommandGenerator.
> 
> cmd.GetCommandGenerator().sendReq(
> 	snmp-engine,'host'
> 	(
> 		((1,3,6,1,4,1,2021,4,6,0),None),
> 		((1,3,6,1,4,1,2021,4,5,0),None),
> 		((1,3,6,1,4,1,2021,4,4,0),None),
> 		((1,3,6,1,4,1,2021,4,3,0),None),
> 	),
> 	handler
> )
> 
> 
> The code will repeat the operation  every minute and then generate a report if the values break custom bounds.  The code works, but I'd like to use the MIB variables instead of the raw OIDs in order to improve the readability of the code.  I did some digging in the examples and I came up with the following.
> 
> from pysnmp.entity.rfc3413.oneliner import mibvar
> 
> realAvail=mibvar.MibVariable('UCD-SNMP-MIB','memAvailReal','0')
> 
> To test it out, I ran realAvail.prettyPrint() and I received an error saying the object wasn't properly initialized.
> 
> So I'm wondering if I'm going in the right direction? Can GetCommandGenerator.sendReq handle a MIB object in place of the OID array?
> 
> --
> Chris

[pysnmp-users] MIB variable in GetCommandGenerator

[Chris <cp...@vi...>]

Hi,
I'm working on code that grabs four OIDs using the GetCommandGenerator.

cmd.GetCommandGenerator().sendReq(
	snmp-engine,'host'
	(
		((1,3,6,1,4,1,2021,4,6,0),None),
		((1,3,6,1,4,1,2021,4,5,0),None),
		((1,3,6,1,4,1,2021,4,4,0),None),
		((1,3,6,1,4,1,2021,4,3,0),None),
	),
	handler
)


The code will repeat the operation  every minute and then generate a report if the values break custom bounds.  The code works, but I'd like to use the MIB variables instead of the raw OIDs in order to improve the readability of the code.  I did some digging in the examples and I came up with the following.

from pysnmp.entity.rfc3413.oneliner import mibvar

realAvail=mibvar.MibVariable('UCD-SNMP-MIB','memAvailReal','0')

To test it out, I ran realAvail.prettyPrint() and I received an error saying the object wasn't properly initialized.

So I'm wondering if I'm going in the right direction? Can GetCommandGenerator.sendReq handle a MIB object in place of the OID array?

--
Chris

Re: [pysnmp-users] MIB builder issue for a complex set of mibs

[Hans-Peter J. <hp...@ur...>]

Hi Ilja,

thanks for your answer.

On Dienstag, 8. Juli 2014 09:57:21 Ilya Etingof wrote:
> Hi Pete,
> 
> It’s usually smidump that is dropping parts of MIB definition due to errors
> in MIB. Try running smidump against these MIBs without the -k switch (that
> makes it ignoring MIB errors) and stderr pointing to /dev/null. Once
> smidump stops complaining, these .py modules will be alright as well. See
> pysnmp/tools/build-pysnmp-mib  script for more information on smidump
> invocation.

Here's the solution to the problem, boiled down to setting SMIPATH and add 
some symlinks for misnamed MIB files... 

export SMIPATH=$(pwd):

ln -sf LIEBERT_GP_REG.MIB LIEBERT-GP-REGISTRATION.MIB
ln -sf LIEBERT_GP_COND.MIB LIEBERT-GP-CONDITIONS-MIB
ln -sf LIEBERT_GP_AGENT.MIB LIEBERT-GP-AGENT-MIB

for f in \
    LIEBERT_GP_REG.MIB \
    LIEBERT_GP_COND.MIB \
    LIEBERT_GP_AGENT.MIB \
    LIEBERT_GP_CONTROLLER.MIB \
    LIEBERT_GP_NOTIFY.MIB \
    LIEBERT_GP_SYSTEM.MIB \
    LIEBERT_GP_ENV.MIB \
    LIEBERT_GP_PDU.MIB \
    LIEBERT_GP_POWER.MIB \
    LIEBERT_GP_FLEXIBLE.MIB \
    LIEBERT_GP_FLEXIBLE_COND.MIB \
    RFC1628_UPS_MIB.MIB; do
        dpy=${f%%.MIB}-dump.py
        dst=${f%%.MIB}.py
        smidump -sm -f python $f > $dpy && libsmi2pysnmp < $dpy > $dst && rm $dpy
        #build-pysnmp-mib -o ${f%%.MIB}.py $f
done

You may consider adding switches to build-pysnmp-mib to explicitly set -k 
and stderr redirection, while omitting both by default. 

I wonder, why the SMIPATH variable is so badly documented, neither in pysnmp 
nor in smidump. man 3 smi_config provided the missing information.

Thank you again,
Pete

> -ilya
> 
> On 07 Jul 2014, at 22:52, Hans-Peter Jansen <hp...@ur...> wrote:
> > Dear Ilya, hi *,
> > 
> > being a complete SNMP rookie, I'm in the process of getting a complex set
> > of MIBs to cooperate for some snmp managing tasks with pysnmp.
> > 
> > For some reason, most of the generated python modules aren't complete,
> > although I'm using a current SVN snapshot of libsmi and current state of
> > pysmnp CVS:
> > https://build.opensuse.org/package/show/home:frispete:tools/libsmi
> > https://build.opensuse.org/package/show/home:frispete:python/python-pysnmp
> > 
> > The smidump output looks almost correct, but due to my rookie state, I'm
> > probably missing some details here..
> > 
> > The set of MIBs in question are available here:
> > 
> > http://www.emersonnetworkpower.com/documents/en-US/Brands/Liebert/Document
> > s/Downloads/SoftwareDownloads/Unity%20Card/192436P1.zip
> > 
> > Of course(?!), this set contains some blatant glitches, but who cares..
> > I fixed them up with the attached (hopefully correct) patch, and compiled
> > them with compile.sh.
> > 
> > Compiling them triggers a bunch of:
> > WARNING: empty MIB module name seen in smidump output at
> > LIEBERT-GP-AGENT-MIB
> > 
> > This is the result:
> > -rw-rw-r-- 1 hp lisa  16353  7. Aug 2013  LIEBERT_GP_AGENT.MIB
> > -rw-rw-r-- 1 hp lisa   2925  7. Jul 20:33 LIEBERT_GP_AGENT.py
> > -rw-rw-r-- 1 hp lisa 180469  7. Aug 2013  LIEBERT_GP_COND.MIB
> > -rw-rw-r-- 1 hp lisa   2761  7. Jul 20:33 LIEBERT_GP_COND.py
> > -rw-rw-r-- 1 hp lisa   3351  7. Aug 2013  LIEBERT_GP_CONTROLLER.MIB
> > -rw-rw-r-- 1 hp lisa   2456  7. Jul 20:33 LIEBERT_GP_CONTROLLER.py
> > -rw-rw-r-- 1 hp lisa 113533  7. Aug 2013  LIEBERT_GP_ENV.MIB
> > -rw-rw-r-- 1 hp lisa   2683  7. Jul 20:33 LIEBERT_GP_ENV.py
> > -rw-rw-r-- 1 hp lisa 128022  7. Aug 2013  LIEBERT_GP_FLEXIBLE_COND.MIB
> > -rw-rw-r-- 1 hp lisa   2467  7. Jul 20:33 LIEBERT_GP_FLEXIBLE_COND.py
> > -rw-rw-r-- 1 hp lisa  14859  7. Aug 2013  LIEBERT_GP_FLEXIBLE.MIB
> > -rw-rw-r-- 1 hp lisa   2624  7. Jul 20:33 LIEBERT_GP_FLEXIBLE.py
> > -rw-rw-r-- 1 hp lisa  14243  7. Aug 2013  LIEBERT_GP_NOTIFY.MIB
> > -rw-rw-r-- 1 hp lisa   2930  7. Jul 20:33 LIEBERT_GP_NOTIFY.py
> > -rw-rw-r-- 1 hp lisa 117068  7. Aug 2013  LIEBERT_GP_PDU.MIB
> > -rw-rw-r-- 1 hp lisa   2559  7. Jul 20:33 LIEBERT_GP_PDU.py
> > -rw-rw-r-- 1 hp lisa 114705  7. Aug 2013  LIEBERT_GP_POWER.MIB
> > -rw-rw-r-- 1 hp lisa   2566  7. Jul 20:33 LIEBERT_GP_POWER.py
> > -rw-rw-r-- 1 hp lisa  41689  7. Aug 2013  LIEBERT_GP_REG.MIB
> > -rw-rw-r-- 1 hp lisa  31669  7. Jul 20:33 LIEBERT_GP_REG.py
> > -rw-rw-r-- 1 hp lisa  18872  7. Aug 2013  LIEBERT_GP_SYSTEM.MIB
> > -rw-rw-r-- 1 hp lisa   2762  7. Jul 20:33 LIEBERT_GP_SYSTEM.py
> > -rw-rw-r-- 1 hp lisa  72054  7. Aug 2013  RFC1628_UPS_MIB.MIB
> > -rw-rw-r-- 1 hp lisa  59229  7. Jul 20:33 RFC1628_UPS_MIB.py
> > 
> > Apart from RFC1628_UPS_MIB.py and LIEBERT_GP_REG.py, all modules are
> > missing most of the defined symbols.. :(
> > 
> > It _looks_, like libsmi2pysnmp doesn't work correctly here.
> > 
> > Is there anything, that could be done on my side to correct this behavior?
> > 
> > Thanks,
> > Pete<192436p1.diff><compile.sh>-------------------------------------------
> > -----------------------------------

Re: [pysnmp-users] MIB builder issue for a complex set of mibs

[Ilya E. <il...@gl...>]

Hi Pete,

It’s usually smidump that is dropping parts of MIB definition due to errors in MIB. Try running smidump against these MIBs without the -k switch (that makes it ignoring MIB errors) and stderr pointing to /dev/null. Once smidump stops complaining, these .py modules will be alright as well. See pysnmp/tools/build-pysnmp-mib  script for more information on smidump invocation.

-ilya

On 07 Jul 2014, at 22:52, Hans-Peter Jansen <hp...@ur...> wrote:

> Dear Ilya, hi *,
> 
> being a complete SNMP rookie, I'm in the process of getting a complex set 
> of MIBs to cooperate for some snmp managing tasks with pysnmp.
> 
> For some reason, most of the generated python modules aren't complete, 
> although I'm using a current SVN snapshot of libsmi and current state of 
> pysmnp CVS:
> https://build.opensuse.org/package/show/home:frispete:tools/libsmi
> https://build.opensuse.org/package/show/home:frispete:python/python-pysnmp
> 
> The smidump output looks almost correct, but due to my rookie state, I'm 
> probably missing some details here.. 
> 
> The set of MIBs in question are available here: 
> 
> http://www.emersonnetworkpower.com/documents/en-US/Brands/Liebert/Documents/Downloads/SoftwareDownloads/Unity%20Card/192436P1.zip
> 
> Of course(?!), this set contains some blatant glitches, but who cares..
> I fixed them up with the attached (hopefully correct) patch, and compiled 
> them with compile.sh.
> 
> Compiling them triggers a bunch of:
> WARNING: empty MIB module name seen in smidump output at LIEBERT-GP-AGENT-MIB
> 
> This is the result:
> -rw-rw-r-- 1 hp lisa  16353  7. Aug 2013  LIEBERT_GP_AGENT.MIB
> -rw-rw-r-- 1 hp lisa   2925  7. Jul 20:33 LIEBERT_GP_AGENT.py
> -rw-rw-r-- 1 hp lisa 180469  7. Aug 2013  LIEBERT_GP_COND.MIB
> -rw-rw-r-- 1 hp lisa   2761  7. Jul 20:33 LIEBERT_GP_COND.py
> -rw-rw-r-- 1 hp lisa   3351  7. Aug 2013  LIEBERT_GP_CONTROLLER.MIB
> -rw-rw-r-- 1 hp lisa   2456  7. Jul 20:33 LIEBERT_GP_CONTROLLER.py
> -rw-rw-r-- 1 hp lisa 113533  7. Aug 2013  LIEBERT_GP_ENV.MIB
> -rw-rw-r-- 1 hp lisa   2683  7. Jul 20:33 LIEBERT_GP_ENV.py
> -rw-rw-r-- 1 hp lisa 128022  7. Aug 2013  LIEBERT_GP_FLEXIBLE_COND.MIB
> -rw-rw-r-- 1 hp lisa   2467  7. Jul 20:33 LIEBERT_GP_FLEXIBLE_COND.py
> -rw-rw-r-- 1 hp lisa  14859  7. Aug 2013  LIEBERT_GP_FLEXIBLE.MIB
> -rw-rw-r-- 1 hp lisa   2624  7. Jul 20:33 LIEBERT_GP_FLEXIBLE.py
> -rw-rw-r-- 1 hp lisa  14243  7. Aug 2013  LIEBERT_GP_NOTIFY.MIB
> -rw-rw-r-- 1 hp lisa   2930  7. Jul 20:33 LIEBERT_GP_NOTIFY.py
> -rw-rw-r-- 1 hp lisa 117068  7. Aug 2013  LIEBERT_GP_PDU.MIB
> -rw-rw-r-- 1 hp lisa   2559  7. Jul 20:33 LIEBERT_GP_PDU.py
> -rw-rw-r-- 1 hp lisa 114705  7. Aug 2013  LIEBERT_GP_POWER.MIB
> -rw-rw-r-- 1 hp lisa   2566  7. Jul 20:33 LIEBERT_GP_POWER.py
> -rw-rw-r-- 1 hp lisa  41689  7. Aug 2013  LIEBERT_GP_REG.MIB
> -rw-rw-r-- 1 hp lisa  31669  7. Jul 20:33 LIEBERT_GP_REG.py
> -rw-rw-r-- 1 hp lisa  18872  7. Aug 2013  LIEBERT_GP_SYSTEM.MIB
> -rw-rw-r-- 1 hp lisa   2762  7. Jul 20:33 LIEBERT_GP_SYSTEM.py
> -rw-rw-r-- 1 hp lisa  72054  7. Aug 2013  RFC1628_UPS_MIB.MIB
> -rw-rw-r-- 1 hp lisa  59229  7. Jul 20:33 RFC1628_UPS_MIB.py
> 
> Apart from RFC1628_UPS_MIB.py and LIEBERT_GP_REG.py, all modules are missing
> most of the defined symbols.. :(
> 
> It _looks_, like libsmi2pysnmp doesn't work correctly here.
> 
> Is there anything, that could be done on my side to correct this behavior?
> 
> Thanks,
> Pete<192436p1.diff><compile.sh>------------------------------------------------------------------------------

[pysnmp-users] MIB builder issue for a complex set of mibs

[Hans-Peter J. <hp...@ur...>]

Dear Ilya, hi *,

being a complete SNMP rookie, I'm in the process of getting a complex set 
of MIBs to cooperate for some snmp managing tasks with pysnmp.

For some reason, most of the generated python modules aren't complete, 
although I'm using a current SVN snapshot of libsmi and current state of 
pysmnp CVS:
https://build.opensuse.org/package/show/home:frispete:tools/libsmi
https://build.opensuse.org/package/show/home:frispete:python/python-pysnmp

The smidump output looks almost correct, but due to my rookie state, I'm 
probably missing some details here.. 

The set of MIBs in question are available here: 

http://www.emersonnetworkpower.com/documents/en-US/Brands/Liebert/Documents/Downloads/SoftwareDownloads/Unity%20Card/192436P1.zip

Of course(?!), this set contains some blatant glitches, but who cares..
I fixed them up with the attached (hopefully correct) patch, and compiled 
them with compile.sh.

Compiling them triggers a bunch of:
WARNING: empty MIB module name seen in smidump output at LIEBERT-GP-AGENT-MIB

This is the result:
-rw-rw-r-- 1 hp lisa  16353  7. Aug 2013  LIEBERT_GP_AGENT.MIB
-rw-rw-r-- 1 hp lisa   2925  7. Jul 20:33 LIEBERT_GP_AGENT.py
-rw-rw-r-- 1 hp lisa 180469  7. Aug 2013  LIEBERT_GP_COND.MIB
-rw-rw-r-- 1 hp lisa   2761  7. Jul 20:33 LIEBERT_GP_COND.py
-rw-rw-r-- 1 hp lisa   3351  7. Aug 2013  LIEBERT_GP_CONTROLLER.MIB
-rw-rw-r-- 1 hp lisa   2456  7. Jul 20:33 LIEBERT_GP_CONTROLLER.py
-rw-rw-r-- 1 hp lisa 113533  7. Aug 2013  LIEBERT_GP_ENV.MIB
-rw-rw-r-- 1 hp lisa   2683  7. Jul 20:33 LIEBERT_GP_ENV.py
-rw-rw-r-- 1 hp lisa 128022  7. Aug 2013  LIEBERT_GP_FLEXIBLE_COND.MIB
-rw-rw-r-- 1 hp lisa   2467  7. Jul 20:33 LIEBERT_GP_FLEXIBLE_COND.py
-rw-rw-r-- 1 hp lisa  14859  7. Aug 2013  LIEBERT_GP_FLEXIBLE.MIB
-rw-rw-r-- 1 hp lisa   2624  7. Jul 20:33 LIEBERT_GP_FLEXIBLE.py
-rw-rw-r-- 1 hp lisa  14243  7. Aug 2013  LIEBERT_GP_NOTIFY.MIB
-rw-rw-r-- 1 hp lisa   2930  7. Jul 20:33 LIEBERT_GP_NOTIFY.py
-rw-rw-r-- 1 hp lisa 117068  7. Aug 2013  LIEBERT_GP_PDU.MIB
-rw-rw-r-- 1 hp lisa   2559  7. Jul 20:33 LIEBERT_GP_PDU.py
-rw-rw-r-- 1 hp lisa 114705  7. Aug 2013  LIEBERT_GP_POWER.MIB
-rw-rw-r-- 1 hp lisa   2566  7. Jul 20:33 LIEBERT_GP_POWER.py
-rw-rw-r-- 1 hp lisa  41689  7. Aug 2013  LIEBERT_GP_REG.MIB
-rw-rw-r-- 1 hp lisa  31669  7. Jul 20:33 LIEBERT_GP_REG.py
-rw-rw-r-- 1 hp lisa  18872  7. Aug 2013  LIEBERT_GP_SYSTEM.MIB
-rw-rw-r-- 1 hp lisa   2762  7. Jul 20:33 LIEBERT_GP_SYSTEM.py
-rw-rw-r-- 1 hp lisa  72054  7. Aug 2013  RFC1628_UPS_MIB.MIB
-rw-rw-r-- 1 hp lisa  59229  7. Jul 20:33 RFC1628_UPS_MIB.py

Apart from RFC1628_UPS_MIB.py and LIEBERT_GP_REG.py, all modules are missing
most of the defined symbols.. :(

It _looks_, like libsmi2pysnmp doesn't work correctly here.

Is there anything, that could be done on my side to correct this behavior?

Thanks,
Pete

Re: [pysnmp-users] Unable to retrieve a Counter64 object

[Johnny C. <bla...@gm...>]

getCmd did the trick. Thank you
Johnny


On Fri, May 30, 2014 at 12:59 AM, Ilya Etingof <il...@gl...> wrote:

>
> Hi Johnny,
>
> You seem to be querying
>
>   1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.7
>
> but getting:
>
>   1.3.6.1.4.1.9.9.171.1.1.1.0
>
> because the latter is the “next” OID past
> 1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.7 at your Agent.
>
> So try using getCmd() instead of nextCmd() — this is what snmpwalk does
> for the first OID.
>
> If you are getting
>
>   len(openSessions) == 0
>
> that means that an error occurred and no data is returned at all. What is
> the errorIndication value in that case?
>
> -ilya
>
> On 28 May 2014, at 04:02, Johnny Costello <bla...@gm...> wrote:
>
> Hi llya, when I run in debug mode I get the following back. I do not see
> what I am doing wrong here and I do not get any errors in debug but the
> object returns a 0. SNMPWALK returns a value.
>
> errorIndication, errorStatus, errorIndex, openSessions  =
> cmdgen.CommandGenerator().nextCmd(
>             cmdgen.CommunityData('agent', options.community),
>             cmdgen.UdpTransportTarget((target_host, options.snmpport)),
>             (1, 3, 6, 1, 4, 1, 9, 9, 147, 1, 2, 2, 2, 1, 5, 40, 7))
>
>  print len(openSessions) -> This is 0
>
> BG: [16:43:20.045]: _sec2com: built securityName to communityName map,
> version 4: {(SnmpAdminString('agent'),
> SnmpEngineID(hexValue='80004fb805736a636f707330312d6465762e746c63473fc950'),
> SnmpAdminString('')): OctetString('MYSTRING)}
> DBG: [16:43:20.045]: generateRequestMsg: using community
> OctetString('MYSTRING') for securityModel SnmpSecurityModel(2),
> securityName SnmpAdminString('agent'), contextEngineId
> SnmpEngineID(hexValue='80004fb805736a636f707330312d6465762e746c63473fc950')
> contextName ''
> DBG: [16:43:20.045]: generateRequestMsg: Message:
>  version=1
>  community=MYSTRING
>  data=PDUs:
>   get-next-request=GetNextRequestPDU:
>    request-id=16293560
>    error-status='noError'
>    error-index=0
>    variable-bindings=VarBindList:
>     VarBind:
>      name=1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.7
>      =_BindValue:
>       unSpecified=
>
>
> DBG: [16:43:20.052]: prepareDataElements: Message:
>  version='version-2c'
>  community=MYSTRING
>  data=PDUs:
>   response=ResponsePDU:
>    request-id=16293560
>    error-status='noError'
>    error-index=0
>    variable-bindings=VarBindList:
>     VarBind:
>      name=1.3.6.1.4.1.9.9.171.1.1.1.0
>      =_BindValue:
>       value=ObjectSyntax:
>        simple=SimpleSyntax:
>         integer-value=1
>
>
> my value ends up 0.
>
> with SNMPWALK I get this.
> snmpwalk -c 'MYCOM'  -v 2c MYIP  1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.7
> SNMPv2-SMI::enterprises.9.9.147.1.2.2.2.1.5.40.7 = Gauge32: 175769
>
> Thank you
> Johnny
>
>
> On Sun, May 25, 2014 at 11:11 PM, Ilya Etingof <il...@gl...> wrote:
>
>>
>> Hi Johnny,
>>
>> Gauge/Gauge32 types are universally supported so either of them should
>> work in both SNMP v1 and v2c.
>>
>> If you enable pysnmp debugging that might help figuring out what value
>> and type is coming from your Agent.
>>
>> from pysnmp import debug
>> debug.setLogger(debug.Debug('msgproc', 'secmod', 'proxy'))
>>
>>
>> -ilya
>>
>> On 23 May 2014, at 22:49, Johnny Costello <bla...@gm...> wrote:
>>
>> Thank you IIlya, that worked for me for the Counter64 object.
>>
>> How about a Gauge32 object. I tried using setting the version to 1 or 2
>> and I still get back a empty string.
>>
>> -Johnny
>>
>>
>> On Fri, May 16, 2014 at 8:19 AM, Ilya Etingof <il...@gl...> wrote:
>>
>>>
>>> Hi Johnny,
>>>
>>> The COUNTER64 type only exists in SNMPv2c and later SNMP versions. You
>>> are using pysnmp in a way that makes it talking SNMPv1 with your Agent. In
>>> that case you would not be getting 64-bit values.
>>>
>>> So try passing 1 as the last option of CommunityData() call or just omit
>>> it (as SNMPv2c(1) is default there):
>>>
>>>   cmdgen.CommunityData('agent', options.community, 1),
>>>   cmdgen.CommunityData('agent', options.community),
>>>
>>> -ilya
>>>
>>>
>>> On 05/15/14 22:12, Johnny Costello wrote:
>>>
>>>> I have a script where I am getting values from a LB and ASA using the
>>>> MIB’s. I can retrieve most values fine but when I try to retrieve a
>>>> Counter64 value I get nothing. I can use the same MIB’s and do a snap
>>>> walk just fine but not with the Python Script.
>>>>
>>>>
>>>> Here is my example.
>>>>
>>>> Using snmpwalk I get
>>>>
>>>> IF-MIB::ifHCInOctets.2 = Counter64: 397233398
>>>>
>>>> IF-MIB::ifHCInOctets.3 = Counter64: 5351734490175
>>>>
>>>> IF-MIB::ifHCInOctets.4 = Counter64: 4813975040688
>>>>
>>>>
>>>> When I use the pysnmp I get nothing back
>>>>
>>>> errorIndication, errorStatus, errorIndex, ifHCInOctets =
>>>> cmdgen.CommandGenerator().nextCmd(
>>>>
>>>>              cmdgen.CommunityData('agent', options.community, 0),
>>>>
>>>>              cmdgen.UdpTransportTarget((target_host,
>>>> options.snmpport)),
>>>>
>>>>              (1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 6))
>>>>
>>>>
>>>> length  0  Result []
>>>>
>>>> Error Indication None Error Status 0 Error Index
>>>>
>>>> The only difference I can see with this and all the other results I am
>>>> getting back is that the result is a Counter64 object. I can get a
>>>> Counter32 object and any other type without any issues just nothing for
>>>> a Counter64.
>>>>
>>>>
>>>> Thank you
>>>>
>>>>
>>>>
>>>
>

Re: [pysnmp-users] Unable to retrieve a Counter64 object

[Ilya E. <il...@gl...>]

Hi Johnny,

You seem to be querying 

  1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.7

but getting:

  1.3.6.1.4.1.9.9.171.1.1.1.0

because the latter is the “next” OID past 1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.7 at your Agent.

So try using getCmd() instead of nextCmd() — this is what snmpwalk does for the first OID.

If you are getting

  len(openSessions) == 0

that means that an error occurred and no data is returned at all. What is the errorIndication value in that case?

-ilya

On 28 May 2014, at 04:02, Johnny Costello <bla...@gm...> wrote:

> Hi llya, when I run in debug mode I get the following back. I do not see what I am doing wrong here and I do not get any errors in debug but the object returns a 0. SNMPWALK returns a value. 
> 
> errorIndication, errorStatus, errorIndex, openSessions  = cmdgen.CommandGenerator().nextCmd(
>             cmdgen.CommunityData('agent', options.community),
>             cmdgen.UdpTransportTarget((target_host, options.snmpport)),
>             (1, 3, 6, 1, 4, 1, 9, 9, 147, 1, 2, 2, 2, 1, 5, 40, 7))
> 
>  print len(openSessions) -> This is 0
> 
> BG: [16:43:20.045]: _sec2com: built securityName to communityName map, version 4: {(SnmpAdminString('agent'), SnmpEngineID(hexValue='80004fb805736a636f707330312d6465762e746c63473fc950'), SnmpAdminString('')): OctetString('MYSTRING)}
> DBG: [16:43:20.045]: generateRequestMsg: using community OctetString('MYSTRING') for securityModel SnmpSecurityModel(2), securityName SnmpAdminString('agent'), contextEngineId SnmpEngineID(hexValue='80004fb805736a636f707330312d6465762e746c63473fc950') contextName ''
> DBG: [16:43:20.045]: generateRequestMsg: Message:
>  version=1
>  community=MYSTRING
>  data=PDUs:
>   get-next-request=GetNextRequestPDU:
>    request-id=16293560
>    error-status='noError'
>    error-index=0
>    variable-bindings=VarBindList:
>     VarBind:
>      name=1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.7
>      =_BindValue:
>       unSpecified=
> 
> 
> DBG: [16:43:20.052]: prepareDataElements: Message:
>  version='version-2c'
>  community=MYSTRING
>  data=PDUs:
>   response=ResponsePDU:
>    request-id=16293560
>    error-status='noError'
>    error-index=0
>    variable-bindings=VarBindList:
>     VarBind:
>      name=1.3.6.1.4.1.9.9.171.1.1.1.0
>      =_BindValue:
>       value=ObjectSyntax:
>        simple=SimpleSyntax:
>         integer-value=1
> 
> 
> my value ends up 0.
> 
> with SNMPWALK I get this.
> snmpwalk -c 'MYCOM'  -v 2c MYIP  1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.7
> SNMPv2-SMI::enterprises.9.9.147.1.2.2.2.1.5.40.7 = Gauge32: 175769
> 
> Thank you
> Johnny
> 
> 
> On Sun, May 25, 2014 at 11:11 PM, Ilya Etingof <il...@gl...> wrote:
> 
> Hi Johnny,
> 
> Gauge/Gauge32 types are universally supported so either of them should work in both SNMP v1 and v2c.
> 
> If you enable pysnmp debugging that might help figuring out what value and type is coming from your Agent.
> 
> from pysnmp import debug
> debug.setLogger(debug.Debug('msgproc', 'secmod', 'proxy'))
> 
> -ilya
> 
> On 23 May 2014, at 22:49, Johnny Costello <bla...@gm...> wrote:
> 
>> Thank you IIlya, that worked for me for the Counter64 object.
>> 
>> How about a Gauge32 object. I tried using setting the version to 1 or 2 and I still get back a empty string.
>> 
>> -Johnny
>> 
>> 
>> On Fri, May 16, 2014 at 8:19 AM, Ilya Etingof <il...@gl...> wrote:
>> 
>> Hi Johnny,
>> 
>> The COUNTER64 type only exists in SNMPv2c and later SNMP versions. You are using pysnmp in a way that makes it talking SNMPv1 with your Agent. In that case you would not be getting 64-bit values.
>> 
>> So try passing 1 as the last option of CommunityData() call or just omit it (as SNMPv2c(1) is default there):
>> 
>>   cmdgen.CommunityData('agent', options.community, 1),
>>   cmdgen.CommunityData('agent', options.community),
>> 
>> -ilya
>> 
>> 
>> On 05/15/14 22:12, Johnny Costello wrote:
>> I have a script where I am getting values from a LB and ASA using the
>> MIB’s. I can retrieve most values fine but when I try to retrieve a
>> Counter64 value I get nothing. I can use the same MIB’s and do a snap
>> walk just fine but not with the Python Script.
>> 
>> 
>> Here is my example.
>> 
>> Using snmpwalk I get
>> 
>> IF-MIB::ifHCInOctets.2 = Counter64: 397233398
>> 
>> IF-MIB::ifHCInOctets.3 = Counter64: 5351734490175
>> 
>> IF-MIB::ifHCInOctets.4 = Counter64: 4813975040688
>> 
>> 
>> When I use the pysnmp I get nothing back
>> 
>> errorIndication, errorStatus, errorIndex, ifHCInOctets =
>> cmdgen.CommandGenerator().nextCmd(
>> 
>>              cmdgen.CommunityData('agent', options.community, 0),
>> 
>>              cmdgen.UdpTransportTarget((target_host, options.snmpport)),
>> 
>>              (1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 6))
>> 
>> 
>> length  0  Result []
>> 
>> Error Indication None Error Status 0 Error Index
>> 
>> The only difference I can see with this and all the other results I am
>> getting back is that the result is a Counter64 object. I can get a
>> Counter32 object and any other type without any issues just nothing for
>> a Counter64.
>> 
>> 
>> Thank you
>> 
>> 
>> 

Re: [pysnmp-users] Unable to retrieve a Counter64 object

[Johnny C. <bla...@gm...>]

Hi llya, when I run in debug mode I get the following back. I do not see
what I am doing wrong here and I do not get any errors in debug but the
object returns a 0. SNMPWALK returns a value.

errorIndication, errorStatus, errorIndex, openSessions  =
cmdgen.CommandGenerator().nextCmd(
            cmdgen.CommunityData('agent', options.community),
            cmdgen.UdpTransportTarget((target_host, options.snmpport)),
            (1, 3, 6, 1, 4, 1, 9, 9, 147, 1, 2, 2, 2, 1, 5, 40, 7))

 print len(openSessions) -> This is 0

BG: [16:43:20.045]: _sec2com: built securityName to communityName map,
version 4: {(SnmpAdminString('agent'),
SnmpEngineID(hexValue='80004fb805736a636f707330312d6465762e746c63473fc950'),
SnmpAdminString('')): OctetString('MYSTRING)}
DBG: [16:43:20.045]: generateRequestMsg: using community
OctetString('MYSTRING') for securityModel SnmpSecurityModel(2),
securityName SnmpAdminString('agent'), contextEngineId
SnmpEngineID(hexValue='80004fb805736a636f707330312d6465762e746c63473fc950')
contextName ''
DBG: [16:43:20.045]: generateRequestMsg: Message:
 version=1
 community=MYSTRING
 data=PDUs:
  get-next-request=GetNextRequestPDU:
   request-id=16293560
   error-status='noError'
   error-index=0
   variable-bindings=VarBindList:
    VarBind:
     name=1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.7
     =_BindValue:
      unSpecified=


DBG: [16:43:20.052]: prepareDataElements: Message:
 version='version-2c'
 community=MYSTRING
 data=PDUs:
  response=ResponsePDU:
   request-id=16293560
   error-status='noError'
   error-index=0
   variable-bindings=VarBindList:
    VarBind:
     name=1.3.6.1.4.1.9.9.171.1.1.1.0
     =_BindValue:
      value=ObjectSyntax:
       simple=SimpleSyntax:
        integer-value=1


my value ends up 0.

with SNMPWALK I get this.
snmpwalk -c 'MYCOM'  -v 2c MYIP  1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.7
SNMPv2-SMI::enterprises.9.9.147.1.2.2.2.1.5.40.7 = Gauge32: 175769

Thank you
Johnny


On Sun, May 25, 2014 at 11:11 PM, Ilya Etingof <il...@gl...> wrote:

>
> Hi Johnny,
>
> Gauge/Gauge32 types are universally supported so either of them should
> work in both SNMP v1 and v2c.
>
> If you enable pysnmp debugging that might help figuring out what value and
> type is coming from your Agent.
>
> from pysnmp import debug
> debug.setLogger(debug.Debug('msgproc', 'secmod', 'proxy'))
>
>
> -ilya
>
> On 23 May 2014, at 22:49, Johnny Costello <bla...@gm...> wrote:
>
> Thank you IIlya, that worked for me for the Counter64 object.
>
> How about a Gauge32 object. I tried using setting the version to 1 or 2
> and I still get back a empty string.
>
> -Johnny
>
>
> On Fri, May 16, 2014 at 8:19 AM, Ilya Etingof <il...@gl...> wrote:
>
>>
>> Hi Johnny,
>>
>> The COUNTER64 type only exists in SNMPv2c and later SNMP versions. You
>> are using pysnmp in a way that makes it talking SNMPv1 with your Agent. In
>> that case you would not be getting 64-bit values.
>>
>> So try passing 1 as the last option of CommunityData() call or just omit
>> it (as SNMPv2c(1) is default there):
>>
>>   cmdgen.CommunityData('agent', options.community, 1),
>>   cmdgen.CommunityData('agent', options.community),
>>
>> -ilya
>>
>>
>> On 05/15/14 22:12, Johnny Costello wrote:
>>
>>> I have a script where I am getting values from a LB and ASA using the
>>> MIB’s. I can retrieve most values fine but when I try to retrieve a
>>> Counter64 value I get nothing. I can use the same MIB’s and do a snap
>>> walk just fine but not with the Python Script.
>>>
>>>
>>> Here is my example.
>>>
>>> Using snmpwalk I get
>>>
>>> IF-MIB::ifHCInOctets.2 = Counter64: 397233398
>>>
>>> IF-MIB::ifHCInOctets.3 = Counter64: 5351734490175
>>>
>>> IF-MIB::ifHCInOctets.4 = Counter64: 4813975040688
>>>
>>>
>>> When I use the pysnmp I get nothing back
>>>
>>> errorIndication, errorStatus, errorIndex, ifHCInOctets =
>>> cmdgen.CommandGenerator().nextCmd(
>>>
>>>              cmdgen.CommunityData('agent', options.community, 0),
>>>
>>>              cmdgen.UdpTransportTarget((target_host, options.snmpport)),
>>>
>>>              (1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 6))
>>>
>>>
>>> length  0  Result []
>>>
>>> Error Indication None Error Status 0 Error Index
>>>
>>> The only difference I can see with this and all the other results I am
>>> getting back is that the result is a Counter64 object. I can get a
>>> Counter32 object and any other type without any issues just nothing for
>>> a Counter64.
>>>
>>>
>>> Thank you
>>>
>>>
>>>
>>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform
> available
> Simple to use. Nothing to install. Get started now for free."
>
> http://p.sf.net/sfu/SauceLabs_______________________________________________
> pysnmp-users mailing list
> pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pysnmp-users
>
>
>