>>>>> "RB" == Rob Bloodgood <[EMAIL PROTECTED]> writes:

RB> However, during development I discovered that when using SNMPv3, the 
RB> constructor blocks until an authentication reply is received (or times 
RB> out).

I believe you're confusing a few things:

1) the constructor doesn't authenticate things
2) the constructor does create SNMPv3 keys, which can be
   mildly-computationally intensive compared to creating non-SNMPv3 sessions
3) the constructor does do engineID probing

You can't short-cut the key creation (it'll need to spend the CPU time
at some point or another)

The engineID probing (it sends a packet to the agent and then waits for
the response) may be blocking, you're right.  I believe the library
actually can delay the engineID probing and it may make it possible for
it to be asynchronous.  I wasn't the one who implemented that code; so I
forget ;-)

However, there is nothing in theory that would make it impossible to do
what you want.  I don't remember the current state of the library and
how much work it would take.

RB> Additionally, if authentication fails, the constructor returns undef and 
RB> I haven't been able to figure out where the error message (or code) 
RB> explaining this is accessible (altho it shows up as part of the 
RB> $SNMP::debugging output).  Is there a (potentially global) way to access 
RB> this data, and return an accurate error message of some kind?

Something else I vaguely remember running into but forget the answer to
(sorry).
-- 
Wes Hardaker
Sparta, Inc.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Net-snmp-users mailing list
[email protected]
Please see the following page to unsubscribe or change other options:
https://lists.sourceforge.net/lists/listinfo/net-snmp-users

Reply via email to