[SNMP4J] When to call USM.removeEngineTime

[Stath, Paul]

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
>