Hi Tjip, As I wrote several times on the list: (1) SNMP4J 1.x is designed for Java 1.4, therefore System.nanoTime cannot be used. (2) Automatically accepting time changes from a SNMPv3 entity makes its security concept (nearly) worthless. You should then use SNMPv1/v2c instead.
Best regards, Frank Tjip Pasma wrote: > 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 -- AGENT++ http://www.agentpp.com http://www.snmp4j.com http://www.mibexplorer.com http://www.mibdesigner.com _______________________________________________ SNMP4J mailing list [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j
