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
