There are indeed some issues with the enginetime (at least in 5.0.8 and probably still in 5.1.x). We came across a similar problem when setting the clock with NTP for our boxes that lack a battery backed clock. They start up in 1970 and suddenly (back to the future) they are in 2004. Looking at the code there also seemed to be an overflow problem occuring after 248 days and some tests seemed to verify this. Both large time changes and the 248 days overflow causes the agent to get stuck in "notInTimeWindow"-mode.
It is all related to the fact that the engineTime is calculated with gettimeofday and in centiseconds. It is then stored in a signed (normally 32 bit) integer. On most platforms this value overflows after 2^31/100 seconds = 248,5 days. There was an earlier discussion on this subject in april. There is a fix for the problem (by me), use at own risk! It prolongs the timespan to ~68 years and fixes the time change problem. Only tested on Linux however. If you look in the archives you should be able to find the earlier discussion, subject was "engineTime and abrupt timechanges". Cheers, M --- Martin Carlsson, martin dot carlsson at lumentis dot se Lumentis AB, Jakobsdalsvagen 17, SE-126 53 Hagersten, Sweden +46 (0)8 52 76 75 66, Fax: +46 (0)8 52 76 75 99 -----Original Message----- when using 5.1.2.pre2 as a client against a 5.0.9 agent on Linux (Debian Woody), I recently ran into two (possibly related) problems: 1. The agent (uptime 268 days) suddenly started to answer all (previously working) SNMPv3 authPriv requests with a SNMP REPORT indicating an usmStatsNotInTimeWindows error, even if we use latest 5.1.2.pre2 as the client. Does this ring a bell with anyone? USM engine time is ~21.700.000, currently. Did I cross a magic boundary? 2. The 5.1.2.pre2 command-line tools (e.g. snmpget) handle this situation quite badly: after sending the request seven times (and getting the REPORT response each time), they hang in select() forever :( The agent responses *do* arrive at the client (as "snmpget -Ddump" shows). Restarting the agent will possibly fix the first issue (as it did for an agent on another machine) and hide the second, but I'd really prefer to track this down instead. Consequently, I can only turn on "-Dtoken" debugging on the client, not on the agent. Suggestions are highly appreciated. +Thomas -- Thomas Anders (thomas.anders at blue-cable.de) ------------------------------------------------------- This SF.Net email sponsored by Black Hat Briefings & Training. Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
