Menu
▾
▴
[ net-snmp-Bugs-3178389 ] hrSystemDate (.1.3.6.1.2.1.25.1.2) reporting incorrectly
|
From: SourceForge.net <no...@so...> - 2011-03-10 15:51:53
|
Bugs item #3178389, was opened at 2011-02-11 15:46 Message generated for change (Settings changed) made by dts12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112694&aid=3178389&group_id=12694 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: agent Group: linux >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Steven K (stevenklestinec) Assigned to: Nobody/Anonymous (nobody) Summary: hrSystemDate (.1.3.6.1.2.1.25.1.2) reporting incorrectly Initial Comment: On net-snmp version 5.4, which we use with Fedora 11, when I snmpwalk the hrSystemDate MIB of ".1.3.6.1.2.1.25.1.2" I get a correct response of -6 for my UTC offset (Chicago) so we can verify system times are correct on all our systems. Example Output from net-snmp 5.4 (correct): HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-2-10,14:21:56.0,-6:0 However, we have introduced new systems into our environment which involved using Fedora 14, which included net-snmp 5.5 and now we are getting the UTC offset results incorrectly. Now instead of showing a -6 for the time zone, it is showing a +6. Example output from net-snmp 5.5 (wrong): HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-2-10,14:21:51.0,+6:0 If I set the timezone to Los Angeles on 5.4 (correct): HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-2-10,14:38:8.0,-8:0 If I set the timezone to Los Angeles on 5.5 (wrong): HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-2-10,14:35:18.0,+8:0 So as you can see, the timezone is opposite no matter where I set the timezone. Instead of Los_Angeles being -8 as per the Correct Timezone offset, it is reporting as the opposite side of the world. For some reason the sign is being reversed from negative to positive. I installed net-snmp 5.4 on the Fedora 14 box and it started reporting correctly. I have tested 5.5 and 5.6 on FC14 and FC11, and the issue follows the net-snmp version above 5.4, not the Fedora Release, so I suspect something has changed since 5.5 which is causing this to report incorrectly. Please let me know if you need anything else to fix this bug ---------------------------------------------------------------------- >Comment By: Dave Shield (dts12) Date: 2011-03-10 15:51 Message: SVN revision 20104 ---------------------------------------------------------------------- Comment By: Dave Shield (dts12) Date: 2011-03-10 15:51 Message: Thanks for the bug report! We've fixed the problem in the 5.3.x, 5.4.x, 5.5.x and 5.6.x code branches and the main development tree, so it should be fixed in future releases of the Net-SNMP package. ---------------------------------------------------------------------- Comment By: Dave Shield (dts12) Date: 2011-03-08 17:29 Message: Good catch! What seems to be happening is that the earlier code isn't detecting that the 'struct tm' contains a field tm_gmtoff, so is falling back to the older 'timezone' global variable. The 5.5 code (and above) *does* detect this field, so uses that instead. What nobody has noticed until now is that 'timezone' is defined as the number of seconds *west* of UTC, while tm_gmtoff is defined as the number of seconds *east* of UTC. Argghhhh!!! I would love to hear an explanation from the time people as to why this inconsistency arose! OK - that should be a fairly trivial fix. We'll try to get it in place as soon as possible. ---------------------------------------------------------------------- Comment By: Steven K (stevenklestinec) Date: 2011-02-11 15:54 Message: Africa/Cairo on 5.4 shows (correctly): HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-2-11,17:53:30.0,+2:0 Africa/Cairo on 5.5 shows (wrong): HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-2-11,17:53:32.0,-2:0 Cairo should be +2, so as you can see it inverses the timezone even if we set it to the other side of the world ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=112694&aid=3178389&group_id=12694 |