>>>>> On Tue, 21 Sep 2004 17:19:54 -0700, "Jeff Johnson" <[EMAIL PROTECTED]> said:
Jeff> Back in April, Martin Carlsson of Lumentis observed in the Jeff> thread entitled "engineTime and abrupt timechanges" that changes Jeff> to the system time could prevent the agent from authenticating Jeff> snmpv3 messages (reference Jeff> http://sourceforge.net/mailarchive/message.php?msg_id=8116151). Jeff> In a subsequent message he proposes a patch which uses ticks Jeff> since reboot via 'times()' instead of wall clock as the basis of Jeff> the engineTime. In June in a different thread entitled Jeff> "usmStatsNotInTimeWindows issues" Thomas Anders showed an Jeff> additional problem with the current engineTime mechanism such Jeff> that after an uptime of 248 days the engineTime calculation Jeff> overflows, also causing problems. I recently encountered the Jeff> first problem (and my search of sourceforge turned up these Jeff> threads), so I incorporated Martin's solution, and it is working Jeff> quite nicely. Yep. It's a known annoying bug. Unfortunately, the reason I haven't applied it is that I haven't had the time. The patch proposed is better but also suffers from additional problems: 1) it still doesn't increment boots or check for that. Granted, not likely to ever happen so I don't care about this that much. 2) The use of LONG_MAX, etc, when subtracting with a clock_t isn't probably ideally portable since there is no guarantee that clock_t == a long. 3) The patch as is will eventually fail as the window between the base time in the patch and the now time moves closer to 0 and that window is missed. This: if (now < snmpv3startClock) { ... snmpv3startClock = now; Will eventually make snmpv3startClock =~ 0 and the times() output wrap will be missed the closer it gets. (note that on a system boot, snmpv3startClock will likely be a low value) 4) proper configure tests needed to be written to check support for the library functions used. I am working on my version of the fix, based in large part on the original patch, and will check it in today or tomorrow in time for the 5.2.pre2 release. Don't get me wrong, I really appreciated the original patch. I just am a perfectionist even when it hurts me and that has caused me to delay patches too long in some cases, and this is one of those cases. Bad me. Jeff> Would it make sense to revisit all of the code which currently Jeff> uses system time and rewrite it to use a timebase that won't Jeff> change when NTP or other mechanism are used to modify the system Jeff> clock? Perhaps a generic timestamp library? Yes. Good suggestion. -- Wes Hardaker Sparta ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Net-snmp-coders mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
