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: [email protected] [mailto:[email protected]] On Behalf Of Stath, Paul Sent: 18. juni 2009 21:55 To: [email protected] 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 [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j _______________________________________________ SNMP4J mailing list [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j
