Hi, Jeff. Have you taken this idea (consistent timestamp handling) further ? Discussion is good, and patches are appreciated, too!
Jeff Johnson wrote:
Back in April, Martin Carlsson of Lumentis observed in the thread entitled "engineTime and abrupt timechanges" that changes to the system time could prevent the agent from authenticating snmpv3 messages (reference
http://sourceforge.net/mailarchive/message.php?msg_id=8116151). In a subsequent message he proposes a patch which uses ticks since reboot via 'times()' instead of wall clock as the basis of the engineTime. In June in a different thread entitled "usmStatsNotInTimeWindows issues" Thomas Anders showed an additional problem with the current engineTime mechanism such that after an uptime of 248 days the engineTime calculation overflows, also causing problems. I recently encountered the first problem (and my search of sourceforge turned up these threads), so I incorporated Martin's solution, and it is working quite nicely.
The reason I'm writing is that since then, I've been looking at other portions of the net-snmp code which could also suffer when there are abrupt changes in the system time. Some of these are minor, such as sysORTable code producing strange timestamps. Others are potentially very bad, including all of the table cache support.
Would it make sense to revisit all of the code which currently uses system time and rewrite it to use a timebase that won't change when NTP or other mechanism are used to modify the system clock? Perhaps a generic timestamp library?
/jeff
------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
