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
_______________________________________________
SNMP4J mailing list
[email protected]
http://lists.agentpp.org/mailman/listinfo/snmp4j
