[SNMP4J] When to call USM.removeEngineTime

[Tjip Pasma]

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:PStath at axxcelera.com] 
Sent: 19. juni 2009 15:25
To: Tjip Pasma; snmp4j at agentpp.org
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:tjip.pasma at ericsson.com]
> Sent: Friday, June 19, 2009 7:08 AM
> To: Stath, Paul; snmp4j at agentpp.org
> 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: snmp4j-bounces at agentpp.org
> [mailto:snmp4j-bounces at agentpp.org] On Behalf Of Stath, Paul
> Sent: 18. juni 2009 21:55
> To: snmp4j at agentpp.org
> 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
> SNMP4J at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j
>