Re: [netdisco-devel] Class Problem w/ SNMPv2

[Max B. <ma...@wa...>]

On Sun, Mar 20, 2005 at 11:19:48PM -0500, Eric Miller wrote:
> I added support for older Accelar devices to the Passport class.  Everything
> works fine for these devices if they are running newer code.  However, if they
> are running older code they start answering and somewhere in the query
> SNMP::Info locks up (the device still functions fine and will answer queries
> from another source).  The only way I can get it to exit is to kill the
> process.  I haven't run SNMP in debug mode yet or taken a packet capture
> because I'm hoping there is an easy solution for this.

Assuming the devices will properly behave enough to grab the description and
model id,  SNMP::Info could be changed to allow a reconnection after
specify().  Right now there is no real way to do it.  something like 

    type = specify()
    if obj->modified sess = session(args)

then moving some of the code in new() to a new method session() that would
parse the %args and return a session obj.  Let me know if I should do that.

A couple things to try : 
    - make sure it's not a bulkwalk thing and turn off bulkwalk
    - try to reproduce the problem with snmpwalk and/or snmpbulkwalk cli
      utils.  Turn on all the debugging output for the tools (except for
packet dump!)

I was seeing an endless loop problem lately with a foundry ironware switch
where it would send back the same data over and over again.  We need to add
a check in snmp::info that checks for a repeating IID when getting a table.
The c-based net-snmp tools like snmpwalk do this already but it's not
documented anywhere.  I wouldn't be surprised if this same thing was
happening with these devices.

> Although the older devices "support" v2, I run into the lockup unless I query
> the device with v1.  Is there any way in the class to tell it to use v2 unless
> the version or model matches certain criterea and then use v1?  I think this is
> opposite of the problems with HP devices.
> 
> Am I missing anything else, like tunable behavior of SNMP::Info?

Another idea might be to put some sort of timeout in _funcs or _global that
would prevent a lock-up like this.   choosing a proper value for funcs()
is non-trivial and is a knob that we don't want to have to expose to a
naive user.

Last resort is to just not support the devices.   Although i don't think
device_type() has the ability to abort right now.

-m