pysnmp-users — PySNMP usage issues

[pysnmp-users] MibNotFoundError even without using MIBs

[Rafael G. F. <ra...@be...>]

Hi all,

I am having an weird issue when running a SNMP GET command. I am getting 
an error `pysnmp.smi.error.MibNotFoundError: No module PYSNMP-SOURCE-MIB 
loaded at <pysnmp.smi.builder.MibBuilder object at 0x7f40c8f806d8>` 
however we use the OIDs directly, the MIBs are not used at all in this 
project. Even though the PYSNMP-SOURCE-MIB is not used, we have the file 
PYSNMP-SOURCE-MIB.py installed at 
.../python3.6/site-packages/pysnmp/smi/mibs.

This is the snippet that is causing the error:
     cmd = cmdgen.CommandGenerator()
     error_indication, error_status, error_index, var_binds = cmd.getCmd(
         cmdgen.CommunityData("test-agent", "public"),
         cmdgen.UdpTransportTarget((management_ip, 161), timeout=0.5, 
retries=0),
         *indexes
     )

Thanks,

[pysnmp-users] snmp_trap_server for v1 and V2c

[Xavier P. <xpe...@gm...>]

Dear all,

I grabbed [1] and adapted some code to implement a snmp trap server. It
works properly for snmp v1 but I need to receive either v1 and v2c. I was
looking how to do it and I saw that the v2c messages are ignored somewhere
before the "cbFun" function. Any one can put a bit of light over it ?

Find attached the code.


Thanks & Regards
[1] - https://stackoverflow.com/questions/33752602/listen-traps-with-pysnmp

Re: [pysnmp-users] Traceback with Asyncio pysnmp

[Ilya E. <et...@gm...>]

Hi

It would be best to open a GutHub issue against pysnmp and include a short reproducer snippet if possible.

Thanks!

> On 22 Jul 2018, at 16:39, Bharat Joshi <bha...@gm...> wrote:
> 
> Hi,
> 
> We are using asyncio pysnmp in our project and we sometime get the
> following traceback.
> 
> 2018-07-22 01:50:21,125 - 24760 - asyncio - ERROR - Exception in
> callback AbstractTransportDispatcher._cbFun(<pysnmp.carri...x7f7b54c214e0>,
> ('10.0.2.66', 161), b'01\x02\x01\...:\x04\x04eth0')
> handle: <Handle
> AbstractTransportDispatcher._cbFun(<pysnmp.carri...x7f7b54c214e0>,
> ('10.0.2.66', 161), b'01\x02\x01\...:\x04\x04eth0')>
> Traceback (most recent call last):
>  File "/usr/lib/python3.4/asyncio/events.py", line 120, in _run
>    self._callback(*self._args)
>  File "/home/vunet/workspace/vunetenv/lib/python3.4/site-packages/pysnmp/carrier/base.py",
> line 58, in _cbFun
>    'Unregistered transport %s' % (incomingTransport,)
> pysnmp.carrier.error.CarrierError: Unregistered transport
> <pysnmp.carrier.asyncio.dgram.udp.UdpAsyncioTransport object at
> 0x7f7b54c214e0>
> 
> We are using asyncio to do SNMP to multiple devices simultaneously and
> we see the above error and data for that device is not collected.
> 
> It would be great if someone can help us with this issue.
> 
> Regards,
> Bharat Joshi
> http://iiesoc.in
> http://bite-the-bytes.blogspot.com/
> https://twitter.com/Bite_the_bytes
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> pysnmp-users mailing list
> pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pysnmp-users

[pysnmp-users] Traceback with Asyncio pysnmp

[Bharat J. <bha...@gm...>]

Hi,

We are using asyncio pysnmp in our project and we sometime get the
following traceback.

2018-07-22 01:50:21,125 - 24760 - asyncio - ERROR - Exception in
callback AbstractTransportDispatcher._cbFun(<pysnmp.carri...x7f7b54c214e0>,
('10.0.2.66', 161), b'01\x02\x01\...:\x04\x04eth0')
handle: <Handle
AbstractTransportDispatcher._cbFun(<pysnmp.carri...x7f7b54c214e0>,
('10.0.2.66', 161), b'01\x02\x01\...:\x04\x04eth0')>
Traceback (most recent call last):
  File "/usr/lib/python3.4/asyncio/events.py", line 120, in _run
    self._callback(*self._args)
  File "/home/vunet/workspace/vunetenv/lib/python3.4/site-packages/pysnmp/carrier/base.py",
line 58, in _cbFun
    'Unregistered transport %s' % (incomingTransport,)
pysnmp.carrier.error.CarrierError: Unregistered transport
<pysnmp.carrier.asyncio.dgram.udp.UdpAsyncioTransport object at
0x7f7b54c214e0>

We are using asyncio to do SNMP to multiple devices simultaneously and
we see the above error and data for that device is not collected.

It would be great if someone can help us with this issue.

Regards,
Bharat Joshi
http://iiesoc.in
http://bite-the-bytes.blogspot.com/
https://twitter.com/Bite_the_bytes

Re: [pysnmp-users] Import as *.py?

[Ilya E. <et...@gm...>]

Hi Krister,

I am not really sure I understand how it works… 

AFAIK, most of the Python tools take shape of a package e.g. they are made of many individual files and directories. You can pack the package into a single importable file e.g. .egg. Is that what you need? Or you could import some top-level sub/package which will pull the rest of the stuff in e.g. `from pysnmp.hlapi import *`.



> On 20 Jun 2018, at 17:06, Krister Johnson <kri...@gm...> wrote:
> 
> Hi guys,
> 
> We have a third party app that has its own python install and allows you to import modules you dump in a custom directory as .py files. Is there a way to pull in pysnmp as a single file?
> 
> Thanks,
> 
> Krister

[pysnmp-users] Import as *.py?

[Krister J. <kri...@gm...>]

Hi guys,

We have a third party app that has its own python install and allows you to
import modules you dump in a custom directory as .py files. Is there a way
to pull in pysnmp as a single file?

Thanks,

Krister

[pysnmp-users] Convert textual mib to oid

[whatever a. <for...@gm...>]

Hi Users,

I am looking for the correct way to convert a textual representation of the
OID : IP-FORWARD-MIB::ipCidrRouteAge.172.16.0.0.255.255.0.0.0.0.0.0.0 to
its Octet form. From the Documentation i am able to figure out that i need
to use something like ObjectIdentity('IP-FORWARD-MIB', 'ipCidrRouteAge',
'172.16.0.0', '255.255.0.0', '0.0.0.0', 0). But this fails with the
following error message.
pysnmp.smi.error.SmiError: Instance index ('172.16.0.0', '255.255.0.0',
'0.0.0.0', 0) to OID convertion failure at object 'ipCidrRouteAge': Can't
coerce '0.0.0.0' into integer: '0.0.0.0'
Can someone please guide me in the proper way to break down these MIBs to
name, variable, IP, instance id?
Thanking you in Anticipation

Farhan

Re: [pysnmp-users] Throttling asyncore transmit.

[Peter K. <pe...@kr...>]

Hi,

I moved to asyncio on python 3.6, asyncio was the final push i needed to switch to python 3.
Coroutines are just way more manageable than callbacks, and everything just works.
I have a throttled task provider feeding a queue, that several collectors pull their tasks from.

A big thank you to Ilya and  the pysnmp project besides being awesome, it has open-end a whole new python3/async world to me.

Med venlig hilsen / Kind Regards
Peter Krüpl



> On 02 Apr 2018, at 03:02, Craig Small <csmall@dropbear.xyz> wrote:
> 
> 
> 
> On Sat, 17 Mar. 2018, 19:28 Ilya Etingof, <et...@gm... <mailto:et...@gm...>> wrote:
> 
> I think the easiest approach would be to make your script sending SNMP queries in chunks. In other words, you can implement the rate limiting yourself.
>  the initial `getCmd` to get things running.
> 
> 
> I did this myself where I had a scheduler pace the queries into the pysnmp framework. Most of the SNMP agents are pretty awful so you may need to limit how hard you hit per device as well.
> 
>   - Craig 
> -- 
> Craig Small             https://dropbear.xyz/ <https://dropbear.xyz/>     csmall at : dropbear.xyz <http://dropbear.xyz/>
> Debian GNU/Linux        https://www.debian.org/ <https://www.debian.org/>   csmall at : debian.org <http://debian.org/>
> Mastodon: @smallsees@social.dropbear.xyz <mailto:smallsees@social.dropbear.xyz>             Twitter: @smallsees  
> GPG fingerprint:      5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Re: [pysnmp-users] Throttling asyncore transmit.

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

On Sat, 17 Mar. 2018, 19:28 Ilya Etingof, <et...@gm...> wrote:

>
> I think the easiest approach would be to make your script sending SNMP
> queries in chunks. In other words, you can implement the rate limiting
> yourself.
>
 the initial `getCmd` to get things running.
>


I did this myself where I had a scheduler pace the queries into the pysnmp
framework. Most of the SNMP agents are pretty awful so you may need to
limit how hard you hit per device as well.

  - Craig

> --
Craig Small             https://dropbear.xyz/     csmall at : dropbear.xyz
Debian GNU/Linux        https://www.debian.org/   csmall at : debian.org
Mastodon: @smallsees@social.dropbear.xyz             Twitter: @smallsees
GPG fingerprint:      5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Re: [pysnmp-users] Throttling asyncore transmit.

[Ilya E. <et...@gm...>]

Hi Peter,

I think the easiest approach would be to make your script sending SNMP queries in chunks. In other words, you can implement the rate limiting yourself.

If you take this simple example [1] and invoke `getCmd` for a subset of your SNMP agents/OIDs from the callback function `cbFun`, that should give you total control on the packet flood you generate. So once you get a response (or time out), the `cbFun` get invoked by pysnmp. Then, besides consuming the response you can send some more SNMP queries.

Keep in mind that you still need the initial `getCmd` to get things running.

1. http://snmplabs.com/pysnmp/examples/hlapi/asyncore/manager/cmdgen/snmp-versions.html#snmpv2c

p.s. I’d suggest moving to GitHub issues for further communication as SourceForge seems to become less relevant unfortunately

> On 16 Mar 2018, at 22:46, Peter K <pe...@kr...> wrote:
> 
> Hi Group,
> 
> I just started playing with pysnmp as i need to collect snap data from approx 2000 hosts,
> and i have chosen to do it with asyncore. And i must say it works very well.
> 
> As pysnmp just generates and sends the requests very very fast. I suspect that some of my requests
> might be dropped on my upstream link, resulting in missing answers.
> 
> I have looked through the source, and used up all my search engine skills…
> Is there a way to make the async requests being sent at a controlled rate ?
> 
> 
> Med venlig hilsen / Kind Regards
> Peter Krüpl
> 

[pysnmp-users] Throttling asyncore transmit.

[Peter K <pe...@kr...>]

Hi Group,

I just started playing with pysnmp as i need to collect snap data from approx 2000 hosts,
and i have chosen to do it with asyncore. And i must say it works very well.

As pysnmp just generates and sends the requests very very fast. I suspect that some of my requests
might be dropped on my upstream link, resulting in missing answers.

I have looked through the source, and used up all my search engine skills…
Is there a way to make the async requests being sent at a controlled rate ?


Med venlig hilsen / Kind Regards
Peter Krüpl

Re: [pysnmp-users] Unknown SNMP engine ID encountered - but only on one device

[Whitesell, K. <Ken...@ws...>]

Ok, Sunday afternoon brain cramp.

Seems to me like each request is going to go out through a different source port, and so the responses will come back through that port. As long as a different port is used for sending the requests, the responses should be able to be segregated by port. Duh.

Now I can start digging.

Thanks again so much for your help.

Ken

-----Original Message-----
From: Ilya Etingof [mailto:et...@gm...] 
Sent: Sunday, October 22, 2017 4:33 AM
To: Whitesell, Ken <Ken...@ws...>
Cc: pys...@li...
Subject: Re: [pysnmp-users] Unknown SNMP engine ID encountered - but only on one device

Hi Ken,

It seems [1] that a well-behaving SNMPv3 agent is supposed to respond from the same interface it received request from. But that does not solve your problem, obviously. ;-)

On the other hand, I have not found explicit prohibition of the mis-matching addresses situation in SNMPv3 / USM RFCs. So may be pysnmp should not be that strict?

Would it help to send SNMP commands to that interface your device tends to respond from? Then may be request/response IPs would match from pysnmp’s perspective…

If you are interested in resolving this issue at the pysnmp side, I may try looking into your pysnmp debug log to figure out where exactly the mismatch breaks things…

1. https://tools.ietf.org/html/rfc3412#section-4.2.2.1

> On 22 Oct 2017, at 08:40, Whitesell, Ken via pysnmp-users <pys...@li...> wrote:
> 
> First, my sincere thanks for the replies to my question. I’ve learned a lot more about SNMP from a protocol perspective than I’ve ever needed to know in working with and around it for the past 10 years or so. 
>  
> So what I’m thinking so far is that I believe the root cause is an ip address problem. These devices are all on IPv6, and typically have multiple addresses assigned to each interface. What I’m seeing from tcpdump and wireshark is that the UDP packet being returned from the device shows a different source IP address than the address to which the request is being sent.
> (In other words, I’m sending a request from 2600:800:280::a036 to the 
> device at 2600:800:280::4444. However, the packet being returned has 
> the MAC-related auto-generated address in the lower half – 
> 2600:800:280:0:226:adff:fe05:1111, where both those addresses are 
> assigned to the same interface.)
>  
> Since this is a connectionless protocol, is it a reasonable assumption that since the response received isn’t coming from the same IP address to which the request was sent, that that might be the cause of the error?
>  
> Thanks,
>                 Ken
>  
> ----------------------------------------------------------------------
> -------- Check out the vibrant tech community on one of the world's 
> most engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot______________________________________________
> _
> pysnmp-users mailing list
> pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pysnmp-users

Re: [pysnmp-users] Unknown SNMP engine ID encountered - but only on one device

[Whitesell, K. <Ken...@ws...>]

Hi Ilya,

	It's obviously clear that you know both the code and the associated specs / RFCs significantly better than I do, so I may be missing something trivial here, but it seems to me like there might be a problem with allowing the addresses to not be the same? The thought that pops into my head is that it would be difficult to associate any specific response to a request in an asynchronous environment. (The eventual target is having one thread sending out requests to about 40 devices on one thread, and having a separate thread listening for the responses. I haven't gotten that far yet, but that's the direction I'm working toward. The nature of these devices is such that some of the custom OIDs being queried have as much as a 0.5 second latency between the request and the response.)

	Thanks for the RFC link, I've started reading it but I won't make any claims that I really understand it yet.

	For some reason sending the commands to that address isn't working. I suspect that there's some firewall rule involved. (That's pure conjecture.) 

	Anyway, I'll gladly send you any information that I can that might help - but I'd like to do my part too. If it's something that I might be able to research / investigate, I'm more than happy to do it. Tips or pointers would be appreciated. Or, if you really want to look at a log, please tell me what you want included and I'll pass one along. (What settings or options you'd like to see set, etc)

Ken

-----Original Message-----
From: Ilya Etingof [mailto:et...@gm...] 
Sent: Sunday, October 22, 2017 4:33 AM
To: Whitesell, Ken <Ken...@ws...>
Cc: pys...@li...
Subject: Re: [pysnmp-users] Unknown SNMP engine ID encountered - but only on one device

Hi Ken,

It seems [1] that a well-behaving SNMPv3 agent is supposed to respond from the same interface it received request from. But that does not solve your problem, obviously. ;-)

On the other hand, I have not found explicit prohibition of the mis-matching addresses situation in SNMPv3 / USM RFCs. So may be pysnmp should not be that strict?

Would it help to send SNMP commands to that interface your device tends to respond from? Then may be request/response IPs would match from pysnmp’s perspective…

If you are interested in resolving this issue at the pysnmp side, I may try looking into your pysnmp debug log to figure out where exactly the mismatch breaks things…

1. https://tools.ietf.org/html/rfc3412#section-4.2.2.1

> On 22 Oct 2017, at 08:40, Whitesell, Ken via pysnmp-users <pys...@li...> wrote:
> 
> First, my sincere thanks for the replies to my question. I’ve learned a lot more about SNMP from a protocol perspective than I’ve ever needed to know in working with and around it for the past 10 years or so. 
>  
> So what I’m thinking so far is that I believe the root cause is an ip address problem. These devices are all on IPv6, and typically have multiple addresses assigned to each interface. What I’m seeing from tcpdump and wireshark is that the UDP packet being returned from the device shows a different source IP address than the address to which the request is being sent.
> (In other words, I’m sending a request from 2600:800:280::a036 to the 
> device at 2600:800:280::4444. However, the packet being returned has 
> the MAC-related auto-generated address in the lower half – 
> 2600:800:280:0:226:adff:fe05:1111, where both those addresses are 
> assigned to the same interface.)
>  
> Since this is a connectionless protocol, is it a reasonable assumption that since the response received isn’t coming from the same IP address to which the request was sent, that that might be the cause of the error?
>  
> Thanks,
>                 Ken
>  
> ----------------------------------------------------------------------
> -------- Check out the vibrant tech community on one of the world's 
> most engaging tech sites, Slashdot.org! 
> http://sdm.link/slashdot______________________________________________
> _
> pysnmp-users mailing list
> pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pysnmp-users

Re: [pysnmp-users] Unknown SNMP engine ID encountered - but only on one device

[Ilya E. <et...@gm...>]

Hi Ken,

It seems [1] that a well-behaving SNMPv3 agent is supposed to respond from the same interface it received request from. But that does not solve your problem, obviously. ;-)

On the other hand, I have not found explicit prohibition of the mis-matching addresses situation in SNMPv3 / USM RFCs. So may be pysnmp should not be that strict?

Would it help to send SNMP commands to that interface your device tends to respond from? Then may be request/response IPs would match from pysnmp’s perspective…

If you are interested in resolving this issue at the pysnmp side, I may try looking into your pysnmp debug log to figure out where exactly the mismatch breaks things…

1. https://tools.ietf.org/html/rfc3412#section-4.2.2.1

> On 22 Oct 2017, at 08:40, Whitesell, Ken via pysnmp-users <pys...@li...> wrote:
> 
> First, my sincere thanks for the replies to my question. I’ve learned a lot more about SNMP from a protocol perspective than I’ve ever needed to know in working with and around it for the past 10 years or so. 
>  
> So what I’m thinking so far is that I believe the root cause is an ip address problem. These devices are all on IPv6, and typically have multiple addresses assigned to each interface. What I’m seeing from tcpdump and wireshark is that the UDP packet being returned from the device shows a different source IP address than the address to which the request is being sent.
> (In other words, I’m sending a request from 2600:800:280::a036 to the device at 2600:800:280::4444. However, the packet being returned has the MAC-related auto-generated address in the lower half – 2600:800:280:0:226:adff:fe05:1111, where both those addresses are assigned to the same interface.)
>  
> Since this is a connectionless protocol, is it a reasonable assumption that since the response received isn’t coming from the same IP address to which the request was sent, that that might be the cause of the error?
>  
> Thanks,
>                 Ken
>  
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot_______________________________________________
> pysnmp-users mailing list
> pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pysnmp-users

Re: [pysnmp-users] Unknown SNMP engine ID encountered - but only on one device

[Whitesell, K. <Ken...@ws...>]

First, my sincere thanks for the replies to my question. I've learned a lot more about SNMP from a protocol perspective than I've ever needed to know in working with and around it for the past 10 years or so.

So what I'm thinking so far is that I believe the root cause is an ip address problem. These devices are all on IPv6, and typically have multiple addresses assigned to each interface. What I'm seeing from tcpdump and wireshark is that the UDP packet being returned from the device shows a different source IP address than the address to which the request is being sent.
(In other words, I'm sending a request from 2600:800:280::a036 to the device at 2600:800:280::4444. However, the packet being returned has the MAC-related auto-generated address in the lower half - 2600:800:280:0:226:adff:fe05:1111, where both those addresses are assigned to the same interface.)

Since this is a connectionless protocol, is it a reasonable assumption that since the response received isn't coming from the same IP address to which the request was sent, that that might be the cause of the error?

Thanks,
                Ken

Re: [pysnmp-users] Unknown SNMP engine ID encountered - but only on one device

[Bertrand F. <Ber...@vi...>]

Hi Ken,

In such a situation I would use wireshark sniffer with snmp dissector to have a better understanding of the agent's response.
There's a lot of info on how to use it on the net.

Encouraging Regards

Bertrand


-------- Message d'origine --------
De : Craig Small <cs...@en...>
Date : 20/10/2017 22:33 (GMT+01:00)
À : pys...@li...
Objet : Re: [pysnmp-users] Unknown SNMP engine ID encountered - but only on one device

On Sat, 21 Oct 2017 at 00:01 Whitesell, Ken via pysnmp-users <pys...@li...<mailto:pys...@li...>> wrote:
$ snmpget.py -v 3 -u xxxxxxxx -A xxxxxxxx -X xxxxxxxx -l authPriv udp6:device-2 SNMPv2-MIB::sysLocation.0
Unknown SNMP engine ID encountered
Hi Ken,
   Everyone gets caught by this message at times. It basically means "something went wrong".  I'm not sure why, perhaps the first check pysnmp does is the engine ID so it fails first.
So, the system is responding with something the code doesn't like.  You need to turn on the backtrace to see what the real problem is.

I've found some client tools play free and loose with the standards and are perfectly happy about getting back garbage that pysnmp doesn't like, which may be why you are seeing the problem in pysnmp only.

So while it says engine id, mentally translate it to "responded with bad things" to help with your debugging.

 - Craig

--
Craig Small             https://dropbear.xyz/     csmall at : enc.com.au<http://enc.com.au>
Debian GNU/Linux        https://www.debian.org/   csmall at : debian.org<http://debian.org>
Mastodon: @smallsees@social.dropbear.xyz<mailto:smallsees@social.dropbear.xyz>             Twitter: @smallsees
GPG fingerprint:      5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Re: [pysnmp-users] Unknown SNMP engine ID encountered - but only on one device

[Ilya E. <et...@gm...>]

Hi Ken,

To try to help you out I’d need your debug log for the device 2.

In general, that error relates to a failure of automatic SNMP engine ID discovery [1] where pysnmp manager is trying to figure out SNMP engine ID and the notion of time of the SNMP agent running inside RSU.

Are those RSU’s anyhow different from each other?

Does this error occur if you are not using any SNMP encryption (e.g. -l noAuthNoPriv)?

1. https://tools.ietf.org/html/rfc3414#section-4 <https://tools.ietf.org/html/rfc3414#section-4>

> On 20 Oct 2017, at 14:40, Whitesell, Ken via pysnmp-users <pys...@li...> wrote:
> 
> I’ve got a problem that has me stumped – looking for any clues or information that might point me in the right direction.
>  
> I’ve got 2 “Road-Side Units” (RSUs), part of what would be a traffic-control system, sitting in labs.
>  
> The first unit works great, responds properly to every command I issue, both in code and from the command-line. (Both the native NetSNMP commands and the pysnmp-apps versions.)
>  
> e.g.
> $ snmpget -v 3 -u xxxxxxxx -A xxxxxxxx -X xxxxxxxx -l authPriv udp6:device-1 SNMPv2-MIB::sysLocation.0
> SNMPv2-MIB::sysLocation.0 = DisplayString: Sitting on the Dock of the Bay
> $ snmpget.py -v 3 -u xxxxxxxx -A xxxxxxxx -X xxxxxxxx -l authPriv udp6:device-1 SNMPv2-MIB::sysLocation.0
> SNMPv2-MIB::sysLocation.0 = DisplayString: Sitting on the Dock of the Bay
> And, my code works as well.
>  
> Now, if I change from device1 to device2, the regular NetSNMP commands still work, but the pysnmp-apps and my code both fail with the “Unknown SNMP engine ID encountered” error message.
>  
> $ snmpget -v 3 -u xxxxxxxx -A xxxxxxxx -X xxxxxxxx -l authPriv udp6:device-2 SNMPv2-MIB::sysLocation.0
> SNMPv2-MIB::sysLocation.0 = STRING: Sitting on the Dock of the Bay
> $ snmpget.py -v 3 -u xxxxxxxx -A xxxxxxxx -X xxxxxxxx -l authPriv udp6:device-2 SNMPv2-MIB::sysLocation.0
> Unknown SNMP engine ID encountered
>  
> So I’m at a loss here.
> -          I can run the NetSNMP commands on device-2, and they all work as expected. From that I conclude that my snmp credentials are correct, that device-2 is functional, and I have network connectivity to device-2.
> -          I can run the pysnmp-apps versions of the utilities on device-1, and other devices, and they all work as expected. From that I conclude that the apps are installed properly.
> -          The code I’ve written also works on device-1 and other devices. From that I conclude that my code is essentially functional.
>  
> Other information that may be of value:
> Host system from which this all is being run –
> Linux VBubuntu 4.10.0-37-generic #41-Ubuntu SMP Fri Oct 6 20:20:37 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
> Distributor ID: Ubuntu
> Description:    Ubuntu 17.04
> Release:        17.04
> Codename:       zesty
>  
> The python virtualenv from which the code is being run contains the following:
> $ pip list
> Package      Version
> ------------ -------
> jsondiff     1.1.1 
> pip          9.0.1 
> ply          3.10  
> pyasn1       0.3.7 
> pycryptodome 3.4.7 
> pysmi        0.1.4 
> pysnmp       4.3.10
> pysnmp-apps  0.4.2 
> pysnmp-mibs  0.1.6 
> setuptools   36.5.0
> wheel        0.30.0
>  
>  
> This is being run under python 2.7.13. I also get the same results when I run this under a different virtualenv configured to use python 3.6.1.
> 
> Other factors that probably aren’t relevant but being included just in case –
> The results don’t change whether I specify the IP address of the RSU or use a locally-defined host name (specified in /etc/hosts).
> The host on which these are being run is a VirtualBox virtual machine running on a Windows 7 host.
> The host has 2 physical Ethernet adapters attached, one that connects to the primary network, and the other connected to the test lab. That second adapter is dedicated to the virtual machines as the means to communicate with the devices in the lab. (I believe that these are all non-issue items because they cause no problem with working with device-1.)
>  
> I’ve tried setting the debug settings in my program, and have generated a lot of output – and there are a _lot_ of differences between the output for device-1 and device-2. However, none of it registers with me as having any particular significance.
>  
> I’ve also tried defining a specific SnmpEngine, using an ID as described in SNMP-FRAMEWORK-MIB.py, and that makes no difference anywhere. (I can see where the /tmp/__pysnmp/<engineID> directory is created, and the “boots” file within it, so that part appears to work normally – but it doesn’t have any effect on the end-result.)
>  
> Does anyone have any ideas or suggestions as to what I can look at that would help identify the cause – and more hopefully a solution – for this problem?
>  
> Thanks!
> Ken Whitesell
> Sr. Application Developer, Geospatial & Applied Technology
>  
> WSP
> Email: Ken...@ws...
> Tel: 410 622 3608
> Cell: 717 487 6358
>  
> WSP USA
> One East Pratt Street
> Baltimore, MD 21202
> 
> wsp.com <http://www.wsp-pb.com/usa>
>  

Re: [pysnmp-users] Unknown SNMP engine ID encountered - but only on one device

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

On Sat, 21 Oct 2017 at 00:01 Whitesell, Ken via pysnmp-users <
pys...@li...> wrote:

> $ snmpget.py -v 3 -u xxxxxxxx -A xxxxxxxx -X xxxxxxxx -l authPriv
> udp6:device-2 SNMPv2-MIB::sysLocation.0
>
> Unknown SNMP engine ID encountered
>
Hi Ken,
   Everyone gets caught by this message at times. It basically means
"something went wrong".  I'm not sure why, perhaps the first check pysnmp
does is the engine ID so it fails first.
So, the system is responding with something the code doesn't like.  You
need to turn on the backtrace to see what the real problem is.

I've found some client tools play free and loose with the standards and are
perfectly happy about getting back garbage that pysnmp doesn't like, which
may be why you are seeing the problem in pysnmp only.

So while it says engine id, mentally translate it to "responded with bad
things" to help with your debugging.

 - Craig

>
> --
Craig Small             https://dropbear.xyz/     csmall at : enc.com.au
Debian GNU/Linux        https://www.debian.org/   csmall at : debian.org
Mastodon: @smallsees@social.dropbear.xyz             Twitter: @smallsees
GPG fingerprint:      5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

[pysnmp-users] Unknown SNMP engine ID encountered - but only on one device

[Whitesell, K. <Ken...@ws...>]

I've got a problem that has me stumped - looking for any clues or information that might point me in the right direction.

I've got 2 "Road-Side Units" (RSUs), part of what would be a traffic-control system, sitting in labs.

The first unit works great, responds properly to every command I issue, both in code and from the command-line. (Both the native NetSNMP commands and the pysnmp-apps versions.)

e.g.
$ snmpget -v 3 -u xxxxxxxx -A xxxxxxxx -X xxxxxxxx -l authPriv udp6:device-1 SNMPv2-MIB::sysLocation.0
SNMPv2-MIB::sysLocation.0 = DisplayString: Sitting on the Dock of the Bay
$ snmpget.py -v 3 -u xxxxxxxx -A xxxxxxxx -X xxxxxxxx -l authPriv udp6:device-1 SNMPv2-MIB::sysLocation.0
SNMPv2-MIB::sysLocation.0 = DisplayString: Sitting on the Dock of the Bay
And, my code works as well.

Now, if I change from device1 to device2, the regular NetSNMP commands still work, but the pysnmp-apps and my code both fail with the "Unknown SNMP engine ID encountered" error message.

$ snmpget -v 3 -u xxxxxxxx -A xxxxxxxx -X xxxxxxxx -l authPriv udp6:device-2 SNMPv2-MIB::sysLocation.0
SNMPv2-MIB::sysLocation.0 = STRING: Sitting on the Dock of the Bay
$ snmpget.py -v 3 -u xxxxxxxx -A xxxxxxxx -X xxxxxxxx -l authPriv udp6:device-2 SNMPv2-MIB::sysLocation.0
Unknown SNMP engine ID encountered

So I'm at a loss here.

-          I can run the NetSNMP commands on device-2, and they all work as expected. From that I conclude that my snmp credentials are correct, that device-2 is functional, and I have network connectivity to device-2.

-          I can run the pysnmp-apps versions of the utilities on device-1, and other devices, and they all work as expected. From that I conclude that the apps are installed properly.

-          The code I've written also works on device-1 and other devices. >From that I conclude that my code is essentially functional.

Other information that may be of value:
Host system from which this all is being run -
Linux VBubuntu 4.10.0-37-generic #41-Ubuntu SMP Fri Oct 6 20:20:37 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
Distributor ID: Ubuntu
Description:    Ubuntu 17.04
Release:        17.04
Codename:       zesty

The python virtualenv from which the code is being run contains the following:
$ pip list
Package      Version
------------ -------
jsondiff     1.1.1
pip          9.0.1
ply          3.10
pyasn1       0.3.7
pycryptodome 3.4.7
pysmi        0.1.4
pysnmp       4.3.10
pysnmp-apps  0.4.2
pysnmp-mibs  0.1.6
setuptools   36.5.0
wheel        0.30.0


This is being run under python 2.7.13. I also get the same results when I run this under a different virtualenv configured to use python 3.6.1.

Other factors that probably aren't relevant but being included just in case -
The results don't change whether I specify the IP address of the RSU or use a locally-defined host name (specified in /etc/hosts).
The host on which these are being run is a VirtualBox virtual machine running on a Windows 7 host.
The host has 2 physical Ethernet adapters attached, one that connects to the primary network, and the other connected to the test lab. That second adapter is dedicated to the virtual machines as the means to communicate with the devices in the lab. (I believe that these are all non-issue items because they cause no problem with working with device-1.)

I've tried setting the debug settings in my program, and have generated a lot of output - and there are a _lot_ of differences between the output for device-1 and device-2. However, none of it registers with me as having any particular significance.

I've also tried defining a specific SnmpEngine, using an ID as described in SNMP-FRAMEWORK-MIB.py, and that makes no difference anywhere. (I can see where the /tmp/__pysnmp/<engineID> directory is created, and the "boots" file within it, so that part appears to work normally - but it doesn't have any effect on the end-result.)

Does anyone have any ideas or suggestions as to what I can look at that would help identify the cause - and more hopefully a solution - for this problem?

Thanks!
Ken Whitesell
Sr. Application Developer, Geospatial & Applied Technology

WSP
Email: Ken...@ws...
Tel: 410 622 3608
Cell: 717 487 6358

WSP USA
One East Pratt Street
Baltimore, MD 21202

wsp.com<http://www.wsp-pb.com/usa>

Re: [pysnmp-users] ObjectIdentity.resolveWithMib() fails to resolve instance indices with InetAddressIPv4 type

[Ilya E. <et...@gm...>]

In short: it looks like you pass pysnmp malformed index. You will find
more details on the StackOverflow:

   
https://stackoverflow.com/questions/46480807/objectidentity-resolvewithmib-fails-to-resolve-instance-indices-with-inetaddre/

On 09/29/2017 03:06 AM, Eugene Kim wrote:
> Greetings,
>
> While walking TCP-MIB::tcpConnectionTable, I noticed that their table
> indices were left unresolved after calling resolveWithMib(); turning MIB
> instrumentation debugging on revealed that the size constraint checks
> were applied to the textual IP address value, and not to the raw
> (4-byte) value.  The problem does not occur for non-IP-address table
> indices, such as ifIndex.
>
> To reproduce:
>
>    from pysnmp.smi.rfc1902 import ObjectIdentity
>    from pysnmp.smi.builder import MibBuilder
>    from pysnmp.smi.compiler import addMibCompiler
>    from pysnmp.smi.view import MibViewController
>    from pysnmp.debug import Debug, setLogger
>
>    builder = MibBuilder()
>    addMibCompiler(builder)
>    builder.loadModules('IF-MIB')
>    builder.loadModules('TCP-MIB')
>    view = MibViewController(builder)
>
>    def doit(*poargs):
>    print(ObjectIdentity(*poargs).resolveWithMib(view).getMibSymbol())
>
>    setLogger(Debug('all'))
>    doit('.1.3.6.1.2.1.2.2.1.1.1')
>   
> doit('.1.3.6.1.2.1.6.19.1.7.1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629')
>
>
> Returns:
>
>    2017-09-28 18:03:13,481 pysnmp: running pysnmp version 4.3.9
>    2017-09-28 18:03:13,481 pysnmp: debug category 'all' enabled
>    2017-09-28 18:03:13,482 pysnmp: resolving .1.3.6.1.2.1.2.2.1.2.1 as
>    OID or label
>    2017-09-28 18:03:13,482 pysnmp: indexMib: re-indexing MIB view
>    2017-09-28 18:03:13,486 pysnmp: getNodeNameByOid: resolved
>    :1.3.6.1.2.1.2.2.1.2.1 -> ('iso', 'org', 'dod', 'internet', 'mgmt',
>    'mib-2', 'interfaces', 'ifTable', 'ifEntry', 'ifDescr').1
>    2017-09-28 18:03:13,486 pysnmp: resolved ('.1.3.6.1.2.1.2.2.1.2.1',)
>    into prefix ObjectName('1.3.6.1.2.1.2.2.1.2') and suffix
> ObjectName('1')
>    2017-09-28 18:03:13,486 pysnmp: getNodeNameByOid: resolved
>    :1.3.6.1.2.1.2.2.1.2 -> ('iso', 'org', 'dod', 'internet', 'mgmt',
>    'mib-2', 'interfaces', 'ifTable', 'ifEntry', 'ifDescr').()
>    2017-09-28 18:03:13,486 pysnmp: resolved prefix
>    ObjectName('1.3.6.1.2.1.2.2.1.2') into MIB node MibTableColumn((1,
>    3, 6, 1, 2, 1, 2, 2, 1, 2),
>   
> DisplayString(subtypeSpec=ConstraintsIntersection(ValueSizeConstraint(0,
>    65535), ValueSizeConstraint(0, 255), ValueSizeConstraint(0, 255))))
>    2017-09-28 18:03:13,486 pysnmp: getNodeNameByOid: resolved :(1, 3,
>    6, 1, 2, 1, 2, 2, 1) -> ('iso', 'org', 'dod', 'internet', 'mgmt',
>    'mib-2', 'interfaces', 'ifTable', 'ifEntry').()
>    2017-09-28 18:03:13,487 pysnmp: resolved indices are
>    (InterfaceIndex(1),)
>    ('IF-MIB', 'ifDescr', (InterfaceIndex(1),))
>    2017-09-28 18:03:13,487 pysnmp: resolving
>   
> .1.3.6.1.2.1.6.19.1.7.1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629
>    as OID or label
>    2017-09-28 18:03:13,490 pysnmp: getNodeNameByOid: resolved
>   
> :1.3.6.1.2.1.6.19.1.7.1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629
>    -> ('iso', 'org', 'dod', 'internet', 'mgmt', 'mib-2', 'tcp',
>    'tcpConnectionTable', 'tcpConnectionEntry',
>   
> 'tcpConnectionState').1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629
>    2017-09-28 18:03:13,490 pysnmp: resolved
>   
> ('.1.3.6.1.2.1.6.19.1.7.1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629',)
>    into prefix ObjectName('1.3.6.1.2.1.6.19.1.7') and suffix
>   
> ObjectName('1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629')
>    2017-09-28 18:03:13,490 pysnmp: getNodeNameByOid: resolved
>    :1.3.6.1.2.1.6.19.1.7 -> ('iso', 'org', 'dod', 'internet', 'mgmt',
>    'mib-2', 'tcp', 'tcpConnectionTable', 'tcpConnectionEntry',
>    'tcpConnectionState').()
>    2017-09-28 18:03:13,490 pysnmp: resolved prefix
>    ObjectName('1.3.6.1.2.1.6.19.1.7') into MIB node MibTableColumn((1,
>    3, 6, 1, 2, 1, 6, 19, 1, 7),
>   
> Integer32(subtypeSpec=ConstraintsIntersection(ValueRangeConstraint(-2147483648,
>    2147483647), ConstraintsUnion(SingleValueConstraint(1, 2, 3, 4, 5,
>    6, 7, 8, 9, 10, 11, 12))), NamedValues((('synReceived', 4),
>    ('established', 5), ('finWait2', 7), ('timeWait', 11), ('finWait1',
>    6), ('lastAck', 9), ('closeWait', 8), ('deleteTCB', 12), ('closed',
>    1), ('closing', 10), ('listen', 2), ('synSent', 3)))))
>    2017-09-28 18:03:13,490 pysnmp: getNodeNameByOid: resolved :(1, 3,
>    6, 1, 2, 1, 6, 19, 1) -> ('iso', 'org', 'dod', 'internet', 'mgmt',
>    'mib-2', 'tcp', 'tcpConnectionTable', 'tcpConnectionEntry').()
>    2017-09-28 18:03:13,491 pysnmp: error resolving table indices at
>    MibTableRow, (9, 49, 48, 46, 48, 46, 48, 46, 49, 49, 22, 1, 14, 49,
>    57, 50, 46, 49, 54, 57, 46, 50, 48, 46, 49, 53, 52, 2629):
>    ConstraintsIntersection(ValueSizeConstraint(0, 65535),
>    ValueSizeConstraint(4, 4)) failed at:
>    ValueConstraintError("ValueSizeConstraint(4, 4) failed at:
>    ValueConstraintError('10.0.0.11',)",) at InetAddressIPv4
>    2017-09-28 18:03:13,491 pysnmp: resolved indices are ((9, 49, 48,
>    46, 48, 46, 48, 46, 49, 49, 22, 1, 14, 49, 57, 50, 46, 49, 54, 57,
>    46, 50, 48, 46, 49, 53, 52, 2629),)
>    ('TCP-MIB', 'tcpConnectionState', ((9, 49, 48, 46, 48, 46, 48, 46,
>    49, 49, 22, 1, 14, 49, 57, 50, 46, 49, 54, 57, 46, 50, 48, 46, 49,
>    53, 52, 2629),))
>
>
> Note how IF-MIB::ifDescr's instance index was resolved correctly to
> (InterfaceIndex(1),), while TCP-MIB::tcpConnectionState's instance index
> was left unresolved as ((9, 49, 48, 46, ...),).
>
> How can I fix or work around this issue?
>
> Cheers,
> Eugene
> ________________________________
> This email message is intended for the use of the person to whom it
> has been sent, and may contain information that is confidential or
> legally protected. If you are not the intended recipient or have
> received this message in error, you are not authorized to copy,
> distribute, or otherwise use this message or its attachments. Please
> notify the sender immediately by return e-mail and permanently delete
> this message and any attachments. NTT I3 makes no warranty that this
> email is error or virus free. Thank you.
> ________________________________
>
> ------------------------------------------------------------------------------
>
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> pysnmp-users mailing list
> pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pysnmp-users

Re: [pysnmp-users] ObjectIdentity.resolveWithMib() fails to resolve instance indices with InetAddressIPv4 type

[<et...@gm...>]

Hi Kim,

Can you check out pysnmp master branch at GitHub please? There have been relevant changes lately. 

Let me know if it helps or not. 

Thanks!

> On 29 Sep 2017, at 03:06, Eugene Kim <eug...@nt...> wrote:
> 
> Greetings,
> 
> While walking TCP-MIB::tcpConnectionTable, I noticed that their table
> indices were left unresolved after calling resolveWithMib(); turning MIB
> instrumentation debugging on revealed that the size constraint checks
> were applied to the textual IP address value, and not to the raw
> (4-byte) value.  The problem does not occur for non-IP-address table
> indices, such as ifIndex.
> 
> To reproduce:
> 
>   from pysnmp.smi.rfc1902 import ObjectIdentity
>   from pysnmp.smi.builder import MibBuilder
>   from pysnmp.smi.compiler import addMibCompiler
>   from pysnmp.smi.view import MibViewController
>   from pysnmp.debug import Debug, setLogger
> 
>   builder = MibBuilder()
>   addMibCompiler(builder)
>   builder.loadModules('IF-MIB')
>   builder.loadModules('TCP-MIB')
>   view = MibViewController(builder)
> 
>   def doit(*poargs):
>   print(ObjectIdentity(*poargs).resolveWithMib(view).getMibSymbol())
> 
>   setLogger(Debug('all'))
>   doit('.1.3.6.1.2.1.2.2.1.1.1')
>   doit('.1.3.6.1.2.1.6.19.1.7.1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629')
> 
> 
> Returns:
> 
>   2017-09-28 18:03:13,481 pysnmp: running pysnmp version 4.3.9
>   2017-09-28 18:03:13,481 pysnmp: debug category 'all' enabled
>   2017-09-28 18:03:13,482 pysnmp: resolving .1.3.6.1.2.1.2.2.1.2.1 as
>   OID or label
>   2017-09-28 18:03:13,482 pysnmp: indexMib: re-indexing MIB view
>   2017-09-28 18:03:13,486 pysnmp: getNodeNameByOid: resolved
>   :1.3.6.1.2.1.2.2.1.2.1 -> ('iso', 'org', 'dod', 'internet', 'mgmt',
>   'mib-2', 'interfaces', 'ifTable', 'ifEntry', 'ifDescr').1
>   2017-09-28 18:03:13,486 pysnmp: resolved ('.1.3.6.1.2.1.2.2.1.2.1',)
>   into prefix ObjectName('1.3.6.1.2.1.2.2.1.2') and suffix ObjectName('1')
>   2017-09-28 18:03:13,486 pysnmp: getNodeNameByOid: resolved
>   :1.3.6.1.2.1.2.2.1.2 -> ('iso', 'org', 'dod', 'internet', 'mgmt',
>   'mib-2', 'interfaces', 'ifTable', 'ifEntry', 'ifDescr').()
>   2017-09-28 18:03:13,486 pysnmp: resolved prefix
>   ObjectName('1.3.6.1.2.1.2.2.1.2') into MIB node MibTableColumn((1,
>   3, 6, 1, 2, 1, 2, 2, 1, 2),
>   DisplayString(subtypeSpec=ConstraintsIntersection(ValueSizeConstraint(0,
>   65535), ValueSizeConstraint(0, 255), ValueSizeConstraint(0, 255))))
>   2017-09-28 18:03:13,486 pysnmp: getNodeNameByOid: resolved :(1, 3,
>   6, 1, 2, 1, 2, 2, 1) -> ('iso', 'org', 'dod', 'internet', 'mgmt',
>   'mib-2', 'interfaces', 'ifTable', 'ifEntry').()
>   2017-09-28 18:03:13,487 pysnmp: resolved indices are
>   (InterfaceIndex(1),)
>   ('IF-MIB', 'ifDescr', (InterfaceIndex(1),))
>   2017-09-28 18:03:13,487 pysnmp: resolving
>   .1.3.6.1.2.1.6.19.1.7.1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629
>   as OID or label
>   2017-09-28 18:03:13,490 pysnmp: getNodeNameByOid: resolved
>   :1.3.6.1.2.1.6.19.1.7.1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629
>   -> ('iso', 'org', 'dod', 'internet', 'mgmt', 'mib-2', 'tcp',
>   'tcpConnectionTable', 'tcpConnectionEntry',
>   'tcpConnectionState').1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629
>   2017-09-28 18:03:13,490 pysnmp: resolved
>   ('.1.3.6.1.2.1.6.19.1.7.1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629',)
>   into prefix ObjectName('1.3.6.1.2.1.6.19.1.7') and suffix
>   ObjectName('1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629')
>   2017-09-28 18:03:13,490 pysnmp: getNodeNameByOid: resolved
>   :1.3.6.1.2.1.6.19.1.7 -> ('iso', 'org', 'dod', 'internet', 'mgmt',
>   'mib-2', 'tcp', 'tcpConnectionTable', 'tcpConnectionEntry',
>   'tcpConnectionState').()
>   2017-09-28 18:03:13,490 pysnmp: resolved prefix
>   ObjectName('1.3.6.1.2.1.6.19.1.7') into MIB node MibTableColumn((1,
>   3, 6, 1, 2, 1, 6, 19, 1, 7),
>   Integer32(subtypeSpec=ConstraintsIntersection(ValueRangeConstraint(-2147483648,
>   2147483647), ConstraintsUnion(SingleValueConstraint(1, 2, 3, 4, 5,
>   6, 7, 8, 9, 10, 11, 12))), NamedValues((('synReceived', 4),
>   ('established', 5), ('finWait2', 7), ('timeWait', 11), ('finWait1',
>   6), ('lastAck', 9), ('closeWait', 8), ('deleteTCB', 12), ('closed',
>   1), ('closing', 10), ('listen', 2), ('synSent', 3)))))
>   2017-09-28 18:03:13,490 pysnmp: getNodeNameByOid: resolved :(1, 3,
>   6, 1, 2, 1, 6, 19, 1) -> ('iso', 'org', 'dod', 'internet', 'mgmt',
>   'mib-2', 'tcp', 'tcpConnectionTable', 'tcpConnectionEntry').()
>   2017-09-28 18:03:13,491 pysnmp: error resolving table indices at
>   MibTableRow, (9, 49, 48, 46, 48, 46, 48, 46, 49, 49, 22, 1, 14, 49,
>   57, 50, 46, 49, 54, 57, 46, 50, 48, 46, 49, 53, 52, 2629):
>   ConstraintsIntersection(ValueSizeConstraint(0, 65535),
>   ValueSizeConstraint(4, 4)) failed at:
>   ValueConstraintError("ValueSizeConstraint(4, 4) failed at:
>   ValueConstraintError('10.0.0.11',)",) at InetAddressIPv4
>   2017-09-28 18:03:13,491 pysnmp: resolved indices are ((9, 49, 48,
>   46, 48, 46, 48, 46, 49, 49, 22, 1, 14, 49, 57, 50, 46, 49, 54, 57,
>   46, 50, 48, 46, 49, 53, 52, 2629),)
>   ('TCP-MIB', 'tcpConnectionState', ((9, 49, 48, 46, 48, 46, 48, 46,
>   49, 49, 22, 1, 14, 49, 57, 50, 46, 49, 54, 57, 46, 50, 48, 46, 49,
>   53, 52, 2629),))
> 
> 
> Note how IF-MIB::ifDescr's instance index was resolved correctly to
> (InterfaceIndex(1),), while TCP-MIB::tcpConnectionState's instance index
> was left unresolved as ((9, 49, 48, 46, ...),).
> 
> How can I fix or work around this issue?
> 
> Cheers,
> Eugene
> ________________________________
> This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. NTT I3 makes no warranty that this email is error or virus free. Thank you.
> ________________________________
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> pysnmp-users mailing list
> pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pysnmp-users

[pysnmp-users] ObjectIdentity.resolveWithMib() fails to resolve instance indices with InetAddressIPv4 type

[Eugene K. <eug...@nt...>]

Greetings,

While walking TCP-MIB::tcpConnectionTable, I noticed that their table
indices were left unresolved after calling resolveWithMib(); turning MIB
instrumentation debugging on revealed that the size constraint checks
were applied to the textual IP address value, and not to the raw
(4-byte) value.  The problem does not occur for non-IP-address table
indices, such as ifIndex.

To reproduce:

    from pysnmp.smi.rfc1902 import ObjectIdentity
    from pysnmp.smi.builder import MibBuilder
    from pysnmp.smi.compiler import addMibCompiler
    from pysnmp.smi.view import MibViewController
    from pysnmp.debug import Debug, setLogger

    builder = MibBuilder()
    addMibCompiler(builder)
    builder.loadModules('IF-MIB')
    builder.loadModules('TCP-MIB')
    view = MibViewController(builder)

    def doit(*poargs):
    print(ObjectIdentity(*poargs).resolveWithMib(view).getMibSymbol())

    setLogger(Debug('all'))
    doit('.1.3.6.1.2.1.2.2.1.1.1')
    doit('.1.3.6.1.2.1.6.19.1.7.1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629')


Returns:

    2017-09-28 18:03:13,481 pysnmp: running pysnmp version 4.3.9
    2017-09-28 18:03:13,481 pysnmp: debug category 'all' enabled
    2017-09-28 18:03:13,482 pysnmp: resolving .1.3.6.1.2.1.2.2.1.2.1 as
    OID or label
    2017-09-28 18:03:13,482 pysnmp: indexMib: re-indexing MIB view
    2017-09-28 18:03:13,486 pysnmp: getNodeNameByOid: resolved
    :1.3.6.1.2.1.2.2.1.2.1 -> ('iso', 'org', 'dod', 'internet', 'mgmt',
    'mib-2', 'interfaces', 'ifTable', 'ifEntry', 'ifDescr').1
    2017-09-28 18:03:13,486 pysnmp: resolved ('.1.3.6.1.2.1.2.2.1.2.1',)
    into prefix ObjectName('1.3.6.1.2.1.2.2.1.2') and suffix ObjectName('1')
    2017-09-28 18:03:13,486 pysnmp: getNodeNameByOid: resolved
    :1.3.6.1.2.1.2.2.1.2 -> ('iso', 'org', 'dod', 'internet', 'mgmt',
    'mib-2', 'interfaces', 'ifTable', 'ifEntry', 'ifDescr').()
    2017-09-28 18:03:13,486 pysnmp: resolved prefix
    ObjectName('1.3.6.1.2.1.2.2.1.2') into MIB node MibTableColumn((1,
    3, 6, 1, 2, 1, 2, 2, 1, 2),
    DisplayString(subtypeSpec=ConstraintsIntersection(ValueSizeConstraint(0,
    65535), ValueSizeConstraint(0, 255), ValueSizeConstraint(0, 255))))
    2017-09-28 18:03:13,486 pysnmp: getNodeNameByOid: resolved :(1, 3,
    6, 1, 2, 1, 2, 2, 1) -> ('iso', 'org', 'dod', 'internet', 'mgmt',
    'mib-2', 'interfaces', 'ifTable', 'ifEntry').()
    2017-09-28 18:03:13,487 pysnmp: resolved indices are
    (InterfaceIndex(1),)
    ('IF-MIB', 'ifDescr', (InterfaceIndex(1),))
    2017-09-28 18:03:13,487 pysnmp: resolving
    .1.3.6.1.2.1.6.19.1.7.1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629
    as OID or label
    2017-09-28 18:03:13,490 pysnmp: getNodeNameByOid: resolved
    :1.3.6.1.2.1.6.19.1.7.1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629
    -> ('iso', 'org', 'dod', 'internet', 'mgmt', 'mib-2', 'tcp',
    'tcpConnectionTable', 'tcpConnectionEntry',
    'tcpConnectionState').1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629
    2017-09-28 18:03:13,490 pysnmp: resolved
    ('.1.3.6.1.2.1.6.19.1.7.1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629',)
    into prefix ObjectName('1.3.6.1.2.1.6.19.1.7') and suffix
    ObjectName('1.9.49.48.46.48.46.48.46.49.49.22.1.14.49.57.50.46.49.54.57.46.50.48.46.49.53.52.2629')
    2017-09-28 18:03:13,490 pysnmp: getNodeNameByOid: resolved
    :1.3.6.1.2.1.6.19.1.7 -> ('iso', 'org', 'dod', 'internet', 'mgmt',
    'mib-2', 'tcp', 'tcpConnectionTable', 'tcpConnectionEntry',
    'tcpConnectionState').()
    2017-09-28 18:03:13,490 pysnmp: resolved prefix
    ObjectName('1.3.6.1.2.1.6.19.1.7') into MIB node MibTableColumn((1,
    3, 6, 1, 2, 1, 6, 19, 1, 7),
    Integer32(subtypeSpec=ConstraintsIntersection(ValueRangeConstraint(-2147483648,
    2147483647), ConstraintsUnion(SingleValueConstraint(1, 2, 3, 4, 5,
    6, 7, 8, 9, 10, 11, 12))), NamedValues((('synReceived', 4),
    ('established', 5), ('finWait2', 7), ('timeWait', 11), ('finWait1',
    6), ('lastAck', 9), ('closeWait', 8), ('deleteTCB', 12), ('closed',
    1), ('closing', 10), ('listen', 2), ('synSent', 3)))))
    2017-09-28 18:03:13,490 pysnmp: getNodeNameByOid: resolved :(1, 3,
    6, 1, 2, 1, 6, 19, 1) -> ('iso', 'org', 'dod', 'internet', 'mgmt',
    'mib-2', 'tcp', 'tcpConnectionTable', 'tcpConnectionEntry').()
    2017-09-28 18:03:13,491 pysnmp: error resolving table indices at
    MibTableRow, (9, 49, 48, 46, 48, 46, 48, 46, 49, 49, 22, 1, 14, 49,
    57, 50, 46, 49, 54, 57, 46, 50, 48, 46, 49, 53, 52, 2629):
    ConstraintsIntersection(ValueSizeConstraint(0, 65535),
    ValueSizeConstraint(4, 4)) failed at:
    ValueConstraintError("ValueSizeConstraint(4, 4) failed at:
    ValueConstraintError('10.0.0.11',)",) at InetAddressIPv4
    2017-09-28 18:03:13,491 pysnmp: resolved indices are ((9, 49, 48,
    46, 48, 46, 48, 46, 49, 49, 22, 1, 14, 49, 57, 50, 46, 49, 54, 57,
    46, 50, 48, 46, 49, 53, 52, 2629),)
    ('TCP-MIB', 'tcpConnectionState', ((9, 49, 48, 46, 48, 46, 48, 46,
    49, 49, 22, 1, 14, 49, 57, 50, 46, 49, 54, 57, 46, 50, 48, 46, 49,
    53, 52, 2629),))


Note how IF-MIB::ifDescr's instance index was resolved correctly to
(InterfaceIndex(1),), while TCP-MIB::tcpConnectionState's instance index
was left unresolved as ((9, 49, 48, 46, ...),).

How can I fix or work around this issue?

Cheers,
Eugene
________________________________
This email message is intended for the use of the person to whom it has been sent, and may contain information that is confidential or legally protected. If you are not the intended recipient or have received this message in error, you are not authorized to copy, distribute, or otherwise use this message or its attachments. Please notify the sender immediately by return e-mail and permanently delete this message and any attachments. NTT I3 makes no warranty that this email is error or virus free. Thank you.
________________________________

[pysnmp-users] Issue resolved.

[Gee Z. <tuv...@ou...>]

Resolved the issue by inserting  '' (semicolon) for ObjectIdentity.

ObjectType(ObjectIdentity(1, 3, 6, 1, 2, 1, 17, 4, 3, 1, 1)) >> ObjectType(ObjectIdentity('1, 3, 6, 1, 2, 1, 17, 4, 3, 1, 1')).


Simple fix, oh the joys of programming. Cheers.

Re: [pysnmp-users] bulkcmd works in old example code, but not in new example.

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

Hi Gee,

I think with both old and new code you should pass OID in either of the two forms:

- as a string (1.3.6.1.1…) or
- tuple of integers (1, 3, 6, 1, …) e,g,:

                         ObjectType(ObjectIdentity((1, 3, 6, 1, 2, 1, 17, 4, 3, 1, 1))),

Note extra parentheses around the numbers.

> On 25 Sep 2017, at 19:02, Gee Zany <tuv...@ou...> wrote:
> 
> Old example code: http://pysnmp.sourceforge.net/examples/current/v3arch/oneliner/manager/cmdgen/getbulk-v2c.html
> 
> New example code: http://pysnmp.sourceforge.net/examples/hlapi/asyncore/sync/manager/cmdgen/table-operations.html#fetch-scalar-and-table-variables
> 
> My code based on old example:
> https://pastebin.com/FFrf9qjP
> 
> My code based on new example:
> https://pastebin.com/Jhu4J3CV
> 
> I am trying to extract a particular OID (1.3.6.1.2.1.17.4.3.1.1) from a Cisco switch via the bulkcmd function. However, I took reference from your old example and it works. However, when I referenced from your new example, it throws errors as follows:
> 
> Traceback (most recent call last):
>  File "C:\Users\user3\PycharmProjects\SNMPCisco1\tst2.py", line 32, in <module>
>    ObjectType(ObjectIdentity(1, 3, 6, 1, 2, 1, 17, 4, 3, 1, 1)),
>  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\hlapi\asyncore\sync\cmdgen.py", line 538, in bulkCmd
>    initialVars = [x[0] for x in vbProcessor.makeVarBinds(snmpEngine, varBinds)]
>  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\hlapi\varbinds.py", line 39, in makeVarBinds
>    __varBinds.append(varBind.resolveWithMib(mibViewController))
>  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\smi\rfc1902.py", line 845, in resolveWithMib
>    self.__args[0].resolveWithMib(mibViewController)
>  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\smi\rfc1902.py", line 481, in resolveWithMib
>    self.__modName, self.__symName
>  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\smi\builder.py", line 400, in importSymbols
>    self.loadModules(modName, **userCtx)
>  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\smi\builder.py", line 362, in loadModules
>    self.loadModule(modName, **userCtx)
>  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\smi\builder.py", line 306, in loadModule
>    modData, sfx = mibSource.read(modName)
>  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\smi\builder.py", line 79, in read
>    pycData = self._getData(f + pycSfx, pycMode)
> TypeError: unsupported operand type(s) for +: 'int' and 'str'
> 
> I tried removing the for loop in the new example code, but the same error occurred. 
> 
> Any guidance is deeply appreciated. Cheers.

[pysnmp-users] bulkcmd works in old example code, but not in new example.

[Gee Z. <tuv...@ou...>]

Old example code: http://pysnmp.sourceforge.net/examples/current/v3arch/oneliner/manager/cmdgen/getbulk-v2c.html


<http://pysnmp.sourceforge.net/examples/current/v3arch/oneliner/manager/cmdgen/getbulk-v2c.html>New example code: http://pysnmp.sourceforge.net/examples/hlapi/asyncore/sync/manager/cmdgen/table-operations.html#fetch-scalar-and-table-variables


My code based on old example:

https://pastebin.com/FFrf9qjP


My code based on new example:

https://pastebin.com/Jhu4J3CV


I am trying to extract a particular OID (1.3.6.1.2.1.17.4.3.1.1) from a Cisco switch via the bulkcmd function. However, I took reference from your old example and it works. However, when I referenced from your new example, it throws errors as follows:


Traceback (most recent call last):
  File "C:\Users\user3\PycharmProjects\SNMPCisco1\tst2.py", line 32, in <module>
    ObjectType(ObjectIdentity(1, 3, 6, 1, 2, 1, 17, 4, 3, 1, 1)),
  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\hlapi\asyncore\sync\cmdgen.py", line 538, in bulkCmd
    initialVars = [x[0] for x in vbProcessor.makeVarBinds(snmpEngine, varBinds)]
  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\hlapi\varbinds.py", line 39, in makeVarBinds
    __varBinds.append(varBind.resolveWithMib(mibViewController))
  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\smi\rfc1902.py", line 845, in resolveWithMib
    self.__args[0].resolveWithMib(mibViewController)
  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\smi\rfc1902.py", line 481, in resolveWithMib
    self.__modName, self.__symName
  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\smi\builder.py", line 400, in importSymbols
    self.loadModules(modName, **userCtx)
  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\smi\builder.py", line 362, in loadModules
    self.loadModule(modName, **userCtx)
  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\smi\builder.py", line 306, in loadModule
    modData, sfx = mibSource.read(modName)
  File "C:\Users\user3\AppData\Local\Programs\Python\Python36\lib\site-packages\pysnmp\smi\builder.py", line 79, in read
    pycData = self._getData(f + pycSfx, pycMode)
TypeError: unsupported operand type(s) for +: 'int' and 'str'

I tried removing the for loop in the new example code, but the same error occurred.

Any guidance is deeply appreciated. Cheers.