pysnmp-users Mailing List for SNMP library for Python (Page 5)
Brought to you by:
elie
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(3) |
Oct
(2) |
Nov
(4) |
Dec
(4) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
|
Feb
(3) |
Mar
(16) |
Apr
(3) |
May
(6) |
Jun
|
Jul
(7) |
Aug
(12) |
Sep
(4) |
Oct
(2) |
Nov
(11) |
Dec
(6) |
2004 |
Jan
(1) |
Feb
(41) |
Mar
(4) |
Apr
(1) |
May
(6) |
Jun
|
Jul
(8) |
Aug
(5) |
Sep
(8) |
Oct
(10) |
Nov
(3) |
Dec
(1) |
2005 |
Jan
|
Feb
(4) |
Mar
(8) |
Apr
(4) |
May
(10) |
Jun
(5) |
Jul
(10) |
Aug
(6) |
Sep
(6) |
Oct
(39) |
Nov
(20) |
Dec
(21) |
2006 |
Jan
(14) |
Feb
(6) |
Mar
(15) |
Apr
|
May
(5) |
Jun
(16) |
Jul
(16) |
Aug
(18) |
Sep
(35) |
Oct
(12) |
Nov
(3) |
Dec
(3) |
2007 |
Jan
(12) |
Feb
(19) |
Mar
(27) |
Apr
(14) |
May
(32) |
Jun
|
Jul
(35) |
Aug
(11) |
Sep
(11) |
Oct
(6) |
Nov
(13) |
Dec
(4) |
2008 |
Jan
(7) |
Feb
(4) |
Mar
(2) |
Apr
(3) |
May
(3) |
Jun
(5) |
Jul
(5) |
Aug
(1) |
Sep
(2) |
Oct
(3) |
Nov
(19) |
Dec
(7) |
2009 |
Jan
(2) |
Feb
(2) |
Mar
(12) |
Apr
(16) |
May
(16) |
Jun
(23) |
Jul
(7) |
Aug
(2) |
Sep
(17) |
Oct
(20) |
Nov
(20) |
Dec
(5) |
2010 |
Jan
(11) |
Feb
(17) |
Mar
(20) |
Apr
(7) |
May
(6) |
Jun
(14) |
Jul
(5) |
Aug
(10) |
Sep
(23) |
Oct
(16) |
Nov
(32) |
Dec
(21) |
2011 |
Jan
(6) |
Feb
(11) |
Mar
(3) |
Apr
(1) |
May
(4) |
Jun
(1) |
Jul
(4) |
Aug
(8) |
Sep
(20) |
Oct
(9) |
Nov
(29) |
Dec
(25) |
2012 |
Jan
(2) |
Feb
(5) |
Mar
(2) |
Apr
(22) |
May
(21) |
Jun
(7) |
Jul
(6) |
Aug
(2) |
Sep
(12) |
Oct
(20) |
Nov
(17) |
Dec
(17) |
2013 |
Jan
(4) |
Feb
(4) |
Mar
(8) |
Apr
(8) |
May
(10) |
Jun
(2) |
Jul
(23) |
Aug
(12) |
Sep
(14) |
Oct
(12) |
Nov
(4) |
Dec
(18) |
2014 |
Jan
(2) |
Feb
(7) |
Mar
(3) |
Apr
(8) |
May
(7) |
Jun
(1) |
Jul
(5) |
Aug
(2) |
Sep
(8) |
Oct
|
Nov
(2) |
Dec
(1) |
2015 |
Jan
(3) |
Feb
(15) |
Mar
(14) |
Apr
(4) |
May
(6) |
Jun
(3) |
Jul
(1) |
Aug
(6) |
Sep
(5) |
Oct
(21) |
Nov
(43) |
Dec
(10) |
2016 |
Jan
|
Feb
(2) |
Mar
(6) |
Apr
(4) |
May
(6) |
Jun
(2) |
Jul
(6) |
Aug
(5) |
Sep
(4) |
Oct
|
Nov
(3) |
Dec
(11) |
2017 |
Jan
(1) |
Feb
(8) |
Mar
|
Apr
(7) |
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
(9) |
Oct
(8) |
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
(2) |
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: Gilmar S. <gil...@er...> - 2015-12-22 23:14:36
|
Hi Ilya, I would like to let you know that I figured out how to upgrade the pysnmp to version 4.3. I basically uninstalled and installed manually the new version. Also I have been able to run the examples of 'higher-level and multi-version Notification Receiver' you suggested. I may need to modify the code to adjust to our needs. Regards, Gilmar -----Original Message----- From: Gilmar Sinhorin Sent: Monday, December 21, 2015 5:42 PM To: 'Ilya Etingof' Cc: pys...@li... Subject: RE: [pysnmp-users] TrapPDUAPI instance has no attribute 'getEnterprise' Hi Ilya, Thanks for the reply. I modified the code in order to support the SNMP v1 and v2c, I browsed the framework a bit and I thought it was possible, but I was wrong. I would like to tell you that I'm learning the pySNMP framework as I am going. In regarding upgrade the pysnmp to version 4.3, I can upgrade since I keep deploying the python 2.7. I took a quick look in the pysnmp site https://pypi.python.org/pypi/pysnmp/4.3.0 and I attempted to upgrade from ' 4.2.2-1' to 'pysnmp-4.3.0-py2.7.egs' on Ubuntu by use this command 'sudo apt-get install python-pysnmp4=4.3.0 ', but got the message ' Version 4.3.0 for python-pysnmp4 was not found'. I also tried other command combination and didn't work ether. I considered download and install manually, but it seems that the package was packaged to be installed on windows. I would appreciate if you can help me with the steps for upgrade to 'pysnmp-4.3.0-py2.7.egs' on Ubuntu. Thanks again for your help. Regards, Gilmar Sinhorin -----Original Message----- From: Ilya Etingof [mailto:il...@gl...] Sent: Monday, December 21, 2015 4:38 AM To: Gilmar Sinhorin Cc: pys...@li... Subject: Re: [pysnmp-users] TrapPDUAPI instance has no attribute 'getEnterprise' Hi Gilmar, I’ve investigated the issue again and now I can’t see how the code you use: http://pysnmp.sourceforge.net/examples/current/v1arch/manager/ntfrcv/v2c-multiple-transports.html can possibly fail the way you reported. Is it the exact original code or you have modified it somehow? In particular, this statement from original code would prevent is from happening: if msgVer == api.protoVersion1: by not entering into the failing branch if msgVer != 0 (SNMP v1 == 0, v2c == 1). Another idea why it could happen is if your trap message has incorrect version indication. That could be figured out by adding: print(reqMsg.prerryPrint()) anywhere once reqMsg is assigned. Speaking of high-level API, if you can’t upgrade to pysnmp 4.3 (which is highly recommended), then you could refer to older examples: http://pysnmp.sourceforge.net/examples/current/v3arch/manager/ntfrcv/v2c-multiple-interfaces.html (IPv6 part can be dropped from the code above). -ilya > On 21 Dec 2015, at 04:16, Gilmar Sinhorin <gil...@er...> wrote: > > Hi Ilya, > > Thanks for the reply. > > The script I mentioned below works fine for SNMPv1 only, but the > problem I need to receive TRAP from both SNMP versions (SNMPv1. > SNMPv2) > > I tried to use the ‘use a higher-level and multi-version Notification Receiver’, but I have problem to import the module ‘from pysnmp.carrier.asyncore.dgram import udp’, which was not found on my environment. > > I need to run on Ubuntu VM, which contains installed the pysnmp-4.2.5-py2.7.egg from https://pypi.python.org/simple/pysnmp/ . Can you point to me what is the mandatory packages to run the ‘Notification Receiver’ on Ubuntu? > > > > Thanks, > > Gilmar > > From: Ilya Etingof [mailto:il...@gl...] > Sent: Sunday, December 20, 2015 7:33 AM > To: Gilmar Sinhorin > Cc: pys...@li... > Subject: Re: [pysnmp-users] TrapPDUAPI instance has no attribute 'getEnterprise' > > > > > > Hi Gilmar, > > > > That happens whenever your Notification Receiver gets SNMPv2 TRAP PDU and handles it as SNMPv1 PDU. > > If it receives SNMPv1 TRAP PDU, that failure won’t happen. > > The reason is that SNMPv1 TRAP PDU is very different from one defined > in later SNMP versions, so it > > has different API. > > > > You could either disable SNMPv2 support in your script or access SNMPv1 TRAP PDU items conditionally. > > > > Or, better yet, use a higher-level and multi-version Notification Receiver: > > > > http://pysnmp.sourceforge.net/examples/v3arch/asyncore/contents.html#n > otification-receiver-applications > > > > Besides supporting all SNMP versions out-of-the-box, it will > automatically translate SNMPv1 TRAP PDU into > > SNMPv2 TRAP PDU so your code won’t have to deal with the differences. > > > > On 18 Dec 2015, at 23:54, Gilmar Sinhorin <gil...@er...> wrote: > > > > Hi All, > > I would like your help to figure out the problem I am experiencing for > getting the enterprise. I am using the Notification Receiver code from > this link > > http://pysnmp.sourceforge.net/examples/current/v1arch/manager/ntfrcv/v2c-multiple-transports.html. I also get the AgentAddr, GenericTrap, SpecificTrap, TimeStamp attributes failed to be fetching. The getVarBindList method is working. > > > > I copied an past the trace logs when the failure happened. I hope it helps identify the issue. > > > > Please let me know if you need further detail. > > > > Thanks in advance for your help. > > Regards, > > Gilmar Sinhorin > > > > ---------------------------------------------------------------------- > ----------------------------------------------------------------- > > > > Traceback (most recent call last): > > File "/usr/lib/python2.7/pdb.py", line 1314, in main > > pdb._runscript(mainpyfile) > > File "/usr/lib/python2.7/pdb.py", line 1233, in _runscript > > self.run(statement) > > File "/usr/lib/python2.7/bdb.py", line 400, in run > > exec cmd in globals, locals > > File "<string>", line 1, in <module> > > File "ntfyReceiverV02.py", line 11, in <module> > > ''' > > File > "/usr/lib/python2.7/dist-packages/pysnmp/carrier/asynsock/dispatch.py" > , line 33, in runDispatcher > > poll(timeout and timeout or self.timeout, self.__sockMap) > > File "/usr/lib/python2.7/asyncore.py", line 156, in poll > > read(obj) > > File "/usr/lib/python2.7/asyncore.py", line 87, in read > > obj.handle_error() > > File "/usr/lib/python2.7/asyncore.py", line 83, in read > > obj.handle_read_event() > > File "/usr/lib/python2.7/asyncore.py", line 447, in > handle_read_event > > self.handle_read() > > File > "/usr/lib/python2.7/dist-packages/pysnmp/carrier/asynsock/dgram/base.p > y", line 73, in handle_read > > self._cbFun(self, transportAddress, incomingMessage) > > File "/usr/lib/python2.7/dist-packages/pysnmp/carrier/base.py", line > 46, in _cbFun > > self, transportDomain, transportAddress, incomingMessage > > File "ntfyReceiverV02.py", line 44, in cbFun > > print('Enterprise: %s' % > (trapPDU.getEnterprise(reqPDU).prettyPrint())) > > AttributeError: TrapPDUAPI instance has no attribute 'getEnterprise' > > Uncaught exception. Entering post mortem debugging > > Running 'cont' or 'step' will restart the program > |
From: Papa <pap...@gm...> - 2015-12-22 20:48:09
|
Gilmar, When I use python and pysnmp, I feel I'm standing on the shoulders of giants. :-) While apt-get is good to update your python or other applications on ubuntu, you depend on what ubuntu makes available. Python uses pip as its own package manager for python packages like pysnmp.. google, bing, etc: on how to use pip. Cheers, 21/12/2015 23:41, Gilmar Sinhorin wrote: > Hi Ilya, > Thanks for the reply. > I modified the code in order to support the SNMP v1 and v2c, I browsed the framework a bit and I thought it was possible, but I was wrong. I would like to tell you that I'm learning the pySNMP framework as I am going. In regarding upgrade the pysnmp to version 4.3, I can upgrade since I keep deploying the python 2.7. I took a quick look in the pysnmp site https://pypi.python.org/pypi/pysnmp/4.3.0 and I attempted to upgrade from ' 4.2.2-1' to 'pysnmp-4.3.0-py2.7.egs' on Ubuntu by use this command 'sudo apt-get install python-pysnmp4=4.3.0 ', but got the message ' Version 4.3.0 for python-pysnmp4 was not found'. I also tried other command combination and didn't work ether. I considered download and install manually, but it seems that the package was packaged to be installed on windows. I would appreciate if you can help me with the steps for upgrade to 'pysnmp-4.3.0-py2.7.egs' on Ubuntu. > > Thanks again for your help. > Regards, > Gilmar Sinhorin > > -----Original Message----- > From: Ilya Etingof [mailto:il...@gl...] > Sent: Monday, December 21, 2015 4:38 AM > To: Gilmar Sinhorin > Cc: pys...@li... > Subject: Re: [pysnmp-users] TrapPDUAPI instance has no attribute 'getEnterprise' > > Hi Gilmar, > > I’ve investigated the issue again and now I can’t see how the code you use: > > http://pysnmp.sourceforge.net/examples/current/v1arch/manager/ntfrcv/v2c-multiple-transports.html > > can possibly fail the way you reported. Is it the exact original code or you have modified it somehow? > In particular, this statement from original code would prevent is from happening: > > if msgVer == api.protoVersion1: > > by not entering into the failing branch if msgVer != 0 (SNMP v1 == 0, v2c == 1). > > Another idea why it could happen is if your trap message has incorrect version indication. That could be figured out by adding: > > print(reqMsg.prerryPrint()) > > anywhere once reqMsg is assigned. > > Speaking of high-level API, if you can’t upgrade to pysnmp 4.3 (which is highly recommended), then you could refer to older examples: > > http://pysnmp.sourceforge.net/examples/current/v3arch/manager/ntfrcv/v2c-multiple-interfaces.html > > (IPv6 part can be dropped from the code above). > > -ilya > >> On 21 Dec 2015, at 04:16, Gilmar Sinhorin <gil...@er...> wrote: >> >> Hi Ilya, >> >> Thanks for the reply. >> >> The script I mentioned below works fine for SNMPv1 only, but the >> problem I need to receive TRAP from both SNMP versions (SNMPv1. >> SNMPv2) >> >> I tried to use the ‘use a higher-level and multi-version Notification Receiver’, but I have problem to import the module ‘from pysnmp.carrier.asyncore.dgram import udp’, which was not found on my environment. >> >> I need to run on Ubuntu VM, which contains installed the pysnmp-4.2.5-py2.7.egg from https://pypi.python.org/simple/pysnmp/ . Can you point to me what is the mandatory packages to run the ‘Notification Receiver’ on Ubuntu? >> >> >> >> Thanks, >> >> Gilmar >> >> From: Ilya Etingof [mailto:il...@gl...] >> Sent: Sunday, December 20, 2015 7:33 AM >> To: Gilmar Sinhorin >> Cc: pys...@li... >> Subject: Re: [pysnmp-users] TrapPDUAPI instance has no attribute 'getEnterprise' >> >> >> >> >> >> Hi Gilmar, >> >> >> >> That happens whenever your Notification Receiver gets SNMPv2 TRAP PDU and handles it as SNMPv1 PDU. >> >> If it receives SNMPv1 TRAP PDU, that failure won’t happen. >> >> The reason is that SNMPv1 TRAP PDU is very different from one defined >> in later SNMP versions, so it >> >> has different API. >> >> >> >> You could either disable SNMPv2 support in your script or access SNMPv1 TRAP PDU items conditionally. >> >> >> >> Or, better yet, use a higher-level and multi-version Notification Receiver: >> >> >> >> http://pysnmp.sourceforge.net/examples/v3arch/asyncore/contents.html#n >> otification-receiver-applications >> >> >> >> Besides supporting all SNMP versions out-of-the-box, it will >> automatically translate SNMPv1 TRAP PDU into >> >> SNMPv2 TRAP PDU so your code won’t have to deal with the differences. >> >> >> >> On 18 Dec 2015, at 23:54, Gilmar Sinhorin <gil...@er...> wrote: >> >> >> >> Hi All, >> >> I would like your help to figure out the problem I am experiencing for >> getting the enterprise. I am using the Notification Receiver code from >> this link >> >> http://pysnmp.sourceforge.net/examples/current/v1arch/manager/ntfrcv/v2c-multiple-transports.html. I also get the AgentAddr, GenericTrap, SpecificTrap, TimeStamp attributes failed to be fetching. The getVarBindList method is working. >> >> >> >> I copied an past the trace logs when the failure happened. I hope it helps identify the issue. >> >> >> >> Please let me know if you need further detail. >> >> >> >> Thanks in advance for your help. >> >> Regards, >> >> Gilmar Sinhorin >> >> >> >> ---------------------------------------------------------------------- >> ----------------------------------------------------------------- >> >> >> >> Traceback (most recent call last): >> >> File "/usr/lib/python2.7/pdb.py", line 1314, in main >> >> pdb._runscript(mainpyfile) >> >> File "/usr/lib/python2.7/pdb.py", line 1233, in _runscript >> >> self.run(statement) >> >> File "/usr/lib/python2.7/bdb.py", line 400, in run >> >> exec cmd in globals, locals >> >> File "<string>", line 1, in <module> >> >> File "ntfyReceiverV02.py", line 11, in <module> >> >> ''' >> >> File >> "/usr/lib/python2.7/dist-packages/pysnmp/carrier/asynsock/dispatch.py" >> , line 33, in runDispatcher >> >> poll(timeout and timeout or self.timeout, self.__sockMap) >> >> File "/usr/lib/python2.7/asyncore.py", line 156, in poll >> >> read(obj) >> >> File "/usr/lib/python2.7/asyncore.py", line 87, in read >> >> obj.handle_error() >> >> File "/usr/lib/python2.7/asyncore.py", line 83, in read >> >> obj.handle_read_event() >> >> File "/usr/lib/python2.7/asyncore.py", line 447, in >> handle_read_event >> >> self.handle_read() >> >> File >> "/usr/lib/python2.7/dist-packages/pysnmp/carrier/asynsock/dgram/base.p >> y", line 73, in handle_read >> >> self._cbFun(self, transportAddress, incomingMessage) >> >> File "/usr/lib/python2.7/dist-packages/pysnmp/carrier/base.py", line >> 46, in _cbFun >> >> self, transportDomain, transportAddress, incomingMessage >> >> File "ntfyReceiverV02.py", line 44, in cbFun >> >> print('Enterprise: %s' % >> (trapPDU.getEnterprise(reqPDU).prettyPrint())) >> >> AttributeError: TrapPDUAPI instance has no attribute 'getEnterprise' >> >> Uncaught exception. Entering post mortem debugging >> >> Running 'cont' or 'step' will restart the program >> > ------------------------------------------------------------------------------ > _______________________________________________ > pysnmp-users mailing list > pys...@li... > https://lists.sourceforge.net/lists/listinfo/pysnmp-users -- mich Mich |
From: Gilmar S. <gil...@er...> - 2015-12-21 22:41:52
|
Hi Ilya, Thanks for the reply. I modified the code in order to support the SNMP v1 and v2c, I browsed the framework a bit and I thought it was possible, but I was wrong. I would like to tell you that I'm learning the pySNMP framework as I am going. In regarding upgrade the pysnmp to version 4.3, I can upgrade since I keep deploying the python 2.7. I took a quick look in the pysnmp site https://pypi.python.org/pypi/pysnmp/4.3.0 and I attempted to upgrade from ' 4.2.2-1' to 'pysnmp-4.3.0-py2.7.egs' on Ubuntu by use this command 'sudo apt-get install python-pysnmp4=4.3.0 ', but got the message ' Version 4.3.0 for python-pysnmp4 was not found'. I also tried other command combination and didn't work ether. I considered download and install manually, but it seems that the package was packaged to be installed on windows. I would appreciate if you can help me with the steps for upgrade to 'pysnmp-4.3.0-py2.7.egs' on Ubuntu. Thanks again for your help. Regards, Gilmar Sinhorin -----Original Message----- From: Ilya Etingof [mailto:il...@gl...] Sent: Monday, December 21, 2015 4:38 AM To: Gilmar Sinhorin Cc: pys...@li... Subject: Re: [pysnmp-users] TrapPDUAPI instance has no attribute 'getEnterprise' Hi Gilmar, I’ve investigated the issue again and now I can’t see how the code you use: http://pysnmp.sourceforge.net/examples/current/v1arch/manager/ntfrcv/v2c-multiple-transports.html can possibly fail the way you reported. Is it the exact original code or you have modified it somehow? In particular, this statement from original code would prevent is from happening: if msgVer == api.protoVersion1: by not entering into the failing branch if msgVer != 0 (SNMP v1 == 0, v2c == 1). Another idea why it could happen is if your trap message has incorrect version indication. That could be figured out by adding: print(reqMsg.prerryPrint()) anywhere once reqMsg is assigned. Speaking of high-level API, if you can’t upgrade to pysnmp 4.3 (which is highly recommended), then you could refer to older examples: http://pysnmp.sourceforge.net/examples/current/v3arch/manager/ntfrcv/v2c-multiple-interfaces.html (IPv6 part can be dropped from the code above). -ilya > On 21 Dec 2015, at 04:16, Gilmar Sinhorin <gil...@er...> wrote: > > Hi Ilya, > > Thanks for the reply. > > The script I mentioned below works fine for SNMPv1 only, but the > problem I need to receive TRAP from both SNMP versions (SNMPv1. > SNMPv2) > > I tried to use the ‘use a higher-level and multi-version Notification Receiver’, but I have problem to import the module ‘from pysnmp.carrier.asyncore.dgram import udp’, which was not found on my environment. > > I need to run on Ubuntu VM, which contains installed the pysnmp-4.2.5-py2.7.egg from https://pypi.python.org/simple/pysnmp/ . Can you point to me what is the mandatory packages to run the ‘Notification Receiver’ on Ubuntu? > > > > Thanks, > > Gilmar > > From: Ilya Etingof [mailto:il...@gl...] > Sent: Sunday, December 20, 2015 7:33 AM > To: Gilmar Sinhorin > Cc: pys...@li... > Subject: Re: [pysnmp-users] TrapPDUAPI instance has no attribute 'getEnterprise' > > > > > > Hi Gilmar, > > > > That happens whenever your Notification Receiver gets SNMPv2 TRAP PDU and handles it as SNMPv1 PDU. > > If it receives SNMPv1 TRAP PDU, that failure won’t happen. > > The reason is that SNMPv1 TRAP PDU is very different from one defined > in later SNMP versions, so it > > has different API. > > > > You could either disable SNMPv2 support in your script or access SNMPv1 TRAP PDU items conditionally. > > > > Or, better yet, use a higher-level and multi-version Notification Receiver: > > > > http://pysnmp.sourceforge.net/examples/v3arch/asyncore/contents.html#n > otification-receiver-applications > > > > Besides supporting all SNMP versions out-of-the-box, it will > automatically translate SNMPv1 TRAP PDU into > > SNMPv2 TRAP PDU so your code won’t have to deal with the differences. > > > > On 18 Dec 2015, at 23:54, Gilmar Sinhorin <gil...@er...> wrote: > > > > Hi All, > > I would like your help to figure out the problem I am experiencing for > getting the enterprise. I am using the Notification Receiver code from > this link > > http://pysnmp.sourceforge.net/examples/current/v1arch/manager/ntfrcv/v2c-multiple-transports.html. I also get the AgentAddr, GenericTrap, SpecificTrap, TimeStamp attributes failed to be fetching. The getVarBindList method is working. > > > > I copied an past the trace logs when the failure happened. I hope it helps identify the issue. > > > > Please let me know if you need further detail. > > > > Thanks in advance for your help. > > Regards, > > Gilmar Sinhorin > > > > ---------------------------------------------------------------------- > ----------------------------------------------------------------- > > > > Traceback (most recent call last): > > File "/usr/lib/python2.7/pdb.py", line 1314, in main > > pdb._runscript(mainpyfile) > > File "/usr/lib/python2.7/pdb.py", line 1233, in _runscript > > self.run(statement) > > File "/usr/lib/python2.7/bdb.py", line 400, in run > > exec cmd in globals, locals > > File "<string>", line 1, in <module> > > File "ntfyReceiverV02.py", line 11, in <module> > > ''' > > File > "/usr/lib/python2.7/dist-packages/pysnmp/carrier/asynsock/dispatch.py" > , line 33, in runDispatcher > > poll(timeout and timeout or self.timeout, self.__sockMap) > > File "/usr/lib/python2.7/asyncore.py", line 156, in poll > > read(obj) > > File "/usr/lib/python2.7/asyncore.py", line 87, in read > > obj.handle_error() > > File "/usr/lib/python2.7/asyncore.py", line 83, in read > > obj.handle_read_event() > > File "/usr/lib/python2.7/asyncore.py", line 447, in > handle_read_event > > self.handle_read() > > File > "/usr/lib/python2.7/dist-packages/pysnmp/carrier/asynsock/dgram/base.p > y", line 73, in handle_read > > self._cbFun(self, transportAddress, incomingMessage) > > File "/usr/lib/python2.7/dist-packages/pysnmp/carrier/base.py", line > 46, in _cbFun > > self, transportDomain, transportAddress, incomingMessage > > File "ntfyReceiverV02.py", line 44, in cbFun > > print('Enterprise: %s' % > (trapPDU.getEnterprise(reqPDU).prettyPrint())) > > AttributeError: TrapPDUAPI instance has no attribute 'getEnterprise' > > Uncaught exception. Entering post mortem debugging > > Running 'cont' or 'step' will restart the program > |
From: Ilya E. <il...@gl...> - 2015-12-21 09:38:27
|
Hi Gilmar, I’ve investigated the issue again and now I can’t see how the code you use: http://pysnmp.sourceforge.net/examples/current/v1arch/manager/ntfrcv/v2c-multiple-transports.html can possibly fail the way you reported. Is it the exact original code or you have modified it somehow? In particular, this statement from original code would prevent is from happening: if msgVer == api.protoVersion1: by not entering into the failing branch if msgVer != 0 (SNMP v1 == 0, v2c == 1). Another idea why it could happen is if your trap message has incorrect version indication. That could be figured out by adding: print(reqMsg.prerryPrint()) anywhere once reqMsg is assigned. Speaking of high-level API, if you can’t upgrade to pysnmp 4.3 (which is highly recommended), then you could refer to older examples: http://pysnmp.sourceforge.net/examples/current/v3arch/manager/ntfrcv/v2c-multiple-interfaces.html (IPv6 part can be dropped from the code above). -ilya > On 21 Dec 2015, at 04:16, Gilmar Sinhorin <gil...@er...> wrote: > > Hi Ilya, > > Thanks for the reply. > > The script I mentioned below works fine for SNMPv1 only, but the problem I need to receive TRAP from both SNMP versions (SNMPv1. SNMPv2) > > I tried to use the ‘use a higher-level and multi-version Notification Receiver’, but I have problem to import the module ‘from pysnmp.carrier.asyncore.dgram import udp’, which was not found on my environment. > > I need to run on Ubuntu VM, which contains installed the pysnmp-4.2.5-py2.7.egg from https://pypi.python.org/simple/pysnmp/ . Can you point to me what is the mandatory packages to run the ‘Notification Receiver’ on Ubuntu? > > > > Thanks, > > Gilmar > > From: Ilya Etingof [mailto:il...@gl...] > Sent: Sunday, December 20, 2015 7:33 AM > To: Gilmar Sinhorin > Cc: pys...@li... > Subject: Re: [pysnmp-users] TrapPDUAPI instance has no attribute 'getEnterprise' > > > > > > Hi Gilmar, > > > > That happens whenever your Notification Receiver gets SNMPv2 TRAP PDU and handles it as SNMPv1 PDU. > > If it receives SNMPv1 TRAP PDU, that failure won’t happen. > > The reason is that SNMPv1 TRAP PDU is very different from one defined in later SNMP versions, so it > > has different API. > > > > You could either disable SNMPv2 support in your script or access SNMPv1 TRAP PDU items conditionally. > > > > Or, better yet, use a higher-level and multi-version Notification Receiver: > > > > http://pysnmp.sourceforge.net/examples/v3arch/asyncore/contents.html#notification-receiver-applications > > > > Besides supporting all SNMP versions out-of-the-box, it will automatically translate SNMPv1 TRAP PDU into > > SNMPv2 TRAP PDU so your code won’t have to deal with the differences. > > > > On 18 Dec 2015, at 23:54, Gilmar Sinhorin <gil...@er...> wrote: > > > > Hi All, > > I would like your help to figure out the problem I am experiencing for getting the enterprise. I am using the Notification Receiver code from this link > > http://pysnmp.sourceforge.net/examples/current/v1arch/manager/ntfrcv/v2c-multiple-transports.html. I also get the AgentAddr, GenericTrap, SpecificTrap, TimeStamp attributes failed to be fetching. The getVarBindList method is working. > > > > I copied an past the trace logs when the failure happened. I hope it helps identify the issue. > > > > Please let me know if you need further detail. > > > > Thanks in advance for your help. > > Regards, > > Gilmar Sinhorin > > > > --------------------------------------------------------------------------------------------------------------------------------------- > > > > Traceback (most recent call last): > > File "/usr/lib/python2.7/pdb.py", line 1314, in main > > pdb._runscript(mainpyfile) > > File "/usr/lib/python2.7/pdb.py", line 1233, in _runscript > > self.run(statement) > > File "/usr/lib/python2.7/bdb.py", line 400, in run > > exec cmd in globals, locals > > File "<string>", line 1, in <module> > > File "ntfyReceiverV02.py", line 11, in <module> > > ''' > > File "/usr/lib/python2.7/dist-packages/pysnmp/carrier/asynsock/dispatch.py", line 33, in runDispatcher > > poll(timeout and timeout or self.timeout, self.__sockMap) > > File "/usr/lib/python2.7/asyncore.py", line 156, in poll > > read(obj) > > File "/usr/lib/python2.7/asyncore.py", line 87, in read > > obj.handle_error() > > File "/usr/lib/python2.7/asyncore.py", line 83, in read > > obj.handle_read_event() > > File "/usr/lib/python2.7/asyncore.py", line 447, in handle_read_event > > self.handle_read() > > File "/usr/lib/python2.7/dist-packages/pysnmp/carrier/asynsock/dgram/base.py", line 73, in handle_read > > self._cbFun(self, transportAddress, incomingMessage) > > File "/usr/lib/python2.7/dist-packages/pysnmp/carrier/base.py", line 46, in _cbFun > > self, transportDomain, transportAddress, incomingMessage > > File "ntfyReceiverV02.py", line 44, in cbFun > > print('Enterprise: %s' % (trapPDU.getEnterprise(reqPDU).prettyPrint())) > > AttributeError: TrapPDUAPI instance has no attribute 'getEnterprise' > > Uncaught exception. Entering post mortem debugging > > Running 'cont' or 'step' will restart the program > |
From: Gilmar S. <gil...@er...> - 2015-12-21 03:16:56
|
Hi Ilya, Thanks for the reply. The script I mentioned below works fine for SNMPv1 only, but the problem I need to receive TRAP from both SNMP versions (SNMPv1. SNMPv2) I tried to use the ‘use a higher-level and multi-version Notification Receiver’, but I have problem to import the module ‘from pysnmp.carrier.asyncore.dgram import udp’, which was not found on my environment. I need to run on Ubuntu VM, which contains installed the pysnmp-4.2.5-py2.7.egg from https://pypi.python.org/simple/pysnmp/ . Can you point to me what is the mandatory packages to run the ‘Notification Receiver’ on Ubuntu? Thanks, Gilmar From: Ilya Etingof [mailto:il...@gl...] Sent: Sunday, December 20, 2015 7:33 AM To: Gilmar Sinhorin Cc: pys...@li... Subject: Re: [pysnmp-users] TrapPDUAPI instance has no attribute 'getEnterprise' Hi Gilmar, That happens whenever your Notification Receiver gets SNMPv2 TRAP PDU and handles it as SNMPv1 PDU. If it receives SNMPv1 TRAP PDU, that failure won’t happen. The reason is that SNMPv1 TRAP PDU is very different from one defined in later SNMP versions, so it has different API. You could either disable SNMPv2 support in your script or access SNMPv1 TRAP PDU items conditionally. Or, better yet, use a higher-level and multi-version Notification Receiver: http://pysnmp.sourceforge.net/examples/v3arch/asyncore/contents.html#notification-receiver-applications Besides supporting all SNMP versions out-of-the-box, it will automatically translate SNMPv1 TRAP PDU into SNMPv2 TRAP PDU so your code won’t have to deal with the differences. On 18 Dec 2015, at 23:54, Gilmar Sinhorin <gil...@er...<mailto:gil...@er...>> wrote: Hi All, I would like your help to figure out the problem I am experiencing for getting the enterprise. I am using the Notification Receiver code from this link http://pysnmp.sourceforge.net/examples/current/v1arch/manager/ntfrcv/v2c-multiple-transports.html. I also get the AgentAddr, GenericTrap, SpecificTrap, TimeStamp attributes failed to be fetching. The getVarBindList method is working. I copied an past the trace logs when the failure happened. I hope it helps identify the issue. Please let me know if you need further detail. Thanks in advance for your help. Regards, Gilmar Sinhorin --------------------------------------------------------------------------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/pdb.py", line 1314, in main pdb._runscript(mainpyfile) File "/usr/lib/python2.7/pdb.py", line 1233, in _runscript self.run(statement) File "/usr/lib/python2.7/bdb.py", line 400, in run exec cmd in globals, locals File "<string>", line 1, in <module> File "ntfyReceiverV02.py", line 11, in <module> ''' File "/usr/lib/python2.7/dist-packages/pysnmp/carrier/asynsock/dispatch.py", line 33, in runDispatcher poll(timeout and timeout or self.timeout, self.__sockMap) File "/usr/lib/python2.7/asyncore.py", line 156, in poll read(obj) File "/usr/lib/python2.7/asyncore.py", line 87, in read obj.handle_error() File "/usr/lib/python2.7/asyncore.py", line 83, in read obj.handle_read_event() File "/usr/lib/python2.7/asyncore.py", line 447, in handle_read_event self.handle_read() File "/usr/lib/python2.7/dist-packages/pysnmp/carrier/asynsock/dgram/base.py", line 73, in handle_read self._cbFun(self, transportAddress, incomingMessage) File "/usr/lib/python2.7/dist-packages/pysnmp/carrier/base.py", line 46, in _cbFun self, transportDomain, transportAddress, incomingMessage File "ntfyReceiverV02.py", line 44, in cbFun print('Enterprise: %s' % (trapPDU.getEnterprise(reqPDU).prettyPrint())) AttributeError: TrapPDUAPI instance has no attribute 'getEnterprise' Uncaught exception. Entering post mortem debugging Running 'cont' or 'step' will restart the program |
From: Ilya E. <il...@gl...> - 2015-12-20 12:32:51
|
Hi Gilmar, That happens whenever your Notification Receiver gets SNMPv2 TRAP PDU and handles it as SNMPv1 PDU. If it receives SNMPv1 TRAP PDU, that failure won’t happen. The reason is that SNMPv1 TRAP PDU is very different from one defined in later SNMP versions, so it has different API. You could either disable SNMPv2 support in your script or access SNMPv1 TRAP PDU items conditionally. Or, better yet, use a higher-level and multi-version Notification Receiver: http://pysnmp.sourceforge.net/examples/v3arch/asyncore/contents.html#notification-receiver-applications <http://pysnmp.sourceforge.net/examples/v3arch/asyncore/contents.html#notification-receiver-applications> Besides supporting all SNMP versions out-of-the-box, it will automatically translate SNMPv1 TRAP PDU into SNMPv2 TRAP PDU so your code won’t have to deal with the differences. > On 18 Dec 2015, at 23:54, Gilmar Sinhorin <gil...@er...> wrote: > > Hi All, > I would like your help to figure out the problem I am experiencing for getting the enterprise. I am using the Notification Receiver code from this link > http://pysnmp.sourceforge.net/examples/current/v1arch/manager/ntfrcv/v2c-multiple-transports.html <http://pysnmp.sourceforge.net/examples/current/v1arch/manager/ntfrcv/v2c-multiple-transports.html>. I also get the AgentAddr, GenericTrap, SpecificTrap, TimeStamp attributes failed to be fetching. The getVarBindList method is working. > > I copied an past the trace logs when the failure happened. I hope it helps identify the issue. > > Please let me know if you need further detail. > > Thanks in advance for your help. > Regards, > Gilmar Sinhorin > > --------------------------------------------------------------------------------------------------------------------------------------- > > Traceback (most recent call last): > File "/usr/lib/python2.7/pdb.py", line 1314, in main > pdb._runscript(mainpyfile) > File "/usr/lib/python2.7/pdb.py", line 1233, in _runscript > self.run(statement) > File "/usr/lib/python2.7/bdb.py", line 400, in run > exec cmd in globals, locals > File "<string>", line 1, in <module> > File "ntfyReceiverV02.py", line 11, in <module> > ''' > File "/usr/lib/python2.7/dist-packages/pysnmp/carrier/asynsock/dispatch.py", line 33, in runDispatcher > poll(timeout and timeout or self.timeout, self.__sockMap) > File "/usr/lib/python2.7/asyncore.py", line 156, in poll > read(obj) > File "/usr/lib/python2.7/asyncore.py", line 87, in read > obj.handle_error() > File "/usr/lib/python2.7/asyncore.py", line 83, in read > obj.handle_read_event() > File "/usr/lib/python2.7/asyncore.py", line 447, in handle_read_event > self.handle_read() > File "/usr/lib/python2.7/dist-packages/pysnmp/carrier/asynsock/dgram/base.py", line 73, in handle_read > self._cbFun(self, transportAddress, incomingMessage) > File "/usr/lib/python2.7/dist-packages/pysnmp/carrier/base.py", line 46, in _cbFun > self, transportDomain, transportAddress, incomingMessage > File "ntfyReceiverV02.py", line 44, in cbFun > print('Enterprise: %s' % (trapPDU.getEnterprise(reqPDU).prettyPrint())) > AttributeError: TrapPDUAPI instance has no attribute 'getEnterprise' > Uncaught exception. Entering post mortem debugging > Running 'cont' or 'step' will restart the program |
From: Gilmar S. <gil...@er...> - 2015-12-18 22:54:38
|
Hi All, I would like your help to figure out the problem I am experiencing for getting the enterprise. I am using the Notification Receiver code from this link http://pysnmp.sourceforge.net/examples/current/v1arch/manager/ntfrcv/v2c-multiple-transports.html. I also get the AgentAddr, GenericTrap, SpecificTrap, TimeStamp attributes failed to be fetching. The getVarBindList method is working. I copied an past the trace logs when the failure happened. I hope it helps identify the issue. Please let me know if you need further detail. Thanks in advance for your help. Regards, Gilmar Sinhorin --------------------------------------------------------------------------------------------------------------------------------------- Traceback (most recent call last): File "/usr/lib/python2.7/pdb.py", line 1314, in main pdb._runscript(mainpyfile) File "/usr/lib/python2.7/pdb.py", line 1233, in _runscript self.run(statement) File "/usr/lib/python2.7/bdb.py", line 400, in run exec cmd in globals, locals File "<string>", line 1, in <module> File "ntfyReceiverV02.py", line 11, in <module> ''' File "/usr/lib/python2.7/dist-packages/pysnmp/carrier/asynsock/dispatch.py", line 33, in runDispatcher poll(timeout and timeout or self.timeout, self.__sockMap) File "/usr/lib/python2.7/asyncore.py", line 156, in poll read(obj) File "/usr/lib/python2.7/asyncore.py", line 87, in read obj.handle_error() File "/usr/lib/python2.7/asyncore.py", line 83, in read obj.handle_read_event() File "/usr/lib/python2.7/asyncore.py", line 447, in handle_read_event self.handle_read() File "/usr/lib/python2.7/dist-packages/pysnmp/carrier/asynsock/dgram/base.py", line 73, in handle_read self._cbFun(self, transportAddress, incomingMessage) File "/usr/lib/python2.7/dist-packages/pysnmp/carrier/base.py", line 46, in _cbFun self, transportDomain, transportAddress, incomingMessage File "ntfyReceiverV02.py", line 44, in cbFun print('Enterprise: %s' % (trapPDU.getEnterprise(reqPDU).prettyPrint())) AttributeError: TrapPDUAPI instance has no attribute 'getEnterprise' Uncaught exception. Entering post mortem debugging Running 'cont' or 'step' will restart the program |
From: Ilya E. <il...@gl...> - 2015-12-12 15:39:32
|
Hi Michael, That should be possible, however there is no specialized API for such things in pysnmp. I can advise listening on the __add__() method of SNMP counters objects and fire traps when an increment is detected. SNMP engine maintains a large collection of counters, each has specific meaning and they all are specified in SNMP RFCs. You should be looking for those counters in RFC2576 (SNMP communities) and RFC3414 (USM). Off the top of my head, you may be interested in SNMPv2-MIB::snmpInBadCommunityNames SNMP-USER-BASED-SM-MIB::usmStatsWrongDigests SNMP-USER-BASED-SM-MIB::usmStatsDecryptionErrors SNMP-USER-BASED-SM-MIB::usmStatsUnsupportedSecLevels SNMP-USER-BASED-SM-MIB::usmStatsUnknownUserNames To “listen” for increment event you could monkey parch __add__() method or subclass original class and replace original counter object with your implementation. Here’s a quick prototype: —— from pysnmp.smi import builder from pysnmp.proto.rfc1902 import Counter32 # Use snmpEngine.msgAndPduDsp.mibInstrumController.mibBuilder to get hold on SNMP engine’s MIB tree mibBuilder = builder.MibBuilder() class MyCounter32(Counter32): def __add__(self, value): print('sending auth trap') return Counter32.__add__(self, value) snmpInBadCommunityNames, = mibBuilder.importSymbols('__SNMPv2-MIB', 'snmpInBadCommunityNames') snmpInBadCommunityNames.syntax = MyCounter32(0) print(snmpInBadCommunityNames.syntax) # this is what SNMP engine does internally snmpInBadCommunityNames.syntax += 1 print(snmpInBadCommunityNames.syntax) # this is what SNMP engine does internally snmpInBadCommunityNames.syntax += 1 print(snmpInBadCommunityNames.syntax) —— Make sure to use the latest pysnmp (4.3.2 from CVS) to make sure the counters are incremented via +=. Sending traps should be easy, just make sure to reuse SnmpEngine object. No need to call stuff like runDispatcher() to push trap out, that would be done automatically by the main loop once trap message is queued. Alternatively to sending traps, you can snmpwalk your running SNMP agent to read all these counters via SNMP and note increments. > On 09 Dec 2015, at 18:20, Michael R Anderson <mic...@gm...> wrote: > > Hi Ilya, > I'm past all the previous problems with you help. > I need to send a Authentication Failure trap if an snmp request passes > incorrect credentials (such as v2 community, or v3 community, user, > md5, des). Can pysnmp be configured to send the trap automatically on > auth failure? > > If not, can I supply it with a call-back to be used if there is a auth > failure so I can send the trap myself? > > Thanks. > > -Mike > > On Wed, Nov 18, 2015 at 2:11 PM, Ilya Etingof <il...@gl...> wrote: >> >> Hi Michael, >> >> From the code snippet you sent, it’s hard to figure out what exactly is the problem. Also ‘thread’ module is somewhat low-level… >> >> I’ve run a quick test with pysnmp 4.3.1 and the 'threading’ module having three independent SNMP engines (managers) running in three threads plus one raw_input() loop in the other. >> >> So it seems to work alright (see attached). >> >> -ilya >> >> >>> On 16 Nov 2015, at 21:41, Michael R Anderson <mic...@gm...> wrote: >>> >>> Hi Ilya, >>> Yes, the snmp part is already in it's own thread. >>> >>> def snmp_thread(self): >>> self.snmp_server_running = True >>> logging.getLogger(__name__).info("xfsnmp:snmp_thread: snmp >>> thread started") >>> self.snmpEngine.transportDispatcher.runDispatcher() # will run >>> forever until jobFinished. >>> logging.getLogger(__name__).info("xfsnmp:snmp_thread: 1") >>> self.snmpEngine.transportDispatcher.closeDispatcher() >>> logging.getLogger(__name__).info("xfsnmp:snmp_thread: 2") >>> self.snmp_server_running = False >>> logging.getLogger(__name__).info("xfsnmp:snmp_thread: 3") >>> sys.stdout.flush();sys.stderr.flush() >>> >>> def start_snmp_server(self): >>> # use specific flags or 'all' for full debugging >>> debug.setLogger(debug.Debug('all')) >>> logging.getLogger(__name__).info("xfsnmp:start_snmp_server: >>> starting snmp server") >>> logging.getLogger(__name__).info("xfsnmp:start_snmp_server: 0") >>> print "sock map", self.snmpEngine.transportDispatcher.getSocketMap() >>> #mySockMap = {} >>> #self.snmpEngine.transportDispatcher.setSocketMap(mySockMap) >>> # register a job - this will keep the dispatcher running until >>> it is unregistered(jobFinished). >>> self.snmpEngine.transportDispatcher.jobStarted(1) >>> logging.getLogger(__name__).info("xfsnmp:start_snmp_server: 1") >>> thread.start_new_thread(self.snmp_thread, ()) >>> logging.getLogger(__name__).info("xfsnmp:start_snmp_server: 2") >>> sys.stdout.flush();sys.stderr.flush() >>> >>> The logging output shows that once runDispatcher() is executed, cly no >>> longer accepts any keyboard input. Until eunDispatcher() cly accepts >>> input and if I comment out only the runDispatcher()/closeDipatcher() >>> lines cly continues to accept input. Having the snmp part in it's own >>> thread doesn't seem to prevent runDispatcher() from stopping cly from >>> accepting input. >>> >>> I'm continuing to look into why this is. Thanks. >>> >>> -Mike >>> >>> >>> >>> On Mon, Nov 16, 2015 at 12:29 PM, Ilya Etingof <il...@gl...> wrote: >>>> Hi Michael, >>>> >>>> SNMP does not touch stdin but blocks on waiting for UDP socket to receive response packet from remove server. In the same time cly blocks waiting on stdin's file descriptor (FD) for your input (yes, raw_input() is blocking by default). Whenever you have a single thread of execution in your program and two blocking calls, you have to execute one or the other at a time. Unless you 1) put one of these calls to a parallel thread of execution or 2) make both blocking calls cooperating thus letting the other one to run while its fellow would block. The first approach is known as a multi-threading design, while the latter is called asynchronous I/O. >>>> >>>> In your case MT might be easier to implement, so I’d try it first. In fact I had an impression that you already did that by putting SNMP part into a dedicated thread (via the threading module). >>>> >>>> Async requires more effort and mind wrapping. The idea is that you switch potentially blocking FDs (sockets) into a non-blocking mode, then pass a collection of them to a dispatcher (select(), poll() etc.) that will watch them for readiness. Once one FD/socket is ready, you could pass it to read()/recvfrom() calls to perform actual I/O. No blocking is done if you do read from FD that has nothing to return - it will indicate that with an error immediately. The only waiting entity with this design is the dispatcher. >>>> >>>> I’ve come across many discussion on the topic: >>>> >>>> https://repolinux.wordpress.com/2012/10/09/non-blocking-read-from-stdin-in-python/ >>>> >>>> Hope this helps, >>>> Ilya >>>> >>>> >>>>> On 15 Nov 2015, at 04:31, Michael R Anderson <mic...@gm...> wrote: >>>>> >>>>> Hi Ilya, >>>>> I didn't mean to say the pysnmp thread blocks the cly thread or vice >>>>> versa. Just that executing rundispather() stopped the command line >>>>> input from reaching cly. That's all I meant. >>>>> >>>>> Is the problem raw_input blocking I/O? Or is it that only one of cly >>>>> or pysnmp reads all input (stdin and port 161), keeps what the map >>>>> says to recognize, ignores the rest, and starves the other of it's >>>>> input? Or did I misunderstand? If that is correct, then if I combine >>>>> the input map from cly with that for pysnmp, either using cly to drive >>>>> or snmp to drive, then somehow I have to get the input (from >>>>> stdin/port 161) from whichever read it to the other. >>>>> >>>>> Is that about right? Any better alternative. >>>>> >>>>> Thanks, >>>>> -Mike >>>>> >>>>> On Sat, Nov 14, 2015 at 12:14 PM, Ilya Etingof <il...@gl...> wrote: >>>>>> >>>>>> The first thing I do not quite understand is why your SNMP call blocks >>>>>> (?) your cly app if your (blocking) pysnmp code runs in a dedicated >>>>>> thread. Can you please elaborate on that point? >>>>>> >>>>>> Alternatively, as Craig says, you may try to switch your stdin file >>>>>> descriptor into non-blocking mode and serve both FD's (SNMP and stdin) >>>>>> by a single select() within a main loop. >>>>>> >>>>>> To start with the second approach, I'd investigate the way how to extent >>>>>> ply input driver to run non-blocking and being managed by a select(). >>>>>> I've looked at the ply code: >>>>>> >>>>>> https://github.com/alecthomas/cly/blob/master/cly/interactive.py >>>>>> >>>>>> so ReadlineDriver class is the place that should probably be >>>>>> hacked/extended to replace blocking raw_inpit() with a non-blocking and >>>>>> select()-managed version like discussed here: >>>>>> >>>>>> http://stackoverflow.com/questions/9027311/how-to-make-non-blocking-raw-input-when-using-eventlet-monkey-patch-and-why-it >>>>>> >>>>>> Once this is working, I could elaborate on >>>>>> two-FDs-been-managed-by-single-select thing. I will probably try to come >>>>>> up with an example script to make it generally useful. >>>>>> >>>>>> -ilya >>>>>> >>>>>> On 11/12/2015 11:15 AM, Craig Small wrote: >>>>>>> Avtually re-reading your email, its not two sockets its an interactive >>>>>>> terminal and a socket. What you can do is put your stdin socket (well >>>>>>> FD) into the socket map. That way the select() is looking at both your >>>>>>> network SNMP socket/fd and your keyboard stdin >>>>>>> >>>>>>> - Craig >>>>>>> >>>>>>> >>>>>>> On Thu, Nov 12, 2015 at 9:09 PM Craig Small <cs...@en... >>>>>>> <mailto:cs...@en...>> wrote: >>>>>>> >>>>>>> >>>>>>> Get's a bit tricky with sockets floating around. What I had to do >>>>>>> was create a new SNMP engine and dispatcher that used my own >>>>>>> socket_map. The socket_map is important because this is what the >>>>>>> select() system calls to listen for the sockets. You can have only >>>>>>> one select() >>>>>>> >>>>>>> You then need to run the dispatcher's jobsArePending and >>>>>>> handleTimerTick to keep the the snmp dispatcher happy. >>>>>>> >>>>>>> I then have the the socket running select(), because you have used >>>>>>> YOUR socket_map then pysnmp has added its socket to the map. >>>>>>> I asked almost the very same thing and Ilya responded here: >>>>>>> >>>>>>> http://sourceforge.net/p/pysnmp/mailman/message/31494830/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thu, Nov 12, 2015 at 11:57 AM Michael R Anderson >>>>>>> <mic...@gm... <mailto:mic...@gm...>> >>>>>>> wrote: >>>>>>> >>>>>>> I am using cly to drive my CLI. It works great. I recently added >>>>>>> pysmp. Now when it gets to runDispatcher() (in it's own thread), it >>>>>>> looks like my CLI input line gets hijacked so that no more command >>>>>>> line input can be done. >>>>>>> >>>>>>> I read runDispacther uses an I/O mainloop somehow. Can this be >>>>>>> causing my CLI is no responsive problem? >>>>>>> >>>>>>> Any suggestions? >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> _______________________________________________ >>>>>>> pysnmp-users mailing list >>>>>>> pys...@li... >>>>>>> <mailto:pys...@li...> >>>>>>> https://lists.sourceforge.net/lists/listinfo/pysnmp-users >>>>>>> >>>>>>> -- >>>>>>> Craig Small (@smallsees) http://enc.com.au/ csmall at : >>>>>>> enc.com.au <http://enc.com.au> >>>>>>> Debian GNU/Linux http://www.debian.org/ csmall at : >>>>>>> debian.org <http://debian.org> >>>>>>> GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B >>>>>>> DF50 FEA5 >>>>>>> >>>>>>> -- >>>>>>> Craig Small (@smallsees) http://enc.com.au/ csmall at : >>>>>>> enc.com.au <http://enc.com.au> >>>>>>> Debian GNU/Linux http://www.debian.org/ csmall at : >>>>>>> debian.org <http://debian.org> >>>>>>> GPG fingerprint: 5D2F B320 B825 D939 04D2 0519 3938 F96B DF50 FEA5 >>>>>>> >>>>>>> >>>>>>> ------------------------------------------------------------------------------ >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> pysnmp-users mailing list >>>>>>> pys...@li... >>>>>>> https://lists.sourceforge.net/lists/listinfo/pysnmp-users >>>>>>> >>>> >> >> |
From: Ilya E. <il...@gl...> - 2015-11-21 09:47:37
|
Hi, Looking at the current pysnmp/pyasn1 code I can’t see how it could possibly happen. What pysnmp/pyasn1 versions you are using? It not the latest ones, could you upgrade? Otherwise I’d need full output when Debug(‘mibbuild’, ‘mibinsrum’) is enabled to catch the moment of bad value entering the system. -ilya > On 21 Nov 2015, at 07:28, Abhishek Lahiri <lah...@gm...> wrote: > > Hi, > > My SNMP packages uses pysnmp for both sending /receiving SNMP queries and accept SNMP traps. However it seems to fail continuously after running successfully for some time. From the log I see : > > 2015-11-21 02:57:16,155 [8995] ERROR: SNMP Error:poll error: Traceback (most recent call last): > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/carrier/asynsock/dispatch.py", line 37, in runDispatcher > use_poll=True, map=self.__sockMap, count=1) > ; File "/usr/lib64/python2.6/asyncore.py", line 214, in loop > poll_fun(timeout, map) > ; File "/usr/lib64/python2.6/asyncore.py", line 195, in poll2 > readwrite(obj, flags) > ; File "/usr/lib64/python2.6/asyncore.py", line 119, in readwrite > obj.handle_error() > ; File "/usr/lib64/python2.6/asyncore.py", line 103, in readwrite > obj.handle_read_event() > ; File "/usr/lib64/python2.6/asyncore.py", line 428, in handle_read_event > self.handle_read() > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/carrier/asynsock/dgram/base.py", line 83, in handle_read > self._cbFun(self, transportAddress, incomingMessage) > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/carrier/base.py", line 52, in _cbFun > self, transportDomain, transportAddress, incomingMessage > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/entity/engine.py", line 64, in __receiveMessageCbFun > self, transportDomain, transportAddress, wholeMsg > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/rfc3412.py", line 319, in receiveMessage > wholeMsg > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/mpmod/rfc2576.py", line 276, in prepareDataElements > msg > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/secmod/rfc2576.py", line 398, in processIncomingMsg > snmpEngine, communityName, transportInformation > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/secmod/rfc2576.py", line 260, in _com2sec > if _tagAndCommunity not in self.__tagAndCommunityToSecurityMap: > ;TypeError: __hash__() should return an int > . > Traceback (most recent call last): > File "/opt/mysnmp-package/lib/python2.6/site-packages/automationtools_probe/monitoring_agent.py", line 69, in checkEvent > lookupNames=True, lookupValues=True) > File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/entity/rfc3413/oneliner/cmdgen.py", line 541, in nextCmd > self.__asynCmdGen.snmpEngine.transportDispatcher.runDispatcher() > File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/carrier/asynsock/dispatch.py", line 41, in runDispatcher > raise PySnmpError('poll error: %s' % ';'.join(format_exception(*exc_info()))) > PySnmpError: poll error: Traceback (most recent call last): > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/carrier/asynsock/dispatch.py", line 37, in runDispatcher > use_poll=True, map=self.__sockMap, count=1) > ; File "/usr/lib64/python2.6/asyncore.py", line 214, in loop > poll_fun(timeout, map) > ; File "/usr/lib64/python2.6/asyncore.py", line 195, in poll2 > readwrite(obj, flags) > ; File "/usr/lib64/python2.6/asyncore.py", line 119, in readwrite > obj.handle_error() > ; File "/usr/lib64/python2.6/asyncore.py", line 103, in readwrite > obj.handle_read_event() > ; File "/usr/lib64/python2.6/asyncore.py", line 428, in handle_read_event > self.handle_read() > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/carrier/asynsock/dgram/base.py", line 83, in handle_read > self._cbFun(self, transportAddress, incomingMessage) > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/carrier/base.py", line 52, in _cbFun > self, transportDomain, transportAddress, incomingMessage > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/entity/engine.py", line 64, in __receiveMessageCbFun > self, transportDomain, transportAddress, wholeMsg > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/rfc3412.py", line 319, in receiveMessage > wholeMsg > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/mpmod/rfc2576.py", line 276, in prepareDataElements > msg > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/secmod/rfc2576.py", line 398, in processIncomingMsg > snmpEngine, communityName, transportInformation > ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/secmod/rfc2576.py", line 260, in _com2sec > if _tagAndCommunity not in self.__tagAndCommunityToSecurityMap: > ;TypeError: __hash__() should return an int > > > If I turn on pysnmp debug I see the following. Looks like a null or empty community string is somehow getting populated but not sure how and if that is causing it to crash, > > tagAndCommunity (SnmpTagValue(''), OctetString('Secr3tPass')) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) > tagAndCommunity (SnmpTagValue(''), OctetString('Secr3tPass')) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) > tagAndCommunity (SnmpTagValue(''), OctetString('Secr3tPass')) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) > tagAndCommunity (SnmpTagValue(''), OctetString('Secr3tPass')) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) > tagAndCommunity (SnmpTagValue(''), OctetString()) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) > Error __hash__() should return an int tagAndCommunity (SnmpTagValue(''), OctetString()) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) > tagAndCommunity (SnmpTagValue(''), OctetString()) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) > Error __hash__() should return an int tagAndCommunity (SnmpTagValue(''), OctetString()) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) > tagAndCommunity (SnmpTagValue(''), OctetString()) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) > Error __hash__() should return an int tagAndCommunity (SnmpTagValue(''), OctetString()) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) > > TIA > ------------------------------------------------------------------------------ > _______________________________________________ > pysnmp-users mailing list > pys...@li... > https://lists.sourceforge.net/lists/listinfo/pysnmp-users |
From: Abhishek L. <lah...@gm...> - 2015-11-21 06:28:14
|
Hi, My SNMP packages uses pysnmp for both sending /receiving SNMP queries and accept SNMP traps. However it seems to fail continuously after running successfully for some time. From the log I see : 2015-11-21 02:57:16,155 [8995] ERROR: SNMP Error:poll error: Traceback (most recent call last): ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/carrier/asynsock/dispatch.py", line 37, in runDispatcher use_poll=True, map=self.__sockMap, count=1) ; File "/usr/lib64/python2.6/asyncore.py", line 214, in loop poll_fun(timeout, map) ; File "/usr/lib64/python2.6/asyncore.py", line 195, in poll2 readwrite(obj, flags) ; File "/usr/lib64/python2.6/asyncore.py", line 119, in readwrite obj.handle_error() ; File "/usr/lib64/python2.6/asyncore.py", line 103, in readwrite obj.handle_read_event() ; File "/usr/lib64/python2.6/asyncore.py", line 428, in handle_read_event self.handle_read() ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/carrier/asynsock/dgram/base.py", line 83, in handle_read self._cbFun(self, transportAddress, incomingMessage) ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/carrier/base.py", line 52, in _cbFun self, transportDomain, transportAddress, incomingMessage ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/entity/engine.py", line 64, in __receiveMessageCbFun self, transportDomain, transportAddress, wholeMsg ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/rfc3412.py", line 319, in receiveMessage wholeMsg ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/mpmod/rfc2576.py", line 276, in prepareDataElements msg ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/secmod/rfc2576.py", line 398, in processIncomingMsg snmpEngine, communityName, transportInformation ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/secmod/rfc2576.py", line 260, in _com2sec if _tagAndCommunity not in self.__tagAndCommunityToSecurityMap: ;TypeError: __hash__() should return an int . Traceback (most recent call last): File "/opt/mysnmp-package/lib/python2.6/site-packages/automationtools_probe/monitoring_agent.py", line 69, in checkEvent lookupNames=True, lookupValues=True) File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/entity/rfc3413/oneliner/cmdgen.py", line 541, in nextCmd self.__asynCmdGen.snmpEngine.transportDispatcher.runDispatcher() File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/carrier/asynsock/dispatch.py", line 41, in runDispatcher raise PySnmpError('poll error: %s' % ';'.join(format_exception(*exc_info()))) PySnmpError: poll error: Traceback (most recent call last): ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/carrier/asynsock/dispatch.py", line 37, in runDispatcher use_poll=True, map=self.__sockMap, count=1) ; File "/usr/lib64/python2.6/asyncore.py", line 214, in loop poll_fun(timeout, map) ; File "/usr/lib64/python2.6/asyncore.py", line 195, in poll2 readwrite(obj, flags) ; File "/usr/lib64/python2.6/asyncore.py", line 119, in readwrite obj.handle_error() ; File "/usr/lib64/python2.6/asyncore.py", line 103, in readwrite obj.handle_read_event() ; File "/usr/lib64/python2.6/asyncore.py", line 428, in handle_read_event self.handle_read() ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/carrier/asynsock/dgram/base.py", line 83, in handle_read self._cbFun(self, transportAddress, incomingMessage) ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/carrier/base.py", line 52, in _cbFun self, transportDomain, transportAddress, incomingMessage ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/entity/engine.py", line 64, in __receiveMessageCbFun self, transportDomain, transportAddress, wholeMsg ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/rfc3412.py", line 319, in receiveMessage wholeMsg ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/mpmod/rfc2576.py", line 276, in prepareDataElements msg ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/secmod/rfc2576.py", line 398, in processIncomingMsg snmpEngine, communityName, transportInformation ; File "/opt/mysnmp-package/lib/python2.6/site-packages/pysnmp/proto/secmod/rfc2576.py", line 260, in _com2sec if _tagAndCommunity not in self.__tagAndCommunityToSecurityMap: ;TypeError: __hash__() should return an int If I turn on pysnmp debug I see the following. Looks like a null or empty community string is somehow getting populated but not sure how and if that is causing it to crash, tagAndCommunity (SnmpTagValue(''), OctetString('Secr3tPass')) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) tagAndCommunity (SnmpTagValue(''), OctetString('Secr3tPass')) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) tagAndCommunity (SnmpTagValue(''), OctetString('Secr3tPass')) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) tagAndCommunity (SnmpTagValue(''), OctetString('Secr3tPass')) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) tagAndCommunity (SnmpTagValue(''), OctetString()) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) Error __hash__() should return an int tagAndCommunity (SnmpTagValue(''), OctetString()) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) tagAndCommunity (SnmpTagValue(''), OctetString()) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) Error __hash__() should return an int tagAndCommunity (SnmpTagValue(''), OctetString()) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) tagAndCommunity (SnmpTagValue(''), OctetString()) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) Error __hash__() should return an int tagAndCommunity (SnmpTagValue(''), OctetString()) targetaddress MibTableColumn((1, 3, 6, 1, 6, 3, 12, 1, 2, 1, 3), TAddress()) TIA |
From: Ilya E. <il...@gl...> - 2015-11-20 08:47:18
|
...or, if you are not interested in MIB-resolved values, just pass lookupMib=False to getCmd()/nextCmd() functions. No MIB lookup will be done and this issue won't be hit. On 11/20/2015 09:42 AM, Ilya Etingof wrote: > > Hi Wei, > > Yes, the hack is to edit the bsnAPIfDot11CountryString value at > AIRESPACE-WIRELESS-MIB.py module by hand to allow larger values: > > bsnAPIfDot11CountryString = ... subtypeSpec=ValueSizeConstraint(3,5) ... > > -ilya > > On 11/20/2015 04:19 AM, Wei Wang wrote: >> I believe the MIB object that throw off pysnmp is this one: >> AIRESPACE-WIRELESS-MIB::bsnAPIfDot11CountryString >> (.1.3.6.1.4.1.14179.2.2.3.1.9) >> >> It is supposed to be size limited to 3 based on the MIB: >> >> bsnAPIfDot11CountryString OBJECT-TYPE >> SYNTAX OCTET STRING (SIZE(3)) >> MAX-ACCESS read-only >> STATUS current >> >> I am not sure how the payload is packaged exactly, but here is what I >> got from Net-SNMP's snmpwalk program: >> >> .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.56.240.0 = Hex-STRING: 55 53 20 >> 00 00 00 >> .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.56.240.1 = Hex-STRING: 55 53 20 >> 00 00 00 >> .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.58.224.0 = Hex-STRING: 55 53 20 >> 00 00 00 >> .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.58.224.1 = Hex-STRING: 55 53 20 >> 00 00 00 >> .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.64.160.0 = Hex-STRING: 55 53 20 >> 00 00 00 >> .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.64.160.1 = Hex-STRING: 55 53 20 >> 00 00 00 >> >> Looks like every single value is packaged with a 6-octet value. >> >> Is there anyway to fix / workaround this? >> >> On Thu, Nov 19, 2015 at 3:50 PM, Ilya Etingof <il...@gl... >> <mailto:il...@gl...>> wrote: >> >> You are right. But the constraint is set in MIB, pyasn1 code you >> found just verifies a value against that constraint. So you should >> blame your SNMP agent for wrong data or your MIB for constraint. ;) >> >> |
From: Ilya E. <il...@gl...> - 2015-11-20 08:42:52
|
Hi Wei, Yes, the hack is to edit the bsnAPIfDot11CountryString value at AIRESPACE-WIRELESS-MIB.py module by hand to allow larger values: bsnAPIfDot11CountryString = ... subtypeSpec=ValueSizeConstraint(3,5) ... -ilya On 11/20/2015 04:19 AM, Wei Wang wrote: > I believe the MIB object that throw off pysnmp is this one: > AIRESPACE-WIRELESS-MIB::bsnAPIfDot11CountryString > (.1.3.6.1.4.1.14179.2.2.3.1.9) > > It is supposed to be size limited to 3 based on the MIB: > > bsnAPIfDot11CountryString OBJECT-TYPE > SYNTAX OCTET STRING (SIZE(3)) > MAX-ACCESS read-only > STATUS current > > I am not sure how the payload is packaged exactly, but here is what I > got from Net-SNMP's snmpwalk program: > > .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.56.240.0 = Hex-STRING: 55 53 20 > 00 00 00 > .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.56.240.1 = Hex-STRING: 55 53 20 > 00 00 00 > .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.58.224.0 = Hex-STRING: 55 53 20 > 00 00 00 > .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.58.224.1 = Hex-STRING: 55 53 20 > 00 00 00 > .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.64.160.0 = Hex-STRING: 55 53 20 > 00 00 00 > .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.64.160.1 = Hex-STRING: 55 53 20 > 00 00 00 > > Looks like every single value is packaged with a 6-octet value. > > Is there anyway to fix / workaround this? > > On Thu, Nov 19, 2015 at 3:50 PM, Ilya Etingof <il...@gl... > <mailto:il...@gl...>> wrote: > > You are right. But the constraint is set in MIB, pyasn1 code you > found just verifies a value against that constraint. So you should > blame your SNMP agent for wrong data or your MIB for constraint. ;) > > |
From: Wei W. <ww...@9r...> - 2015-11-20 03:20:27
|
I believe the MIB object that throw off pysnmp is this one: AIRESPACE-WIRELESS-MIB::bsnAPIfDot11CountryString (.1.3.6.1.4.1.14179.2.2.3.1.9) It is supposed to be size limited to 3 based on the MIB: bsnAPIfDot11CountryString OBJECT-TYPE SYNTAX OCTET STRING (SIZE(3)) MAX-ACCESS read-only STATUS current I am not sure how the payload is packaged exactly, but here is what I got from Net-SNMP's snmpwalk program: .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.56.240.0 = Hex-STRING: 55 53 20 00 00 00 .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.56.240.1 = Hex-STRING: 55 53 20 00 00 00 .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.58.224.0 = Hex-STRING: 55 53 20 00 00 00 .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.58.224.1 = Hex-STRING: 55 53 20 00 00 00 .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.64.160.0 = Hex-STRING: 55 53 20 00 00 00 .1.3.6.1.4.1.14179.2.2.3.1.9.0.20.27.88.64.160.1 = Hex-STRING: 55 53 20 00 00 00 Looks like every single value is packaged with a 6-octet value. Is there anyway to fix / workaround this? On Thu, Nov 19, 2015 at 3:50 PM, Ilya Etingof <il...@gl...> wrote: > You are right. But the constraint is set in MIB, pyasn1 code you found > just verifies a value against that constraint. So you should blame your > SNMP agent for wrong data or your MIB for constraint. ;) > |
From: Ilya E. <il...@gl...> - 2015-11-19 20:50:47
|
You are right. But the constraint is set in MIB, pyasn1 code you found just verifies a value against that constraint. So you should blame your SNMP agent for wrong data or your MIB for constraint. ;) > On 19 Nov 2015, at 17:21, Wei Wang <ww...@9r...> wrote: > > I added a couple of lines to the spot where the SmiError is raised and got this on my console: > > Traceback (most recent call last): > File "/usr/local/lib/python2.7/dist-packages/pysnmp/smi/rfc1902.py", line 727, in resolveWithMib > self.__args[1] = self.__args[0].getMibNode().getSyntax().clone(self.__args[1]) > File "/usr/local/lib/python2.7/dist-packages/pysnmp/proto/rfc1902.py", line 187, in clone > self, value, tagSet, subtypeSpec, encoding, binValue, hexValue > File "/usr/local/lib/python2.7/dist-packages/pyasn1/type/univ.py", line 328, in clone > value, tagSet, subtypeSpec, encoding, binValue, hexValue > File "/usr/local/lib/python2.7/dist-packages/pyasn1/type/univ.py", line 312, in __init__ > base.AbstractSimpleAsn1Item.__init__(self, value, tagSet, subtypeSpec) > File "/usr/local/lib/python2.7/dist-packages/pyasn1/type/base.py", line 75, in __init__ > self._verifySubtypeSpec(value) > File "/usr/local/lib/python2.7/dist-packages/pyasn1/type/base.py", line 33, in _verifySubtypeSpec > raise c('%s at %s' % (i, self.__class__.__name__)) > PyAsn1Error: ConstraintsIntersection(ConstraintsIntersection(ConstraintsIntersection(), ValueSizeConstraint(0, 65535)), ValueSizeConstraint(3, 3)) failed at: "ValueSizeConstraint(3, 3) failed at: "US "" at OctetString > > So, it look that my suspicion was correct: There is a size constraint of 3 on the data, the pyasn1/type/base.py module did not like the 5-byte data it received. |
From: Ilya E. <il...@gl...> - 2015-11-19 20:48:08
|
Hi Wei, So we are dealing with two irrelevant problems. This is related to the situation when your agent send you a value in response that does not fit MIB specification for it. With current pysnmp code it is not obvious what OID caused this, you may want to enable pysnmp debugging to figure that out (I’ll improve this exception shortly). Once you know what OID (e.g. MIB object) fails, you may fix/hack the constraints in your MIB to accommodate currently rejected value. Why this happens? I can think of two possibilities: * you are using somewhat obsolete MIB, may be later a version exists that allows that value * your agent works against MIB specification due to a bug -ilya > On 18 Nov 2015, at 23:01, Wei Wang <ww...@9r...> wrote: > > Made a bit of progress, with this manual MIB file compilation: > > mibdump.py /opt/nss/etc/snmp/mibs/cisco/AIRESPACE-WIRELESS-MIB.mib > > That created two MIB files in the .py format in ~/.pysnmp/mibs folder. > > But my code still throws exception: > > 2015-11-18 16:56:29,465 ERROR base_events.default_exception_handler:1053 Exception in callback _cbFun(<pysnmp....a2b44e90>, ('10.50.0.12', 161), '0\x82\x06[\x... \x00\x00\x00') > handle: <Handle _cbFun(<pysnmp....a2b44e90>, ('10.50.0.12', 161), '0\x82\x06[\x... \x00\x00\x00')> > Traceback (most recent call last): > File "/usr/local/lib/python2.7/dist-packages/trollius/events.py", line 136, in _run > self._callback(*self._args) > File "/usr/local/lib/python2.7/dist-packages/pysnmp/carrier/base.py", line 63, in _cbFun > self, transportDomain, transportAddress, incomingMessage > File "/usr/local/lib/python2.7/dist-packages/pysnmp/entity/engine.py", line 140, in __receiveMessageCbFun > self, transportDomain, transportAddress, wholeMsg > File "/usr/local/lib/python2.7/dist-packages/pysnmp/proto/rfc3412.py", line 453, in receiveMessage > cachedParams['cbCtx']) > File "/usr/local/lib/python2.7/dist-packages/pysnmp/entity/rfc3413/cmdgen.py", line 125, in processResponsePdu > cbFun(snmpEngine, origSendRequestHandle, None, PDU, cbCtx) > File "/usr/local/lib/python2.7/dist-packages/pysnmp/entity/rfc3413/cmdgen.py", line 349, in processResponseVarBinds > varBindTable, cbCtx): > File "/usr/local/lib/python2.7/dist-packages/pysnmp/hlapi/asyncio/cmdgen.py", line 440, in __cbFun > (errorIndication, errorStatus, errorIndex, [vbProcessor.unmakeVarBinds(snmpEngine, varBindTableRow, lookupMib) for varBindTableRow in varBindTable]) > File "/usr/local/lib/python2.7/dist-packages/pysnmp/hlapi/varbinds.py", line 37, in unmakeVarBinds > varBinds = [ObjectType(ObjectIdentity(x[0]), x[1]).resolveWithMib(mibViewController) for x in varBinds] > File "/usr/local/lib/python2.7/dist-packages/pysnmp/smi/rfc1902.py", line 728, in resolveWithMib > raise SmiError('Value %r to type %r convertion failure: %s' % (self.__args[1], self.__args[0].getMibNode().getSyntax().__class__.__name__, sys.exc_info()[1])) > SmiError: Value OctetString(hexValue='555320000000') to type 'OctetString' convertion failure: ConstraintsIntersection(ConstraintsIntersection(ConstraintsIntersection(), ValueSizeConstraint(0, 65535)), ValueSizeConstraint(3, 3)) failed at: "ValueSizeConstraint(3, 3) failed at: "US ^@^@^@"" at OctetString |
From: Wei W. <ww...@9r...> - 2015-11-19 16:22:13
|
I added a couple of lines to the spot where the SmiError is raised and got this on my console: Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/pysnmp/smi/rfc1902.py", line 727, in resolveWithMib self.__args[1] = self.__args[0].getMibNode().getSyntax().clone(self.__args[1]) File "/usr/local/lib/python2.7/dist-packages/pysnmp/proto/rfc1902.py", line 187, in clone self, value, tagSet, subtypeSpec, encoding, binValue, hexValue File "/usr/local/lib/python2.7/dist-packages/pyasn1/type/univ.py", line 328, in clone value, tagSet, subtypeSpec, encoding, binValue, hexValue File "/usr/local/lib/python2.7/dist-packages/pyasn1/type/univ.py", line 312, in __init__ base.AbstractSimpleAsn1Item.__init__(self, value, tagSet, subtypeSpec) File "/usr/local/lib/python2.7/dist-packages/pyasn1/type/base.py", line 75, in __init__ self._verifySubtypeSpec(value) File "/usr/local/lib/python2.7/dist-packages/pyasn1/type/base.py", line 33, in _verifySubtypeSpec raise c('%s at %s' % (i, self.__class__.__name__)) PyAsn1Error: ConstraintsIntersection(ConstraintsIntersection(ConstraintsIntersection(), ValueSizeConstraint(0, 65535)), ValueSizeConstraint(3, 3)) failed at: "ValueSizeConstraint(3, 3) failed at: "US "" at OctetString So, it look that my suspicion was correct: There is a size constraint of 3 on the data, the pyasn1/type/base.py module did not like the 5-byte data it received. |
From: Wei W. <ww...@9r...> - 2015-11-19 14:45:14
|
Hi, Ilya, Got the latest code from SF.net and installed from that. I am still getting the same error as I last reported. 2015-11-19 09:38:46,501 ERROR base_events.default_exception_handler:1053 Exception in callback _cbFun(<pysnmp....5dac71d0>, ('10.50.0.12', 161), '0\x82\x06\\\... \x00\x00\x00') handle: <Handle _cbFun(<pysnmp....5dac71d0>, ('10.50.0.12', 161), '0\x82\x06\\\... \x00\x00\x00')> Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/trollius/events.py", line 136, in _run self._callback(*self._args) File "/usr/local/lib/python2.7/dist-packages/pysnmp/carrier/base.py", line 63, in _cbFun self, transportDomain, transportAddress, incomingMessage File "/usr/local/lib/python2.7/dist-packages/pysnmp/entity/engine.py", line 140, in __receiveMessageCbFun self, transportDomain, transportAddress, wholeMsg File "/usr/local/lib/python2.7/dist-packages/pysnmp/proto/rfc3412.py", line 453, in receiveMessage cachedParams['cbCtx']) File "/usr/local/lib/python2.7/dist-packages/pysnmp/entity/rfc3413/cmdgen.py", line 125, in processResponsePdu cbFun(snmpEngine, origSendRequestHandle, None, PDU, cbCtx) File "/usr/local/lib/python2.7/dist-packages/pysnmp/entity/rfc3413/cmdgen.py", line 349, in processResponseVarBinds varBindTable, cbCtx): File "/usr/local/lib/python2.7/dist-packages/pysnmp/hlapi/asyncio/cmdgen.py", line 440, in __cbFun (errorIndication, errorStatus, errorIndex, [vbProcessor.unmakeVarBinds(snmpEngine, varBindTableRow, lookupMib) for varBindTableRow in varBindTable]) File "/usr/local/lib/python2.7/dist-packages/pysnmp/hlapi/varbinds.py", line 37, in unmakeVarBinds varBinds = [ObjectType(ObjectIdentity(x[0]), x[1]).resolveWithMib(mibViewController) for x in varBinds] File "/usr/local/lib/python2.7/dist-packages/pysnmp/smi/rfc1902.py", line 728, in resolveWithMib raise SmiError('Value %r to type %r convertion failure: %s' % (self.__args[1], self.__args[0].getMibNode().getSyntax().__class__.__name__, sys.exc_info()[1])) SmiError: Value OctetString(hexValue='555320000000') to type 'OctetString' convertion failure: ConstraintsIntersection(ConstraintsIntersection(ConstraintsIntersection(), ValueSizeConstraint(0, 65535)), ValueSizeConstraint(3, 3)) failed at: "ValueSizeConstraint(3, 3) failed at: "US "" at OctetString The octet string value in hex is "555320000000", which when break up into ASCII, would be U/55, S/53, (space)/20, and two more null/00 characters. Are the two null characters causing the problem. |
From: Wei W. <ww...@9r...> - 2015-11-18 22:11:49
|
Ilya: Thanks for the amazing support. I just did all that, except I could not find pysmi 0.0.7 -- 0.0.6 seems to be the latest on Pypi. I am still getting the same SmiError (Value OctetString(hexValue='555320000000') to type 'OctetString' convertion failure: ...) and no other debug message from pysmi. On Wed, Nov 18, 2015 at 4:54 PM, Ilya Etingof <il...@gl...> wrote: > > To troubleshoot the MIB compilation issue I’d advise: > > * Not a solution, but a quick cure: just run mibdump.py and collect > compiled MIBs from where it stores them. > I just checked, it works out-of-the-box pulling this and all required > MIBs from web: > > $ mibdump.py AIRESPACE-WIRELESS-MIB > > * Make sure you are running the latest version of pysmi from pypi (0.0.7) > > * Enable pysmi debugging in your script and re-run your script to see > where exactly it looks for MIB files: > > from pysmi import debug > debug.setLogger(debug.Debug(‘reader')) > > There’s documentation on pysmi internals, but it may be too low level in > this case: > > http://pysmi.sf.net > > -ilya > |
From: Wei W. <ww...@9r...> - 2015-11-18 22:02:14
|
Made a bit of progress, with this manual MIB file compilation: mibdump.py /opt/nss/etc/snmp/mibs/cisco/AIRESPACE-WIRELESS-MIB.mib That created two MIB files in the .py format in ~/.pysnmp/mibs folder. But my code still throws exception: 2015-11-18 16:56:29,465 ERROR base_events.default_exception_handler:1053 Exception in callback _cbFun(<pysnmp....a2b44e90>, ('10.50.0.12', 161), '0\x82\x06[\x... \x00\x00\x00') handle: <Handle _cbFun(<pysnmp....a2b44e90>, ('10.50.0.12', 161), '0\x82\x06[\x... \x00\x00\x00')> Traceback (most recent call last): File "/usr/local/lib/python2.7/dist-packages/trollius/events.py", line 136, in _run self._callback(*self._args) File "/usr/local/lib/python2.7/dist-packages/pysnmp/carrier/base.py", line 63, in _cbFun self, transportDomain, transportAddress, incomingMessage File "/usr/local/lib/python2.7/dist-packages/pysnmp/entity/engine.py", line 140, in __receiveMessageCbFun self, transportDomain, transportAddress, wholeMsg File "/usr/local/lib/python2.7/dist-packages/pysnmp/proto/rfc3412.py", line 453, in receiveMessage cachedParams['cbCtx']) File "/usr/local/lib/python2.7/dist-packages/pysnmp/entity/rfc3413/cmdgen.py", line 125, in processResponsePdu cbFun(snmpEngine, origSendRequestHandle, None, PDU, cbCtx) File "/usr/local/lib/python2.7/dist-packages/pysnmp/entity/rfc3413/cmdgen.py", line 349, in processResponseVarBinds varBindTable, cbCtx): File "/usr/local/lib/python2.7/dist-packages/pysnmp/hlapi/asyncio/cmdgen.py", line 440, in __cbFun (errorIndication, errorStatus, errorIndex, [vbProcessor.unmakeVarBinds(snmpEngine, varBindTableRow, lookupMib) for varBindTableRow in varBindTable]) File "/usr/local/lib/python2.7/dist-packages/pysnmp/hlapi/varbinds.py", line 37, in unmakeVarBinds varBinds = [ObjectType(ObjectIdentity(x[0]), x[1]).resolveWithMib(mibViewController) for x in varBinds] File "/usr/local/lib/python2.7/dist-packages/pysnmp/smi/rfc1902.py", line 728, in resolveWithMib raise SmiError('Value %r to type %r convertion failure: %s' % (self.__args[1], self.__args[0].getMibNode().getSyntax().__class__.__name__, sys.exc_info()[1])) SmiError: Value OctetString(hexValue='555320000000') to type 'OctetString' convertion failure: ConstraintsIntersection(ConstraintsIntersection(ConstraintsIntersection(), ValueSizeConstraint(0, 65535)), ValueSizeConstraint(3, 3)) failed at: "ValueSizeConstraint(3, 3) failed at: "US ^@^@^@"" at OctetString |
From: Ilya E. <il...@gl...> - 2015-11-18 21:55:02
|
To troubleshoot the MIB compilation issue I’d advise: * Not a solution, but a quick cure: just run mibdump.py and collect compiled MIBs from where it stores them. I just checked, it works out-of-the-box pulling this and all required MIBs from web: $ mibdump.py AIRESPACE-WIRELESS-MIB * Make sure you are running the latest version of pysmi from pypi (0.0.7) * Enable pysmi debugging in your script and re-run your script to see where exactly it looks for MIB files: from pysmi import debug debug.setLogger(debug.Debug(‘reader')) There’s documentation on pysmi internals, but it may be too low level in this case: http://pysmi.sf.net -ilya > On 18 Nov 2015, at 22:25, Wei Wang <ww...@9r...> wrote: > > Ilya, > > Thanks for the response. > > I compiled the MIBs from their text files into the .py files (using the build-pysnmp-mib tool in a version 4.2.5 installation on a different host, if that matters). > > The text MIB files are here: > https://raw.githubusercontent.com/ww9rivers/SnmpMibs/master/cisco/AIRESPACE-WIRELESS-MIB.mib > https://raw.githubusercontent.com/ww9rivers/SnmpMibs/master/cisco/AIRESPACE-REF-MIB.mib > > I took the .py files out of the pysnmp folder and put it locally. Here is how I have loaded the MIB files: > > varbinds = [ > ObjectType( > #ObjectIdentity('.1.3.6.1.4.1.14179.2.2.1.1') > ObjectIdentity('AIRESPACE-WIRELESS-MIB', 'bsnAPEntry') > ) > .addMibSource(os.path.abspath('.')) > .loadMibs('AIRESPACE-REF-MIB', 'AIRESPACE-WIRELESS-MIB') > ] > > Of course, I only had the .py files there. That made the code resolve object names but produced the same SmiError. > > With your latest email, I try to get pysnmp to auto-compile the MIBs: > > mibs = 'file:///opt/nss/etc/snmp/mibs' > varbinds = [ > ObjectType( > #ObjectIdentity('.1.3.6.1.4.1.14179.2.2.1.1') > ObjectIdentity('AIRESPACE-WIRELESS-MIB', 'bsnAPEntry') > ) > .addAsn1MibSource(mibs, os.path.join(mibs, 'cisco')) > .loadMibs('AIRESPACE-REF-MIB', 'AIRESPACE-WIRELESS-MIB') > ] > > But I am getting this error: > > MibNotFoundError: AIRESPACE-WIRELESS-MIB compilation error(s): missing; no module "SNMPv2-TC" in symbolTable at MIB AIRESPACE-WIRELESS-MIB > > I do have these files locally: > /opt/nss/etc/snmp/mibs/cisco/AIRESPACE-WIRELESS-MIB.mib > /opt/nss/etc/snmp/mibs/cisco/AIRESPACE-REF-MIB.mib > /opt/nss/etc/snmp/mibs/SNMPv2-TC.mib > > Then there is also this: > /usr/local/lib/python2.7/dist-packages/pysnmp/smi/mibs/SNMPv2-TC.py > > Why is it complaining about (no module "SNMPv2-TC" in symbolTable at MIB AIRESPACE-WIRELESS-MIB)? > > Without much documentation, I am moving forward with trial-and-error here. What do I need to make the MIB compilation work? > > Thanks! |
From: Vincent B. <be...@lu...> - 2015-11-18 21:49:02
|
❦ 18 novembre 2015 21:37 +0100, Ilya Etingof <il...@gl...> : >> So, I had a look at PySNMP 4.3 but it seems that CommandGenerator is no >> longer using AsynCommandGenerator. I can provide my own SnmpEngine but >> SnmpEngine is still not thread-safe. > > The 4.3 version has many changes. In particular, SNMP high-level API > has been unified across different transports and moved into > pysnmp.hlapi.* . > I’d advise not to use legacy interface > (e.g. pysnmp.entity.rfc3413.oneliner) for multithreading stuff - it > has many concurrency issues. > Use pysnmp.hlapi.asyncore or pysnmp.hlapi (synchronous) instead. Dully noted. However, I need to keep compatibility with PySNMP < 4.3 too. As I am currently using a local CommandGenerator for each thread, is that safe to use? >> 1. Having CommandGenerator as a singleton and using a single >> thread. This fails when spawning commands from the same command >> generator with different USM. This should not and using the >> structure of usmUserTable (which is for a single agent) to store >> stuff for a manager talking to multiple agents is a bad idea. The >> cache should not just be a usmUserTable. It should also be indexed >> by other security parameters or by the target agent (but we don't >> know it yet when creating this structure). > > It is not quite clear to me what exactly fails here. It's very easy to reproduce. No threads are needed. You initialize a session with SNMPv3 to host A with security name "read", auth "auth", priv "priv". Then, you initialize a session with SNMPv3 to host B, with the same CommandGenerator (and I think I also tried the same engine, but I am unsure, you know better), security name "read", auth "auth2", priv "priv2". Query one OID on host A, one OID on host B. One of them will fail. It is because you cache stuff into usmUserTable which is index by user. It needs to be also indexed by host since we can share the command generator/engine with several hosts. I am using this test: https://github.com/vincentbernat/snimpy/blob/master/tests/test_snmp.py#L293 https://github.com/vincentbernat/snimpy/blob/master/tests/test_snmp.py#L381 It can be made to fail by changing this line: https://github.com/vincentbernat/snimpy/blob/master/snimpy/snmp.py#L124 >> Since many stuff doesn't seem to be thread safe and that SnmpEngine is >> only parsing MIB stuff to get constant data, this part should be >> extracted to do it once. The other idea would be to stuff the context of > > Well, not quite. MIB structures can be modified at real-time > (configuration and statistics, not to mention remote configuration > features). I am not using any MIB myself (I am still using libsmi for that). I was under the impression that in hlapi.varbinds, the code of AbstractVarBinds was executed for each engine and the mibViewController was expensive because it needed to parse/load a MIB. Isn't that part constant and could be shared between all SnmpEngine instances? But maybe this is also used to store MIB stuff later (when using MIB to resolve OID)? >> a new SnmpEngine with the mibViewController of a previous SnmpEngine. > > Yeah, but what do you think of the idea when you keep a bunch of > SnmpEngine persistent and per-thread local passing queries to them? > > The other approach is asyncio: > > http://pysnmp.sourceforge.net/examples/hlapi/asyncio/manager/cmdgen/advanced-topics.html#concurrent-queries > > What do you think? Yes, this would be more convenient, but I need to threads to keep it simple for casual users. BTW, the trigger is this bug report: https://github.com/vincentbernat/snimpy/issues/33 -- Use variable names that mean something. - The Elements of Programming Style (Kernighan & Plauger) |
From: Vincent B. <be...@lu...> - 2015-11-18 21:29:29
|
❦ 18 novembre 2015 21:44 +0100, Ilya Etingof <il...@gl...> : > Oh, that might be a problem then. I’ve not noticed that advice. > > The good thing is that the parsing phase only happens once, then the > result is put into $HOME/.pysnmp/mibs/ and only loaded from there. > So you can potentially ‘bootstrap’ all MIBs from a single thread to > compile them from ASN.1 source prior to use (there’s also the mibdump > command-line tool). Currently, I am not using any MIB myself. I am only using OIDs. The only MIB that I am using are those implicitly needed by the SNMP engine. I am quite unsure of what happens exactly. $HOME/.pysnmp doesn't exist on my system, so I suppose that no MIB were cached. I may be mistaken with my view on how all this work. I was under impression that instantiating a new SnmpEngine would read some MIB (and that was the part that was slow). > Or have a dedicated thread that only compiles newly required MIBs, > other threads never compile anything but only load them up. > > I do not see much better solutions since we seem to hit ply’s limitation. > > What do you think? Yes, this is a very reasonable limitation (loading the MIB before doing thread stuff). -- The first thing we do, let's kill all the lawyers. -- Wm. Shakespeare, "Henry VI", Part IV |
From: Wei W. <ww...@9r...> - 2015-11-18 21:26:08
|
Ilya, Thanks for the response. I compiled the MIBs from their text files into the .py files (using the build-pysnmp-mib tool in a version 4.2.5 installation on a different host, if that matters). The text MIB files are here: https://raw.githubusercontent.com/ww9rivers/SnmpMibs/master/cisco/AIRESPACE-WIRELESS-MIB.mib https://raw.githubusercontent.com/ww9rivers/SnmpMibs/master/cisco/AIRESPACE-REF-MIB.mib I took the .py files out of the pysnmp folder and put it locally. Here is how I have loaded the MIB files: varbinds = [ ObjectType( #ObjectIdentity('.1.3.6.1.4.1.14179.2.2.1.1') ObjectIdentity('AIRESPACE-WIRELESS-MIB', 'bsnAPEntry') ) .addMibSource(os.path.abspath('.')) .loadMibs('AIRESPACE-REF-MIB', 'AIRESPACE-WIRELESS-MIB') ] Of course, I only had the .py files there. That made the code resolve object names but produced the same SmiError. With your latest email, I try to get pysnmp to auto-compile the MIBs: mibs = 'file:///opt/nss/etc/snmp/mibs' varbinds = [ ObjectType( #ObjectIdentity('.1.3.6.1.4.1.14179.2.2.1.1') ObjectIdentity('AIRESPACE-WIRELESS-MIB', 'bsnAPEntry') ) .addAsn1MibSource(mibs, os.path.join(mibs, 'cisco')) .loadMibs('AIRESPACE-REF-MIB', 'AIRESPACE-WIRELESS-MIB') ] But I am getting this error: MibNotFoundError: AIRESPACE-WIRELESS-MIB compilation error(s): missing; no module "SNMPv2-TC" in symbolTable at MIB AIRESPACE-WIRELESS-MIB I do have these files locally: /opt/nss/etc/snmp/mibs/cisco/AIRESPACE-WIRELESS-MIB.mib /opt/nss/etc/snmp/mibs/cisco/AIRESPACE-REF-MIB.mib /opt/nss/etc/snmp/mibs/SNMPv2-TC.mib Then there is also this: /usr/local/lib/python2.7/dist-packages/pysnmp/smi/mibs/SNMPv2-TC.py Why is it complaining about (no module "SNMPv2-TC" in symbolTable at MIB AIRESPACE-WIRELESS-MIB)? Without much documentation, I am moving forward with trial-and-error here. What do I need to make the MIB compilation work? Thanks! |
From: Ilya E. <il...@gl...> - 2015-11-18 20:44:28
|
Oh, that might be a problem then. I’ve not noticed that advice. The good thing is that the parsing phase only happens once, then the result is put into $HOME/.pysnmp/mibs/ and only loaded from there. So you can potentially ‘bootstrap’ all MIBs from a single thread to compile them from ASN.1 source prior to use (there’s also the mibdump command-line tool). Or have a dedicated thread that only compiles newly required MIBs, other threads never compile anything but only load them up. I do not see much better solutions since we seem to hit ply’s limitation. What do you think? -ilya > On 15 Nov 2015, at 23:02, Vincent Bernat <be...@lu...> wrote: > > ❦ 15 novembre 2015 17:30 +0100, Vincent Bernat <be...@lu...> : > >> Since many stuff doesn't seem to be thread safe and that SnmpEngine is >> only parsing MIB stuff to get constant data, this part should be >> extracted to do it once. > > All the more than starting with PySNMP 4.3, MIBs are parsed/compiled > with PySMI. I can't say for sure, but is it safe to compile a MIB from > different threads? It seems that ply is not thread-safe. It is said: > > ╭─────┤ https://github.com/dabeaz/ply/blob/master/ply/yacc.py#L40-L45 ├───── > │The current implementation is only somewhat object-oriented. The > │LR parser itself is defined in terms of an object (which allows multiple > │parsers to co-exist). However, most of the variables used during table > │construction are defined in terms of global variables. Users shouldn't > │notice unless they are trying to define multiple parsers at the same > │time using threads (in which case they should have their head > │examined). > ╰───── > — |
From: Ilya E. <il...@gl...> - 2015-11-18 20:37:39
|
Hi Vincent, > So, I had a look at PySNMP 4.3 but it seems that CommandGenerator is no > longer using AsynCommandGenerator. I can provide my own SnmpEngine but > SnmpEngine is still not thread-safe. The 4.3 version has many changes. In particular, SNMP high-level API has been unified across different transports and moved into pysnmp.hlapi.* . I’d advise not to use legacy interface (e.g. pysnmp.entity.rfc3413.oneliner) for multithreading stuff - it has many concurrency issues. Use pysnmp.hlapi.asyncore or pysnmp.hlapi (synchronous) instead. > A quick summary: I am trying to use multiple threads with several > managers per thread (but a given manager is created and lives in a > single thread). I am also trying to avoid the costly creation of a > CommandGenerator (which parses MIB). The only feasible design to me is to have one SnmpEngine per thread. SnmpEngine is expensive to create and populate, so try to keep your SnmpEngine’s in a thread pool for as long as you can rather than re-create them frequently. http://pysnmp.sourceforge.net/examples/hlapi/asyncore/sync/manager/cmdgen/advanced-topics.html#query-agents-from-multiple-threads [Asyn]CommandGenerator is gone - it was reimplemented as a function in the new API. > What does not work: > > 1. Having CommandGenerator as a singleton and using a single > thread. This fails when spawning commands from the same command > generator with different USM. This should not and using the > structure of usmUserTable (which is for a single agent) to store > stuff for a manager talking to multiple agents is a bad idea. The > cache should not just be a usmUserTable. It should also be indexed > by other security parameters or by the target agent (but we don't > know it yet when creating this structure). It is not quite clear to me what exactly fails here. > 2. Having CommandGenerator as a singleton and using multiple threads > with SNMPv1/v2 managers. This fails because SnmpEngine is not > thread-safe. That’s right. > 3. Having SnmpEngine as a singleton and using multiple threads with > SNMPv1/v2 managers, each manager having its own CommandGenerator > using the global SnmpEngine. SnmpEngine is not thread-safe and this > doesn't work either. Fair enough. > 4. Gaving CommandGenerator as a thread-local storage singleton. This > fails again with SNMPv3 when the same threads has several managers > (talking to several agents). Important thing is to have SnmpEngine local to thread. > What works: > > 1. Having one CommandGenerator for each manager. Works fine. Slow as > hell when you need to spawn them fast. Right. > 2. Having CommandGenerator as a thread-local storage singleton with > SNMPv1/v2 managers. Works fine. However, spawning multiple threads > is slow as hell. Right. > Since many stuff doesn't seem to be thread safe and that SnmpEngine is > only parsing MIB stuff to get constant data, this part should be > extracted to do it once. The other idea would be to stuff the context of Well, not quite. MIB structures can be modified at real-time (configuration and statistics, not to mention remote configuration features). > a new SnmpEngine with the mibViewController of a previous SnmpEngine. Yeah, but what do you think of the idea when you keep a bunch of SnmpEngine persistent and per-thread local passing queries to them? The other approach is asyncio: http://pysnmp.sourceforge.net/examples/hlapi/asyncio/manager/cmdgen/advanced-topics.html#concurrent-queries What do you think? -ilya |