[SNMP4J] When to call USM.removeEngineTime

[Tjip Pasma]

Hi

This is actually an interesting case, im gonna check if Im facing this
same case for my system.....

Management of engineTime / engineBoots is to my experience pretty
flawed, as the majority of implementations that i know of, base their
engineTime on their operating system time. 
The consequence of this is that if you modify the OS-time on the agent
then you may end up with an agent that you wont be able to talk to with
snmp v3. 
(read more details here
http://lists.agentpp.org/pipermail/snmp4j/2008-April/002832.html)

I made a fix for the above case by modifying snmp4j (in
UsmTimeTable.checkTime, i can send you my fix if you want) so it will
allow an agent to use an engineTime's with a lower value than expected
by checkTime. I would suggest that you modified in a similar way to
allow the specific case of an engineBoots of 1. (some would claim that
this violates usm security for snmp v3, however i see this as increasing
the robustness of snmp v3 :-)

Best Regards
Tjip Pasma



-----Original Message-----
From: snmp4j-bounces at agentpp.org [mailto:snmp4j-bounces at agentpp.org] On
Behalf Of Stath, Paul
Sent: 18. juni 2009 21:55
To: snmp4j at agentpp.org
Subject: [SNMP4J] When to call USM.removeEngineTime

I am using snmp4J in a long running program that performs SNMP
management functions.
 
The devices that we are managing store the value for engineBoots in
non-vol.
 
If the device is reset to factory default (by removing the non-vol
files) the value for
msgAuthoritativeEngineBoots becomes "1" when the device is rebooted.
 
If snmp4j has already discovered the values for engineBoots and
engineTime for this  device, any further USM PDU messages return a
REPORT PDU indicating that the msgAuthoritativeEngineTime provided by
snmp4j is wrong.  When this occurs, the device is unmanageable until the
program is restarted.
 
The removeEngineTime() method of the USM object appears to address this
problem, if I can get it called.
 
The ResposeEvent returned from Snmp.send(pdu, target) returns a null
value for getResponse().
 
If getReponse() would return the REPORT PDU, I could call
removeEngineTime() and resend the PDU.
 
If I'm using TableUtils, the RetrievalEvent has a getReportPDU() method
that returns a REPORT PDU.
 
Given that I need to clear the engineTime values for an already
discovered agent, what are my options, and which is cleanest?
 
1) Implement my own object with a send() method that returns a
RetrievalEvent rather than a ResponseEvent?
 
2) Implement an AuthenticationFailureListener class that listens for
AuthenticationFailureEvent messages and clears the engineTimes, allowing
the retry in MessageDispatherImpl to retry the PDU?
(This would require parsing the BERInputSteam to determine the specific
error, and get the engineID.)
 
3) Something else?
 
-- Paul Stath
_______________________________________________
SNMP4J mailing list
SNMP4J at agentpp.org
http://lists.agentpp.org/mailman/listinfo/snmp4j