Hi All snmpv3 managers that i know of will keep a copy for an agent's engineTime/engineBoots and use this information next time that the manager is making a request towards the agent. Snmp4j saves this information within the usm model (which is implemented as a singleton) which fully should enable the usage scenario you describe.
The agents engineTime / engineBoots is saved in the manager together with a the manager local timestamp (based on System.currentTimeMillis). This information is updated everytime a response is received from agent. Next time the manager is sending a snmpv3 request to the agent it will calculate the correct engineTime to use based on the stored engineTime and the difference between stored timestamp and current time. At a glance this looks just fine, but in reality this may fail in several different ways. 1. The speed that engineTime increases with in the agent may differ from the speed that the managers time is increasing with. This is a very likely situation since these two different time systems is based on different xtal's that is driving the time systems. If those two xtal have a difference of 500 ppm (which is high but not unrealistic) will cause a time difference of 1,8s within just one hour. If your manager is running as a 24/7 service and you make snmp request with large intervals then your system is fragile for this situation. (an interval of more than 3.5 days will fail for a 500 ppm difference) Solutions: A. let all agents / managers be based on same NTP time reference. B. Delete engineTime / engineBoots reference in manager if you havent made request for a longer period. 2. The engineTime used in the agents is typically based on the agents operating system. Changing the agents system time will cause a change to the agents engineTime. This is a poor implementation of the engineTime but unfortunately this is how this typically is implemented. Adjusting the agents time forward isnt that bad, as the snmp4j manager will recover in such case. Adjusting the agents time backwards will however cause a severe error as a snmp4j manager now will ignore the responses from the agent, and all requests to the agent will now fail. Solutions: A. snmp4j manager should detect if an agents engineTime is adjusted backwards and update the proxied information about this. B. This situation isnt possible to detect on a snmp4j API level. Its only possible to detect a timeout on the request. So whenever a timeout is detected then engineTime / engineBoots could be deleted. 3. snmp4j and other snmpv3 managers is based on the operating system's time to deal with enginetime calculations. This causes similar problems as in 2) If system time is adjusted forwards on the manager then all future comunication with ALL snmpv3 agents will fail with a timeout. If system time is adjusted backwards on the manager then the manager recovers (with a "received message outside time" message) Solutions: A In snmp4j manager replace use of System.currentTimeMillis with System.nanoTime if you are using java 1.5 B If communication have failed with timeout then delete engineTime / engineBoots references for that agent. Kind Regards Tjip Pasma -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of c v Sent: 1. februar 2009 01:48 To: Jochen Katz Cc: [email protected] Subject: Re: [SNMP4J] Accessing v3 servers who are ahead in time and UsmTimeTable Thanks for your quick response. If you are saying growing differences ... the way i implemented can also be a potential issue ... i have multiple components in same jvm trying to send/receive snmp requests (new snmp instance for each component) to same server at random times and they can conflict too .... as usm model is implemented as a singleton can there be a possible conflicts in times and misbehaviour that i'm seeing ? if that is the case ... can you suggest any implementation to work around this? On Sat, Jan 31, 2009 at 2:08 PM, Jochen Katz <[email protected]> wrote: > Hello, > > > When trying to access servers service snmp v3 which are in time > > ahead (8-10 hrs) than the sender. I received a bunch of the following messages. > > > > "CheckTime: received message outside time window (non authorative)" > > for SNMPv3 it is no problem, if manager and agent have different times. > But you have a problem if the times on manager and agent are growing > at different speeds and the difference increases by 150 seconds during > runtime of agent and manager. > > If you cannot keep the host times in sync or at a stable difference, > your only workaround would be to regularly remove the time information > from the USM time table. But you then lose part of the SNMPv3 security. > > Regards, > Jochen > _______________________________________________ > SNMP4J mailing list > [email protected] > http://lists.agentpp.org/mailman/listinfo/snmp4j > _______________________________________________ SNMP4J mailing list [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j _______________________________________________ SNMP4J mailing list [email protected] http://lists.agentpp.org/mailman/listinfo/snmp4j
