[SNMP4J] SNMPv3 engineBoots/engineTime issue

[Mike Davidson]

Hello,

We use SNMP4J (v1.11) in our SNMP management application and we've recently run into an issue with what I think is a mis-behaving 3rd-party agent.  I was hoping to be able to work-around the mis-behaving agent but I'm running into some SNMP4J behavior that I don't understand.  First, I'll describe the SNMP4J behavior that I'm confused by.  The issue is specific to SNMPv3 set requests and involves engineBoots and engineTime values.  I was able to reproduce this issue with the SnmpRequest console tool that comes with SNMP4J.  

At a high level, here's the packet exchange I'm seeing when issuing an SNMPv3 set request using the SNMP4J SnmpRequest console tool.  In this case, the agent is "well-behaved" and the set succeeds:


	set-request (w/ engineId=0) -> 
																	<- unknownEngineID report (w/ engineId, engineBoots, and engineTime set)
	
	set-request (w/ engineId set but engineBoots and engineTime set to 0) ->
																	<- notInTimeWindow report (w/ engineId, engineBoots, and engineTime set)

	set-request (w/ engineId, engineBoots and engineTime set)
																	<- set-response
	

My question is this:  why isn't initial set-request sufficient to determine engineBoots and engineTime (why is only engineId determined by this request)?

For example, if I use Net-SNMP to perform the same set the packet exchange looks like this:

	set-request (w/ engineId=0) -> 
																	<- unknownEngineID report (w/ engineId, engineBoots, and engineTime set)
	
	set-request (w/ engineId, engineBoots, and engineTime set) ->
																	<- set-response


Can SNMP4J be configured to have similar behavior?  Not only is the Net-SNMP behavior more efficient but I have an SNMP agent which does not generate the "notInTimeWindow" report in response to a setRequest in which engineBoots and engineTime set to 0.  Instead the agent just responds as if the set succeeded (even though it really doesn't actually perform the set).  If I use Net-SNMP to perform the set, it works just fine with this "mis-behaving" agent since engineBoots and engineTime are set correctly based on the initial engineID discovery request. 

Any help or insight would be appreciated.

Regards,
Mike