pysnmp-dev — PySNMP development

Re: [Pysnmp-dev] IANA-CHARSET mib byte compilation problem - pysnmp-mibs 0.0.7a

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

It turned to be a bug triggered by changed MIB text file. This bug has 
been fixed in CVS (and also accedentally released at PyPi). The fix went 
to libsmi2pysnmp script, rebuilt MIB is attached to this message.

-ilya

> I'm the maintainer of the pysnmp4 packages in FreeBSD.  I am in the
> process of updating pyasn1, pysnmp4, and pysnmp4-mibs to their latest
> versions in the FreeBSD ports tree.
>
> I have updated pyasn1 to 0.0.9a, pysnmp4 to 4.1.11a, but I'm having
> problems building the port for pysnmp4-mibs 0.0.7a.  All of the other
> MIBs byte-compile just fine, but I keep getting this error:
>
>   File
> "/tmp/py25-snmp4-mibs-0.0.7a/lib/python2.5/site-packages/pysnmp_mibs/v4/IANA-CHARSET-MIB.py",
> line 17
>
> ,2091,85,2063,84,1017,47,2060,74,2080,2079,60,1020,1002,106,33,40,20,2015,2090,2029,52,2003,2002,91,35,73,1000,65,2035,2066,26,)
> SyntaxError: more than 255 arguments
>
> and the package won't build because the required .pyc and .pyo files
> aren't generated.
>
> Is this a structural problem in the file or a bug somewhere in my pysnmp
> toolchain?
>
> I'm testing with python 2.5.4, py-asn 0.0.9a, pysnmp4 4.1.11a, and
> libsmi 0.4.8.

[Pysnmp-dev] IANA-CHARSET mib byte compilation problem - pysnmp-mibs 0.0.7a

[Martin J. <mh...@sw...>]

Greetings all,

I'm the maintainer of the pysnmp4 packages in FreeBSD.  I am in the 
process of updating pyasn1, pysnmp4, and pysnmp4-mibs to their latest 
versions in the FreeBSD ports tree.

I have updated pyasn1 to 0.0.9a, pysnmp4 to 4.1.11a, but I'm having 
problems building the port for pysnmp4-mibs 0.0.7a.  All of the other 
MIBs byte-compile just fine, but I keep getting this error:

   File 
"/tmp/py25-snmp4-mibs-0.0.7a/lib/python2.5/site-packages/pysnmp_mibs/v4/IANA-CHARSET-MIB.py", 
line 17
 
,2091,85,2063,84,1017,47,2060,74,2080,2079,60,1020,1002,106,33,40,20,2015,2090,2029,52,2003,2002,91,35,73,1000,65,2035,2066,26,)
SyntaxError: more than 255 arguments

and the package won't build because the required .pyc and .pyo files 
aren't generated.

Is this a structural problem in the file or a bug somewhere in my pysnmp 
toolchain?

I'm testing with python 2.5.4, py-asn 0.0.9a, pysnmp4 4.1.11a, and 
libsmi 0.4.8.

Thanks,
Marty

[Pysnmp-dev] [PATCH] make use of mktemp if available

[Filippo G. <fi...@es...>]

As per subject, this also makes build-pysnmp-lib honour user's TMPDIR if set

thanks,
filippo

---
 tools/build-pysnmp-mib |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/tools/build-pysnmp-mib b/tools/build-pysnmp-mib
index 63f2426..4daa19c 100644
--- a/tools/build-pysnmp-mib
+++ b/tools/build-pysnmp-mib
@@ -38,6 +38,7 @@ egrep -q 'FROM *RFC' $mibFile 2> /dev/null && ! egrep -q 'FROM *SNMPv2-' $mibFil
 
 [ $oldMib = 'yes' ] && { # pysnmp SMI is SMIv2
     tmpFile=/tmp/buildmibs.$$
+    [ -x "$(which mktemp)" ] && t=$(mktemp -t buildmibs.XXXXXXX) && tmpFile=$t
     $smidump -k -f smiv2 $mibFile > $tmpFile 2> /dev/null || {
         [ -f $tmpFile ] && rm -f $tmpFile;
         echo >&2 "$smidump -k -f smiv2 $mibFile fails";
-- 
1.6.3.1

[Pysnmp-dev] [PATCH] don't assume libsmi2pysnmp in current dir and use /bin/sh

[Filippo G. <fi...@es...>]

I've found myself launching build-pysnmp-mib from outside tools/ and it wasn't
finding libsmi2pysnmp, this patch fixes the behaviour.

Also, the other trivial patch doesn't require the shell to be bash, I found no
bashisms using checkbashisms

thanks,
filippo

---
 tools/build-pysnmp-mib |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tools/build-pysnmp-mib b/tools/build-pysnmp-mib
index 495c2f0..a3b94b1 100644
--- a/tools/build-pysnmp-mib
+++ b/tools/build-pysnmp-mib
@@ -4,7 +4,9 @@
 # See http://pysnmp.sf.net for more information.
 #
 
-libsmi2pysnmp=libsmi2pysnmp  # part of pysnmp distro
+mydir=$(dirname "$0")
+
+libsmi2pysnmp="$mydir/libsmi2pysnmp" # part of pysnmp distro
 smidump=smidump  # part of libsmi distro
 
 while getopts o: o
diff --git a/tools/build-pysnmp-mib b/tools/build-pysnmp-mib
index a3b94b1..63f2426 100644
--- a/tools/build-pysnmp-mib
+++ b/tools/build-pysnmp-mib
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh

-- 
1.6.3.1

Re: [Pysnmp-dev] Receiving Traps Question

[Tom P. <pus...@ba...>]

That looks like exactly what I need. Thanks!

Tom

On May 22, 2009, at 3:07 AM, Ilya Etingof wrote:

>
> I've modified pysnmp CVS code to allow NotificationReceiver and
> CommandResponder apps browsing request details, particularily  
> transport information.
>
> See examples/v3arch/manager/ntfrcv.py for more information.
>
> Please, let me know if this change meets your needs.
>
> -ilya
>
>> As for Notification Originators identification - I'm trying to  
>> figure out
>> how it's supported to be done within the SNMPv3 standard. So far my
>> impression is that you have to use peer's contextEngineId/ 
>> contextName,
>> as comes with Notification, then lookup Manager's LCD for  
>> corresponding
>> transport information.
>>
>> Although I'm still not sure how this mechanism should work in  
>> SNMPv1/v2c
>> compatibility mode. If you have any ideas on the subject, please,  
>> let me
>> know. Meanwhile, I'm trying to figure that out.

Re: [Pysnmp-dev] Receiving Traps Question

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

I've modified pysnmp CVS code to allow NotificationReceiver and
CommandResponder apps browsing request details, particularily transport 
information.

See examples/v3arch/manager/ntfrcv.py for more information.

Please, let me know if this change meets your needs.

-ilya

> As for Notification Originators identification - I'm trying to figure out
> how it's supported to be done within the SNMPv3 standard. So far my
> impression is that you have to use peer's contextEngineId/contextName,
> as comes with Notification, then lookup Manager's LCD for corresponding
> transport information.
>
> Although I'm still not sure how this mechanism should work in SNMPv1/v2c
> compatibility mode. If you have any ideas on the subject, please, let me
> know. Meanwhile, I'm trying to figure that out.

Re: [Pysnmp-dev] Receiving Traps Question

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

Twisted dispatcher will surely be a part of pysnmp. I did not commit it 
into CVS yet because I'm trying to make sure it is done in a way 
consistent with Twisted spirit (and I'm not a Twisted expert).

As for Notification Originators identification - I'm trying to figure out
how it's supported to be done within the SNMPv3 standard. So far my 
impression is that you have to use peer's contextEngineId/contextName,
as comes with Notification, then lookup Manager's LCD for corresponding 
transport information.

Although I'm still not sure how this mechanism should work in SNMPv1/v2c 
compatibility mode. If you have any ideas on the subject, please, let me 
know. Meanwhile, I'm trying to figure that out.

-ilya

> First let me say thanks for pysnmp. Its quite nice. And thanks to Filippo for 
> the twisted dispatcher. Thats working great for me. Is that going to get 
> committed into CVS soon?
>
> I've been hacking on examples/v3arch/manager/ntfrcv.py and it works fine.
>
> I need to receive v1/v2/v3 traps from many sources in the same network so its 
> not possible to determine who the trap is from by authentication info.
>
> Is there an API through which I can determine who sent the trap in cbFun()?
>
> Once I get the trap, I need to query the device.

[Pysnmp-dev] Receiving Traps Question

[Tom P. <pus...@ba...>]

First let me say thanks for pysnmp. Its quite nice. And thanks to  
Filippo for the twisted dispatcher. Thats working great for me. Is  
that going to get committed into CVS soon?

I've been hacking on examples/v3arch/manager/ntfrcv.py and it works  
fine.

I need to receive v1/v2/v3 traps from many sources in the same network  
so its not possible to determine who the trap is from by  
authentication info.

Is there an API through which I can determine who sent the trap in  
cbFun()?

Once I get the trap, I need to query the device.

Thanks,
Tom

[Pysnmp-dev] [PATCH] Improve snmpwalk speed

[Alexander E. <al...@se...>]

Hi,

for large MIBs (~4600 PDUs with ~700 containing data) pysnmp takes quite some
time until a full snmpwalk is completed. 
For my use case the appended patch improves the walk time from ~12s to ~8s.


Mfg
Alexander Elbs

-- 
Alexander Elbs  ***  eMail al...@se...

Re: [Pysnmp-dev] libsmi2pysnmp textual-convention processing broken by 'default' enumeration

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

Ah, that looks like a design flaw in smidump -- it clashes enumeration 
names with its own keyword.

I've taken a slightly different workaround to skip generating default 
value in typedef:

*** libsmi2pysnmp       10 Mar 2009 16:39:51 -0000      1.32
--- libsmi2pysnmp       26 Mar 2009 16:26:24 -0000
***************
*** 277,283 ****
                          typeDef['range']['min'] == typeDef['range']['max']:
                       r = r + '.setFixedLength(%s)' % typeDef['range']['min']

!     if symDef.has_key('default'):
           defVal = __genDefVal(baseType, symDef)
           if classMode:
               if defVal is not None:
--- 277,283 ----
                          typeDef['range']['min'] == typeDef['range']['max']:
                       r = r + '.setFixedLength(%s)' % typeDef['range']['min']

!     if symDef.has_key('default') and not symDef.has_key('basetype'):
           defVal = __genDefVal(baseType, symDef)
           if classMode:
               if defVal is not None:

thanks,
ilya

> I?ve run into what I think is a bug in libsmi2pysnmp?s handling of
> textual-conventions that are enumerated maps that include the string
> ?default?.  Specifically, If processing a MIB with a TEXTUAL-CONVENTION
> like:
>
> SomeConvention ::= TEXTUAL-CONVENTION
>    STATUS          current
>    DESCRIPTION
>        "An example to crash libsmi2pysnmp²
>    SYNTAX          INTEGER  {
>                        default(1),
>                        whatever(2)
>                    }
>
> then when libsmi2pysnmp processes smidump ?f python?s output it will
> traceback thusly:
>
> Traceback (most recent call last):
>  File "./libsmi2pysnmp", line 343, in <module>
>    out.write('%s' % __genTypeDef((symName, symDef), 1))
>  File "./libsmi2pysnmp", line 281, in __genTypeDef
>    defVal = __genDefVal(baseType, symDef)
>  File "./libsmi2pysnmp", line 132, in __genDefVal
>    if symDef['syntax']['type'].has_key(symDef['default']):
> KeyError: 'syntax'
>
> I have worked around this by changing line 281 of __genTypeDef from:
>    if symDef.has_key('default'):
> to:
>    if symDef.has_key('default') and symDef.has_key('syntax'):
>
> Which works, but I have no idea if it?s really appropriate.
>
> Regards,
> Mark

[Pysnmp-dev] libsmi2pysnmp textual-convention processing broken by 'default' enumeration

[markeva <ma...@ci...>]

I¹ve run into what I think is a bug in libsmi2pysnmp¹s handling of
textual-conventions that are enumerated maps that include the string
Œdefault¹.  Specifically, If processing a MIB with a TEXTUAL-CONVENTION
like:

SomeConvention ::= TEXTUAL-CONVENTION
    STATUS          current
    DESCRIPTION
        "An example to crash libsmi2pysnmp²
    SYNTAX          INTEGER  {
                        default(1),
                        whatever(2)
                    }

then when libsmi2pysnmp processes smidump ­f python¹s output it will
traceback thusly:

Traceback (most recent call last):
  File "./libsmi2pysnmp", line 343, in <module>
    out.write('%s' % __genTypeDef((symName, symDef), 1))
  File "./libsmi2pysnmp", line 281, in __genTypeDef
    defVal = __genDefVal(baseType, symDef)
  File "./libsmi2pysnmp", line 132, in __genDefVal
    if symDef['syntax']['type'].has_key(symDef['default']):
KeyError: 'syntax'

I have worked around this by changing line 281 of __genTypeDef from:
    if symDef.has_key('default'):
 to:
    if symDef.has_key('default') and symDef.has_key('syntax'):

Which works, but I have no idea if it¹s really appropriate.

Regards,
Mark

Re: [Pysnmp-dev] converting from pyASN ObjectString, Integer to python types

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

These pyasn1 objects try to mimic base Python types meaning that you could
use them as you would use vanilla Python objects like integers or
strings.

> > > from pyasn1.type import univ
> > > print univ.Integer(1) + 10
11
> > > print univ.OctetString('hello') + ' world'
hello world

Therefore there is no explicit converter pyasn1-to-python built into 
pyasn1
objects.

If you still need to get rid of pyasn1 objects, try something like:

if issubclass(univ.Integer, myvalue):
    myvalue = long(myvalue)
else:
    myvalue = str(myvalue)

-ilya

On Thu, 19 Mar 2009, Zorg 421 wrote:

> Hello pysnmp users,
>
> How do I convert the snmp values returned by pysnmp without resorting
> to a priori knowledge on the ASN type
> in the table column I'm interested (like using int(prettyPrint()) )
> Example:
>
> ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 17, 24], Integer('1')),
> ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 17, 25], Integer('1')),
> ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 17, 26], Integer('1')),
> ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 17, 27], Integer('2')),
> ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 17, 28], Integer('2')),
> ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 18, 1], OctetString('Test SNMP query fifi')),
> ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 18, 2], OctetString('libre')),
> ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 18, 3], OctetString('free')),
> ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 18, 4], OctetString('unused')),
>
> Is there a commonly named method for each pyASN type which return a
> python int, string etc... ?
>
> Regards.
>
> ------------------------------------------------------------------------------
> Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
> powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
> easily build your RIAs with Flex Builder, the Eclipse(TM)based development
> software that enables intelligent coding and step-through debugging.
> Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
> _______________________________________________
> Pysnmp-dev mailing list
> Pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pysnmp-dev
>

[Pysnmp-dev] converting from pyASN ObjectString, Integer to python types

[Zorg 4. <zor...@gm...>]

Hello pysnmp users,

How do I convert the snmp values returned by pysnmp without resorting
to a priori knowledge on the ASN type
in the table column I'm interested (like using int(prettyPrint()) )
Example:

([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 17, 24], Integer('1')),
 ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 17, 25], Integer('1')),
 ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 17, 26], Integer('1')),
 ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 17, 27], Integer('2')),
 ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 17, 28], Integer('2')),
 ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 18, 1], OctetString('Test SNMP query fifi')),
 ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 18, 2], OctetString('libre')),
 ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 18, 3], OctetString('free')),
 ([1, 3, 6, 1, 2, 1, 31, 1, 1, 1, 18, 4], OctetString('unused')),

Is there a commonly named method for each pyASN type which return a
python int, string etc... ?

Regards.

Re: [Pysnmp-dev] [PATCH] first commit of twisted transport and dispatcher

[Filippo G. <fi...@tr...>]

On Fri, Feb 27, 2009 at 11:40:16PM +0300, Ilya Etingof wrote:
> 
> Hi,
> 
> Thanks for the patch! Twisted integration is something I always wanted!
> 
> I've re-arranged your patch a little to fit pysnmp/carrier code 
> conventions more naturally. I'm not a Twisted expert so I'd appreciate 
> you taking a look at it before it's released.
> 
> Your code is shipped under GPL, although pysnmp is BSD-licensed. Would 
> that cause some kind legal confusion once released altogether, what do you 
> think?

Attached there's an updated patch with code relicensed under BSD.

thanks,
filippo
--
Filippo Giunchedi - http://esaurito.net - 0x6B79D401

I always keep the Titanic in mind when I talk about security or
safety, meaning that nothing is fully secure.
-- Anonymous (?)

Re: [Pysnmp-dev] [PATCH] first commit of twisted transport and dispatcher

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

Hi,

Thanks for the patch! Twisted integration is something I always wanted!

I've re-arranged your patch a little to fit pysnmp/carrier code 
conventions more naturally. I'm not a Twisted expert so I'd appreciate 
you taking a look at it before it's released.

Your code is shipped under GPL, although pysnmp is BSD-licensed. Would 
that cause some kind legal confusion once released altogether, what do you 
think?

Thanks again!

-ilya

> the patch below ought to add a dispatcher and an udp transport to be 
> used with twisted, IOW you can use pysnmp while running a twisted 
> reactor.
>
> thanks in advance,
> filippo
> ---
> pysnmp/v4/carrier/twisted/dispatch.py |   61 +++++++++++++++++++++++++++
> pysnmp/v4/carrier/twisted/udp.py      |   74 +++++++++++++++++++++++++++++++++
> 2 files changed, 135 insertions(+), 0 deletions(-)
> create mode 100644 pysnmp/v4/carrier/twisted/__init__.py
> create mode 100644 pysnmp/v4/carrier/twisted/dispatch.py
> create mode 100644 pysnmp/v4/carrier/twisted/udp.py
>
> diff --git a/pysnmp/v4/carrier/twisted/__init__.py b/pysnmp/v4/carrier/twisted/__init__.py
> new file mode 100644
> index 0000000..e69de29
> diff --git a/pysnmp/v4/carrier/twisted/dispatch.py b/pysnmp/v4/carrier/twisted/dispatch.py
> new file mode 100644
> index 0000000..cba5074
> --- /dev/null
> +++ b/pysnmp/v4/carrier/twisted/dispatch.py
> @@ -0,0 +1,61 @@
> +#!/usr/bin/env python
> +#
> +# -*- python -*-
> +#
> +#  File: transport.py
> +#
> +#  Copyright (C) 2008 Truelite Srl <in...@tr...>
> +#
> +#  Author: Filippo Giunchedi <fi...@tr...>
> +#
> +#  This program is free software; you can redistribute it and/or modify
> +#  it under the terms of the GNU General Public License Version 2
> +#  as published by the Free Software Foundation
> +#
> +# Description:
> +# Transport dispatcher based on twisted.internet.reactor
> +
> +from time import time
> +
> +from twisted.internet import reactor, task
> +
> +from pysnmp.carrier.base import AbstractTransportDispatcher
> +
> +class ReactorDispatcher(AbstractTransportDispatcher):
> +    """TransportDispatcher based on twisted.internet.reactor"""
> +    def __init__(self, *args, **kwargs):
> +        AbstractTransportDispatcher.__init__(self)
> +
> +        self.timeout = 1
> +        if kwargs.has_key('timeout'):
> +            self.timeout = kwargs['timeout']
> +
> +        self.loopingcall = task.LoopingCall(self.handleTimeout)
> +
> +    def handleTimeout(self):
> +        self.handleTimerTick(time())
> +
> +    def runDispatcher(self, timeout=0.0):
> +        if not reactor.running:
> +            reactor.run()
> +
> +# jobstarted/jobfinished might be okay as-is
> +
> +    def registerTransport(self, tDomain, transport):
> +        if not self.loopingcall.running and self.timeout > 0:
> +            self.loopingcall.start(self.timeout, now = False)
> +        AbstractTransportDispatcher.registerTransport(self, tDomain, transport)
> +        # Ugly, but we need to call handleTimerTick() asyncronously from transports now.
> +        # IOW, it is not possibile to call handleTimerTick after poll()ing every transport' socket
> +        transport.dispatcher = self
> +
> +    def unregisterTransport(self, tDomain):
> +        t = AbstractTransportDispatcher.getTransport(self, tDomain)
> +        if t is not None:
> +            AbstractTransportDispatcher.unregisterTransport(self, tDomain)
> +            t.closeTransport()
> +
> +        if len(self._AbstractTransportDispatcher__transports) == 0:
> +            # the last transport has been removed, stop the timeout
> +            if self.loopingcall.running:
> +                self.loopingcall.stop()
> diff --git a/pysnmp/v4/carrier/twisted/udp.py b/pysnmp/v4/carrier/twisted/udp.py
> new file mode 100644
> index 0000000..dbb657a
> --- /dev/null
> +++ b/pysnmp/v4/carrier/twisted/udp.py
> @@ -0,0 +1,74 @@
> +#!/usr/bin/env python
> +#
> +# -*- python -*-
> +#
> +#  File: transport.py
> +#
> +#  Copyright (C) 2008 Truelite Srl <in...@tr...>
> +#
> +#  Author: Filippo Giunchedi <fi...@tr...>
> +#
> +#  This program is free software; you can redistribute it and/or modify
> +#  it under the terms of the GNU General Public License Version 2
> +#  as published by the Free Software Foundation
> +#
> +# Description:
> +# twisted DatagramProtocol UDP transport
> +
> +from time import time
> +
> +from twisted.internet import reactor
> +from twisted.internet.protocol import DatagramProtocol
> +
> +from pysnmp.carrier import error
> +
> +class ReactorUDPTransport(DatagramProtocol):
> +    """UDP Transport based on twisted, to be used with ReactorDispatcher"""
> +
> +    def __init__(self):
> +        self.__writeQ = []
> +
> +# twisted API
> +    def datagramReceived(self, datagram, address):
> +        if self._cbFun is not None:
> +            self._cbFun(self, address, datagram)
> +        else:
> +            raise error.CarrierError('Unable to call cbFun')
> +
> +        if self.dispatcher is not None:
> +            self.dispatcher.handleTimerTick(time())
> +        else:
> +            raise error.CarrierError('Unable to call handleTimerTick')
> +
> +    def startProtocol(self):
> +        while self.__writeQ:
> +            msg, addr = self.__writeQ.pop(0)
> +            self.transport.write(msg, addr)
> +
> +    def stopProtocol(self):
> +        self.unregisterCbFun()
> +        self.dispatcher = None
> +
> +# asyncore AbstractSocketTransport API
> +    def openClientMode(self, iface=''):
> +        self._lport = reactor.listenUDP(0, self, iface)
> +        return self
> +
> +    def openServerMode(self, iface=None):
> +        self._lport = reactor.listenUDP(iface[1], self, iface[0])
> +        return self
> +
> +    def sendMessage(self, outgoingMessage, transportAddress):
> +        if self.transport is None:
> +            self.__writeQ.append((outgoingMessage, transportAddress))
> +        else:
> +            self.transport.write(outgoingMessage, transportAddress)
> +
> +    def registerCbFun(self, cbFun):
> +        self._cbFun = cbFun
> +
> +    def unregisterCbFun(self):
> +        self._cbFun = None
> +
> +    def closeTransport(self):
> +        self.transport.stopListening()
>

[Pysnmp-dev] [PATCH] first commit of twisted transport and dispatcher

[Filippo G. <fi...@tr...>]

Hi,
the patch below ought to add a dispatcher and an udp transport to be used with
twisted, IOW you can use pysnmp while running a twisted reactor.

thanks in advance,
filippo
---
 pysnmp/v4/carrier/twisted/dispatch.py |   61 +++++++++++++++++++++++++++
 pysnmp/v4/carrier/twisted/udp.py      |   74 +++++++++++++++++++++++++++++++++
 2 files changed, 135 insertions(+), 0 deletions(-)
 create mode 100644 pysnmp/v4/carrier/twisted/__init__.py
 create mode 100644 pysnmp/v4/carrier/twisted/dispatch.py
 create mode 100644 pysnmp/v4/carrier/twisted/udp.py

diff --git a/pysnmp/v4/carrier/twisted/__init__.py b/pysnmp/v4/carrier/twisted/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/pysnmp/v4/carrier/twisted/dispatch.py b/pysnmp/v4/carrier/twisted/dispatch.py
new file mode 100644
index 0000000..cba5074
--- /dev/null
+++ b/pysnmp/v4/carrier/twisted/dispatch.py
@@ -0,0 +1,61 @@
+#!/usr/bin/env python
+#
+# -*- python -*-
+#
+#  File: transport.py
+#
+#  Copyright (C) 2008 Truelite Srl <in...@tr...>
+#
+#  Author: Filippo Giunchedi <fi...@tr...>
+#
+#  This program is free software; you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License Version 2
+#  as published by the Free Software Foundation
+#
+# Description:
+# Transport dispatcher based on twisted.internet.reactor
+
+from time import time
+
+from twisted.internet import reactor, task
+
+from pysnmp.carrier.base import AbstractTransportDispatcher
+
+class ReactorDispatcher(AbstractTransportDispatcher):
+    """TransportDispatcher based on twisted.internet.reactor"""
+    def __init__(self, *args, **kwargs):
+        AbstractTransportDispatcher.__init__(self)
+
+        self.timeout = 1
+        if kwargs.has_key('timeout'):
+            self.timeout = kwargs['timeout']
+
+        self.loopingcall = task.LoopingCall(self.handleTimeout)
+
+    def handleTimeout(self):
+        self.handleTimerTick(time())
+
+    def runDispatcher(self, timeout=0.0):
+        if not reactor.running:
+            reactor.run()
+
+# jobstarted/jobfinished might be okay as-is
+
+    def registerTransport(self, tDomain, transport):
+        if not self.loopingcall.running and self.timeout > 0:
+            self.loopingcall.start(self.timeout, now = False)
+        AbstractTransportDispatcher.registerTransport(self, tDomain, transport)
+        # Ugly, but we need to call handleTimerTick() asyncronously from transports now.
+        # IOW, it is not possibile to call handleTimerTick after poll()ing every transport' socket
+        transport.dispatcher = self
+
+    def unregisterTransport(self, tDomain):
+        t = AbstractTransportDispatcher.getTransport(self, tDomain)
+        if t is not None:
+            AbstractTransportDispatcher.unregisterTransport(self, tDomain)
+            t.closeTransport()
+
+        if len(self._AbstractTransportDispatcher__transports) == 0:
+            # the last transport has been removed, stop the timeout
+            if self.loopingcall.running:
+                self.loopingcall.stop()
diff --git a/pysnmp/v4/carrier/twisted/udp.py b/pysnmp/v4/carrier/twisted/udp.py
new file mode 100644
index 0000000..dbb657a
--- /dev/null
+++ b/pysnmp/v4/carrier/twisted/udp.py
@@ -0,0 +1,74 @@
+#!/usr/bin/env python
+#
+# -*- python -*-
+#
+#  File: transport.py
+#
+#  Copyright (C) 2008 Truelite Srl <in...@tr...>
+#
+#  Author: Filippo Giunchedi <fi...@tr...>
+#
+#  This program is free software; you can redistribute it and/or modify
+#  it under the terms of the GNU General Public License Version 2
+#  as published by the Free Software Foundation
+#
+# Description:
+# twisted DatagramProtocol UDP transport
+
+from time import time
+
+from twisted.internet import reactor
+from twisted.internet.protocol import DatagramProtocol
+
+from pysnmp.carrier import error
+
+class ReactorUDPTransport(DatagramProtocol):
+    """UDP Transport based on twisted, to be used with ReactorDispatcher"""
+
+    def __init__(self):
+        self.__writeQ = []
+
+# twisted API
+    def datagramReceived(self, datagram, address):
+        if self._cbFun is not None:
+            self._cbFun(self, address, datagram)
+        else:
+            raise error.CarrierError('Unable to call cbFun')
+
+        if self.dispatcher is not None:
+            self.dispatcher.handleTimerTick(time())
+        else:
+            raise error.CarrierError('Unable to call handleTimerTick')
+
+    def startProtocol(self):
+        while self.__writeQ:
+            msg, addr = self.__writeQ.pop(0)
+            self.transport.write(msg, addr)
+
+    def stopProtocol(self):
+        self.unregisterCbFun()
+        self.dispatcher = None
+
+# asyncore AbstractSocketTransport API
+    def openClientMode(self, iface=''):
+        self._lport = reactor.listenUDP(0, self, iface)
+        return self
+
+    def openServerMode(self, iface=None):
+        self._lport = reactor.listenUDP(iface[1], self, iface[0])
+        return self
+
+    def sendMessage(self, outgoingMessage, transportAddress):
+        if self.transport is None:
+            self.__writeQ.append((outgoingMessage, transportAddress))
+        else:
+            self.transport.write(outgoingMessage, transportAddress)
+
+    def registerCbFun(self, cbFun):
+        self._cbFun = cbFun
+
+    def unregisterCbFun(self):
+        self._cbFun = None
+
+    def closeTransport(self):
+        self.transport.stopListening()
-- 
1.6.0.6

Re: [Pysnmp-dev] possible bug in SnmpV1SecurityModel.processIncomingMsg ?

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

Your fix is absolutely correct. I've just committed it into CVS at 
SourceForge. Thanks for pointing out!

-ilya

[ skipped ]

> There is a while(1) look in there that is exited with a break when the
> incoming communityName is matched against an entry in the SNMP-COMMUNITY-MIB
> snmpCommunityName or we exhaust all the snmpCommunityName entries without
> finding a match, in which case the request should be dropped and
> snmpInBadCommunityNames incremented.
> 
> The problem is we always seem to allow in the user, even when a match is not
> found.  The problem is that the 'else' clause outside of the while(1) loop
> can never be entered since the else clause on a loop is only entered when
> the loop terminates normally, which is impossible for a while(1) loop.

[ skipped ]

[Pysnmp-dev] possible bug in SnmpV1SecurityModel.processIncomingMsg ?

[Paul W. <pau...@cy...>]

First let me say that PySNMP is pretty handy, it has made my life a lot
easier in the last few weeks.

Secondly, in doing some development and testing of my manager side
application I think I hit a bug in pysnmp/v4/proto/secmod/rfc2576.py
SnmpV1SecurityModel.processIncomingMsg.  Apologies in advance if I am just
misunderstanding this.

There is a while(1) look in there that is exited with a break when the
incoming communityName is matched against an entry in the SNMP-COMMUNITY-MIB
snmpCommunityName or we exhaust all the snmpCommunityName entries without
finding a match, in which case the request should be dropped and
snmpInBadCommunityNames incremented.

The problem is we always seem to allow in the user, even when a match is not
found.  The problem is that the 'else' clause outside of the while(1) loop
can never be entered since the else clause on a loop is only entered when
the loop terminates normally, which is impossible for a while(1) loop.
>From the python docs:
"Loop statements may have an else clause; it is executed when the loop
terminates through exhaustion of the list (with for) or when the condition
becomes false (with while), but not when the loop is terminated by a
breakstatement."

        while 1:
            try:
                mibNodeIdx = snmpCommunityName.getNextNode(
                    mibNodeIdx.name
                    )
            except NoSuchInstanceError:
                break
            if mibNodeIdx.syntax != communityName:
                continue
            break
        else:
            #  I don't think we can ever get here!
            snmpInBadCommunityNames, =
snmpEngine.msgAndPduDsp.mibInstrumController.mibBuilder.importSymbols('__SNMP-COMMUNITY-MIB',
'snmpInBadCommunityNames')
            snmpInBadCommunityNames.syntax =
snmpInBadCommunityNames.syntax+1
            raise error.StatusInformation(
                errorIndication = 'unknownCommunityName'
                )

I think instead we want something like this, although a better solution is
welcome:

        while 1:
            try:
                mibNodeIdx = snmpCommunityName.getNextNode(
                    mibNodeIdx.name
                    )
            except NoSuchInstanceError:
                print 'unknownCommunityName: %s' % (communityName,)
                snmpInBadCommunityNames, =
snmpEngine.msgAndPduDsp.mibInstrumController.mibBuilder.importSymbols('__SNMPv2-MIB',
'snmpInBadCommunityNames')
                snmpInBadCommunityNames.syntax =
snmpInBadCommunityNames.syntax+1
                raise error.StatusInformation(
                    errorIndication = 'unknownCommunityName'
                    )
                break  # i guess this break isn't needed
            if mibNodeIdx.syntax != communityName:
                continue
            break

Thanks in advance for any replies, and keep up the good work.

-Paul Warner

Re: [Pysnmp-dev] Timeout calculation bug

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

Fixed in CVS. Thanks for digging this up so clearly!

> Anyway, I changed the calculation to:
> 
> 	float(timeout)/100.0 + time.time()
> 
> and now everything seems to be running as expected without unexpected
> retransmits.

Re: [Pysnmp-dev] Timeout calculation bug

[Mark M E. <mar...@ma...>]

It looks like there is at least one more occurrence of the bug at:

	pysnmp/v4/entity/rfc3413/ntforg.py:74

On Nov 21, 2007, at 5:20 PM, Mark M Evans wrote:

> ...
>
> In my local checkout of PySNMP this change was required in:
>
> 	pysnmp/v4/entity/rfc3413/cmdgen.py:164
> 	pysnmp/v4/entity/rfc3413/ntforg.py:229
>
> I can create a patch if you like, but it seems a bit overkill.  :-)
>
> Regards,
> Mark
>
> ...
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ 
> _______________________________________________
> Pysnmp-dev mailing list
> Pys...@li...
> https://lists.sourceforge.net/lists/listinfo/pysnmp-dev

--
This signature intentionally left blank.

[Pysnmp-dev] Timeout calculation bug

[Mark M E. <mar...@ma...>]

Howdy,

I've been running PySNMP on some fairly slow hardware and I  
discovered an apparent bug related to calculating the "timeoutAt"  
time for a PDU.  The behavior I noticed was that according to  
wireshark, requests where occasionally being retransmitted  
significantly sooner than the 1 second default timeout.

After much spelunking and a liberal use of print statements, I  
discovered that PDUs were timing out earlier than expected.   
Occasionally they were timing out in a few hundredths of a second.   
It turns out that _sendPdu() and sendNotification() were truncating  
the calculated timeoutAt entry in the expectResponse parameter of  
snmpEngine.msgAndPduDsp.sendPdu(...).  What's happening is that  
timeoutAt is calculated as:

	timeout/100 + time.time()

But timeout is a TimeInterval instance which has a __div__ method  
that returns a new TimeInterval instance.  The TimeInterval also has  
__add__ and __radd__ methods, so the result of the addition of  
time.time() is also a TimeInterval.  So the calculation is essentially:

	TimeInterval(timeout/100) + TimeInterval(time.time())

aka

	int(timeout/100) + int(time.time())

Which results in a lot of truncation.  If timeout was ever less than  
1, then timeoutAt would never be greater than time.time().  But even  
with the default of timeout=TimeInterval(100), the truncation of  
time.time() is essentially always less than expected.

Anyway, I changed the calculation to:

	float(timeout)/100.0 + time.time()

and now everything seems to be running as expected without unexpected  
retransmits.

In my local checkout of PySNMP this change was required in:

	pysnmp/v4/entity/rfc3413/cmdgen.py:164
	pysnmp/v4/entity/rfc3413/ntforg.py:229

I can create a patch if you like, but it seems a bit overkill.  :-)

Regards,
Mark






--
This signature intentionally left blank.

Re: [Pysnmp-dev] More potential socket_map issues

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

Your patch has been committed into CVS. Sorry for delay.

Thanks,
ilya

[ skipped ]

> The following worked for me (similar to my original hack, but closer  
> to the source of the problem):
> 
> class AbstractSocketTransport(asyncore.dispatcher):
>      sockFamily = sockType = None
>      retryCount = 0; retryInterval = 0
>      def __init__(self, sock=None, sockMap=None):
>          # @patch begin
>          # The socket map is managed by the AsynsockDispatcher on  
> which this
>          # transport is registered.
>          if sockMap is None:
>              sockMap = {}
>          # @patch end
>          if sock is None:
>              try:
> 
> The temporary socket map is immediately discarded and then the  
> AbstractSocketTransport
> only participates in the socket map of the AsynsockDispatcher on  
> which it is registered.

[Pysnmp-dev] More potential socket_map issues

[Mark M E. <mar...@ma...>]

First of all, in case I haven't mentioned it already, I'm really  
impressed by PySNMP.  I think it
is an amazing piece of work.  Also, I'm new to PySNMP and SNMP, so  
I'm still learning my
way around.

4.1.9a (aka CVS) fixes the socket leak, but it's still creating "side  
effects" in the
asyncore.socket_map.  Consider the following code:

===========================8<==============================
from pysnmp.carrier.asynsock import dispatch
from pysnmp.entity import engine
from pysnmp.entity.rfc3413.oneliner import cmdgen


security_name = 'default'
community_name = 'xxx'
address = '10.0.1.1' # My Airport Extreme Wireless router
port = 161
# iso.org.dod.internet.private.enterprises.apple.airport.baseStation3.
#     physicalInterfaces.physicalInterfacesTable.physicalInterface.
#     physicalInterfaceNumRX.1
object_name = (1, 3, 6, 1, 4, 1, 63, 501, 3, 4, 2, 1, 8, 1)

auth_data = cmdgen.CommunityData(security_name,
                                  community_name,
                                  1)
transportTarget = cmdgen.UdpTransportTarget((address, port))
snmpEngine = engine.SnmpEngine()
transportDispatcher = dispatch.AsynsockDispatcher()
transportDispatcher.setSocketMap({})
snmpEngine.registerTransportDispatcher(transportDispatcher)
errorIndication, errorStatus, errorIndex, varBinds = (
     cmdgen.CommandGenerator(snmpEngine).getCmd(
         auth_data, transportTarget,
         object_name
         )
     )
===========================>8==============================

In so far as this creates a blocking command that uses it's own  
socket map
in runDispatcher(), this works great.  But internally, the transport  
is being added initially to the
asyncore.socket_map and then it is also being added the the __sockMap  
of the
transportDispatcher.  I'm concerned about the transport ever being  
added to
asyncore.socket_map when it is being created for an  
transportDispatcher that has it's own map.
The reason that I'm concerned is that I'm trying to make sure that I  
can invoke a blocking command
in a thread without effecting some other package that is using  
asyncore in another thread (like
Medussa).  Although my example is using blocking commands, I think  
that any attempt to use a
non-default socket map will result in the same behavior.

It seems like the correct socket map is explicitly managed via  
registerTransport() and
unregisterTransport().  Therefore it seems like a  
AbstractSocketTransport should not implicitly
added to asyncore.socket_map, but rather defer that decision until  
registerTransport() is
called.

The following worked for me (similar to my original hack, but closer  
to the source of the problem):

class AbstractSocketTransport(asyncore.dispatcher):
     sockFamily = sockType = None
     retryCount = 0; retryInterval = 0
     def __init__(self, sock=None, sockMap=None):
         # @patch begin
         # The socket map is managed by the AsynsockDispatcher on  
which this
         # transport is registered.
         if sockMap is None:
             sockMap = {}
         # @patch end
         if sock is None:
             try:

The temporary socket map is immediately discarded and then the  
AbstractSocketTransport
only participates in the socket map of the AsynsockDispatcher on  
which it is registered.

Hopefully what I've said made sense.

Regards,
Mark

Re: [Pysnmp-dev] Potential oneliner bugs

[Mark M E. <mar...@ma...>]

Thanks for the quick fixes (and sorry for the slow response, I've  
been swamped).  I've verified the socket leak is fixed.  The changes  
for V1 GET NEXT looks good, but I haven't been able to test it  
against real hardware yet.

On Aug 15, 2007, at 6:31 AM, Ilya Etingof wrote:

>
> Both issues hopefully fixed in CVS (not with your patches). Please,  
> take a
> look.
>
> Thanks,
> ilya
>
> On Tue, 14 Aug 2007, Mark M Evans wrote:
>
>> I've run into a couple of issues that I think are bugs in the
>> oneliner implementation.  I'm still learning my way around PySNMP, so
>> apologies if my assumptions or conclusions are incorrect.
>>
>> Issue #1:  Oneliner commands "leaking" sockets.
>>
>> UdpTransportTarget.openClientMode() creates a transport via
>> UdpSocketTransport().  A side effect of using the default parameters
>> is that a new channel/socket is created and is registered in
>> asyncore.socket_map.  The socket is never removed from
>> asyncore.socket_map, it's never garbage collected and the socket is
>> never closed.  The result is that instantiating and destroying large
>> numbers of CommandGenerators will consume all of the systems socket
>> resources.
>>
>> I have a patch that works for me which is to pass a throw away
>> dictionary as the sockMap.  Example:
>>
>> pysnmp/entity/rfc3413/oneliner/cmdgen.py:
>>
>> class UdpTransportTarget:
>>      ...
>>      def openClientMode(self):
>>          self.transport = udp.UdpSocketTransport(sock=None,
>>                                                  sockMap=
>> {}).openClientMode()
>>          return self.transport
>>
>> Issue #2:  CommandGenerator().nextCmd() does not work with V1  
>> devices.
>>
>> V1 devices terminate the list list of OIDs by returning an
>> errorStatus of noSuchName(2), not by returning a value of endOfMib.
>> CommandGenerator().nextCmd() considers a non-false errorStatus as an
>> error (makes sense) and passes that failure to the caller.
>>
>> I've hacked my local version to explicitly check for an errorStatus
>> of 2, and clears that errorStatus/Index.  This seems to work, but
>> there may be a cleaner solution.
>>
>> pysnmp/entity/rfc3413/oneliner/cmdgen.py:
>>
>> class CommandGenerator(AsynCommandGenerator):
>>      ...
>>      def nextCmd(self, authData, transportTarget, *varNames):
>>          def __cbFun(
>>              sendRequestHandle, errorIndication, errorStatus,
>> errorIndex,
>>              varBindTable, (varBindHead, varBindTotalTable,  
>> appReturn)
>>              ):
>>              if errorStatus == 2:
>>                  # V1 terminates GETNEXT with an errorStatus of
>> noSuchName
>>                  # rather than a value of endOfMib (which v2c.PDUAPI
>> replaces
>>                  # with None).
>>                  errorStatus = errorStatus.clone(0)
>>                  errorIndex = errorIndex.clone(0)
>>                  pass
>>              if errorIndication or errorStatus:
>>              ...
>>
>> Hopefully this information is helpful.
>>
>> Regards,
>> Mark

--
This signature intentionally left blank.

Re: [Pysnmp-dev] Potential oneliner bugs

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

Both issues hopefully fixed in CVS (not with your patches). Please, take a 
look.

Thanks,
ilya

On Tue, 14 Aug 2007, Mark M Evans wrote:

> I've run into a couple of issues that I think are bugs in the  
> oneliner implementation.  I'm still learning my way around PySNMP, so  
> apologies if my assumptions or conclusions are incorrect.
> 
> Issue #1:  Oneliner commands "leaking" sockets.
> 
> UdpTransportTarget.openClientMode() creates a transport via  
> UdpSocketTransport().  A side effect of using the default parameters  
> is that a new channel/socket is created and is registered in  
> asyncore.socket_map.  The socket is never removed from  
> asyncore.socket_map, it's never garbage collected and the socket is  
> never closed.  The result is that instantiating and destroying large  
> numbers of CommandGenerators will consume all of the systems socket  
> resources.
> 
> I have a patch that works for me which is to pass a throw away  
> dictionary as the sockMap.  Example:
> 
> pysnmp/entity/rfc3413/oneliner/cmdgen.py:
> 
> class UdpTransportTarget:
>      ...
>      def openClientMode(self):
>          self.transport = udp.UdpSocketTransport(sock=None,
>                                                  sockMap= 
> {}).openClientMode()
>          return self.transport
> 
> Issue #2:  CommandGenerator().nextCmd() does not work with V1 devices.
> 
> V1 devices terminate the list list of OIDs by returning an  
> errorStatus of noSuchName(2), not by returning a value of endOfMib.   
> CommandGenerator().nextCmd() considers a non-false errorStatus as an  
> error (makes sense) and passes that failure to the caller.
> 
> I've hacked my local version to explicitly check for an errorStatus  
> of 2, and clears that errorStatus/Index.  This seems to work, but  
> there may be a cleaner solution.
> 
> pysnmp/entity/rfc3413/oneliner/cmdgen.py:
> 
> class CommandGenerator(AsynCommandGenerator):
>      ...
>      def nextCmd(self, authData, transportTarget, *varNames):
>          def __cbFun(
>              sendRequestHandle, errorIndication, errorStatus,  
> errorIndex,
>              varBindTable, (varBindHead, varBindTotalTable, appReturn)
>              ):
>              if errorStatus == 2:
>                  # V1 terminates GETNEXT with an errorStatus of  
> noSuchName
>                  # rather than a value of endOfMib (which v2c.PDUAPI  
> replaces
>                  # with None).
>                  errorStatus = errorStatus.clone(0)
>                  errorIndex = errorIndex.clone(0)
>                  pass
>              if errorIndication or errorStatus:
>              ...
> 
> Hopefully this information is helpful.
> 
> Regards,
> Mark