Re: SNMPv3 bulkwalk()/callback blocking during background EngineID queries

Quoting Wes Hardaker <[email protected]>:

> Paul S <[email protected]> writes:
>
>> From packet analysis, I see that when bulkwalk() is called, the SNMP
>> library first queries that device's EngineID if this is not already
>> cached.
>
> SNMPv3 does have a larger start up cost because of this while it does
> engine synchronization.  It would surprise me that bulkwalk is the only
> function with this problem.  Are you sure the same symptoms don't occur
> with other types of requests (walks or even gets)?

Actually, I'm not sure as I'm only using bulkwalk(), but I have no  
doubt that engine synchronisation must happen for walks/gets if its  
not already cached.

However, it's not the engine synchronization itself that's the issue -  
it's the fact that the engine synchonisation is not handled within  
SNMP::MainLoop().  Thus the attempted synchronisation of one  
unavailable device blocks the asynchronous SNMP processing of hundreds  
of other devices until that single device times-out.  There may be a  
number of devices unavailable, and all of these will block asynchonous  
polling each time they are retried and found to be unavailable.

As an alternative immediate solution I tried to handle the engine  
synchonrisation in a separate process, and pass the EngineID via  
SecEngineId in SNMP::Session->new() in my code.

If I specify 0 as the EngineID (default, as above), we have the  
overhead of the blocking EngineId request (a working device returns  
Report 33, usmStatsUnknownEngineIDs increments)

If I specify the correct EngineID, The device replies Report 31,  
usmStatsNotInTimeWindows increments, which implies I have the EngineID  
correct, but bulkwalk() itself then fails to complete - callback is  
immediately called with empty data.

If I specify an incorrect EngineID the device returns Report 33,  
usmStatsUnknownEngineIDs increments, and this attempt is retried  
before timing-out and the callback called with empty data.  This does  
not block.

So, specifying a non-zero SecEngineId avoids blocking of bulkwalk as  
there is no EngineID synchonrisation happening in the background.   
This would solve my issue except it seems bulkwalk() fails even when a  
correct EngineID is specified.  Any ideas how I might work around this?

Many thanks,
Paul

-- 
Paul S