Hi I attached my fixes, there is actually two problems fixed in these two files. 1. In UsmTimeTable.checkTime there a check to see if the agents time have been set backwards and if it is then this new time is being accepted. This is where i would fix the issue with an agent reseting its engineBoots. 2. System.currentTimeMillis is replaced with System.nanoTime in misc. locations, this makes manager robust to changes in its own OS-time. This fix only works for java 1.5+
Its been a while since i did debugging of these issues but as far as i remember then you are not able to detect this issue on a snmp4j API level. The pdu request will end in a timeout just like you also have notiched. (A CounterEvent is send when this happens, so you may implement a an event listener that uses this event, but afair this didnt provide a robust and easy fix of the issues faced here) BR Tjip PS: if your manager rarely communicates with the agents then you may be facing the issue of agent time that "changes" If your manager reference clock is deviating with 500 ppm from the agents reference clock then in "just" 3,5 days the time will have drifted 150 seconds apart between thes two systems. So if you are communicating with time intervals of this size then you may wanna check what kind of differences you have in clock system. -----Original Message----- From: Stath, Paul [mailto:[email protected]] Sent: 19. juni 2009 15:25 To: Tjip Pasma; [email protected] Subject: RE: [SNMP4J] When to call USM.removeEngineTime Tjip: Thanks for your prompt reply. The devices I am managing are embedded, and don't have a real-time clock, so I don't have to worry about changes to the system time on the agents. However, I would be interested in your fix, since I have considered this course of action myself, and it would be nice to have a sanity check. In response to your referenced link, Frank indicates that the (latest) version of SNMP4J returns a Report PDU on a notInTimeWindow report. I'm not seeing this in the JavaDoc for SNMP4J 1.10, much less the latest SNMP4J back in 2008-Apr-02. (Looks like maybe v 1.21 or 1.5 based on Changelog.) Frank's response: http://lists.agentpp.org/pipermail/snmp4j/2008-April/002833.html I'm using SNMP4J v1.9.3d, and Snmp.send() is returning like a timeout, (ResonseEvent.getRespone() == null) even though Wireshark shows the ReportPDU being returning right away. Am I missing something? -- Paul > -----Original Message----- > From: Tjip Pasma [mailto:[email protected]] > Sent: Friday, June 19, 2009 7:08 AM > To: Stath, Paul; [email protected] > Subject: RE: [SNMP4J] When to call USM.removeEngineTime > > 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
