[SNMP4J] SnmpV3 timeout issue with system clock drift

[Robert Pierce]

Hi Frank,
Thanks again for your help. I added some debug statements to my code. It
appears the engine boots are not changing. Unless I'm looking in the wrong
spot. Below shows what Im doing in the test. The app basically polls a
device every 10seconds and prints out the timeEntry info and then does a
get request. Everything works for a few hours but when the timedrift
happens all the requests are returning null. I noticed the timeDiff right
off the bat is off. Is this normal?
Let me know if you need more information.
Thanks again for your help.
Thanks,
Robert

Code Example:
....
UsmTimeTable timeTable = this.snmp.getUSM().getTimeTable();

UsmTimeEntry timeEntry = timeTable.getEntry(engineIdString);

System.err.println(engineIdString + " timeTable.getEngineBoots() =
"+timeTable.getEngineBoots() + " timeTable.getEngineTime() = " +
timeTable.getEngineTime() +
               " timeEntry.getEngineBoots() = "+timeEntry.getEngineBoots()
+ " timeEntry.getLatestReceivedTime() =" +
timeEntry.getLatestReceivedTime() + " timeEntry.getTimeDiff() = "  +
timeEntry.getTimeDiff());

event = snmp.getBulk(pdu, target);



Output:
//This is the output near the start of the application
50:00:00:09:03:00:00:00:00:00:00:00 timeTable.getEngineBoots() = 0
timeTable.getEngineTime() = 4 timeEntry.getEngineBoots() = 1
timeEntry.getLatestReceivedTime() =1726970 timeEntry.getTimeDiff() = 1170238


//This is the output of the last successful request.
50:00:00:09:03:00:00:00:00:00:00:00 timeTable.getEngineBoots() = 0
timeTable.getEngineTime() = 11038 timeEntry.getEngineBoots() = 1
timeEntry.getLatestReceivedTime() =1737896 timeEntry.getTimeDiff() = 1170127

//between these two requests there was a 3min shift shown by some logging
in my code

//This is the output when all the requests start to return null
50:00:00:09:03:00:00:00:00:00:00:00 timeTable.getEngineBoots() = 0
timeTable.getEngineTime() = 11527 timeEntry.getEngineBoots() = 1
timeEntry.getLatestReceivedTime() =1737896 timeEntry.getTimeDiff() = 1170127

On Thu, Nov 3, 2011 at 9:28 AM, Frank Fock <fock at agentpp.com> wrote:

> Hi,
>
> Are you sure that the below is caused by a clock drift?
> A reset of the engine boots counter at the manager
> seems to be more likely.
>
> You are right, that a notInTimeWindow error/report should be
> returned if the times of sender and responder are not in sync.
>
> Doing an automated rediscovery is a security issue.
>
> Best regards,
> Frank
>
> On 03.11.2011 17:19, Robert Pierce wrote:
> > Hi,
> > We are encountering an issue with particular AMD processors in that the
> > system clock drifts causing the snmpV3 requests to timeout after some
> > point. Even once the clock gets resynched, the request will continue to
> > timeout.
> > Couple questions:
> >
> > 1) Initially, I would of expected a time not in window exception instead
> of
> > a timeout?
> > 2) If I do a discoverAuthoritativeEngineID after it timeouts, the
> requests
> > starts working again. My question is it best practice to rediscover the
> >   engine ID on a timeout or exception? Or should I be looking at
> something
> > else, such as clearing the usm time table?
> >
> > Thanks again for your help.
> > Robert
> > _______________________________________________
> > 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
>
> _______________________________________________
> SNMP4J mailing list
> SNMP4J at agentpp.org
> http://lists.agentpp.org/mailman/listinfo/snmp4j
>