[SNMP4J] When to call USM.removeEngineTime

Frank Fock fock at agentpp.com
Thu Jun 25 09:08:46 CEST 2009 

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: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
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> SNMP4J mailing list
>> SNMP4J at agentpp.org
>> http://lists.agentpp.org/mailman/listinfo/snmp4j

-- 
AGENT++
http://www.agentpp.com
http://www.snmp4j.com
http://www.mibexplorer.com
http://www.mibdesigner.com

More information about the SNMP4J mailing list