Bug 683680 - hrSystemDate timzeone sign is incorrect
Summary: hrSystemDate timzeone sign is incorrect
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: net-snmp
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Jan Safranek
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 684014
TreeView+ depends on / blocked
 
Reported: 2011-03-10 00:42 UTC by Bryan Mason
Modified: 2018-11-14 14:31 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Prior to this update, the snmpd daemon did report HOST-RESOURCES-MIB::hrSystemDate with erroneous sign in timezone offset. This update makes sure, that timezone offset reported by snmpd is properly recalculated and the timezone offset is correct. (BZ#683680).
Clone Of:
: 684014 (view as bug list)
Environment:
Last Closed: 2011-12-06 17:11:42 UTC
Target Upstream Version:


Attachments (Terms of Use)
Proposed Patch (480 bytes, patch)
2011-03-10 18:29 UTC, Bryan Mason
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2011:1524 0 normal SHIPPED_LIVE net-snmp bug fix update 2011-12-06 01:02:35 UTC

Description Bryan Mason 2011-03-10 00:42:51 UTC
Description of problem:

    Querying hrSystemDate returns a value for the time zone which is
    negative when it should be positive and positive when it should be
    negative.

Version-Release number of selected component (if applicable):

    net-snmp-5.5-27.el6.x86_64

How reproducible:

    100%

Steps to Reproduce:

 1. Configure net-snmp to allow public queries for hrSystemDate by adding

        view    systemview    included   .1.3.6.1.2.1.25.1.2
    
    to /etc/snmp/snmpd.conf.

 2. Restart snmpd ("service snmpd restart")
 3. Run

        snmpwalk -c public -v1 localhost hrSystemDate; date '+%F,%T,%z'

Actual results:

    # snmpwalk -c public -v1 localhost hrSystemDate;date '+%F,%T,%z'
    HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-3-9,16:37:47.0,+8:0
    End of MIB
    2011-03-09,16:37:47,-0800

    (Note that the sign on the timezone of snmpwalk and date differ)

Expected results:

    # snmpwalk -c public -v1 localhost hrSystemDate;date '+%F,%T,%z'
    HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-3-9,16:37:47.0,-8:0
    End of MIB
    2011-03-09,16:37:47,-0800

    (Note that the sign on the timezone of snmpwalk and date agree)

Additional info:

* Also reported upstream: 
http://sourceforge.net/tracker/index.php?func=detail&aid=3178389&group_id=12694&atid=112694

* Patch forthcoming.

Comment 1 Bryan Mason 2011-03-10 18:29:41 UTC
Created attachment 483534 [details]
Proposed Patch

The attached patch resolves the issue in my testing.  The problem appears to be with the following bit of code in date_n_time() in snmplib/snmp-tc.c:

    167 #ifdef HAVE_STRUCT_TM_TM_GMTOFF
    168     const int tzoffset = tm_p->tm_gmtoff;
    169 #else
    170     const int tzoffset = timezone;
    171 #endif

The problem is that, according to the comments in /usr/include/time.h, tm_gmtoff is "Seconds east of UTC" whereas timezone appears to be "Seconds west of UTC."

in RHEL 6, HAVE_STRUCT_TM_TM_GMTOFF is true, so gm_gmtoff is used to generate the timezone information.  In RHEL 5, this value (actually STRUCT_TM_HAS_TM_GMTOFF) is false, so timezone is used and the value of tzoffset is correct.

I believe the fix is to simply negate the value of tm_p->tm_gmtoff before assigning it to tzoffset.

Comment 2 Bryan Mason 2011-03-10 18:49:24 UTC
As it turns out, upstream has the same solution.  And we both came up with that solution within hours of each other. :)

http://net-snmp.svn.sourceforge.net/viewvc/net-snmp/trunk/net-snmp/snmplib/snmp-tc.c?r1=20006&r2=20104

Comment 5 Jan Safranek 2011-03-11 08:08:03 UTC
Thanks for detailed description and patch.

Comment 8 Karel Srot 2011-07-14 11:29:09 UTC
> I believe the fix is to simply negate the value of tm_p->tm_gmtoff before
> assigning it to tzoffset.

I am not sure it is enough. E.g. CEST (Central European Summer Time) is UTC+2:00 but snmpd returns -1:00. On the other hand, it would be OK if snmpd is supposed to ignore summer time.

[ksrot@dhcp-30-102 ~]$ rpm -q net-snmp
net-snmp-5.5-31.el6.x86_64
[ksrot@dhcp-30-102 ~]$ snmpwalk -c public -v1 localhost hrSystemDate
HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-7-14,13:27:9.0,-1:0
[ksrot@dhcp-30-102 ~]$ date '+%F,%T,%z'
2011-07-14,13:27:12,+0200

Comment 9 Jan Safranek 2011-08-01 12:43:40 UTC
(In reply to comment #8)
> > I believe the fix is to simply negate the value of tm_p->tm_gmtoff before
> > assigning it to tzoffset.
> 
> I am not sure it is enough. E.g. CEST (Central European Summer Time) is
> UTC+2:00 but snmpd returns -1:00. On the other hand, it would be OK if snmpd is
> supposed to ignore summer time.

Yes, also the daylight saving time was calculated incorrectly, it should be fixed now.

Comment 10 Jan Safranek 2011-08-11 11:33:31 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Prior to this update, the snmpd daemon did report HOST-RESOURCES-MIB::hrSystemDate with erroneous sign in timezone offset.  This update makes sure, that timezone offset reported by snmpd is properly recalculated and the timezone offset is correct. (BZ#683680).

Comment 12 Arjen Heidinga 2011-08-25 11:39:05 UTC
hmmm, after applying the patch it still not good:

Before patch:
[root@bigbrother snmp]# snmpwalk -c public -v 1 lipwig 1.3.6.1.2.1.25.1.2
HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-8-25,13:20:59.0,-1:0

After patch:
[root@bigbrother snmp]# snmpwalk -c public -v 1 lipwig 1.3.6.1.2.1.25.1.2
]HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-8-25,13:36:43.0,+3:0

Should be:
[root@bigbrother snmp]# snmpwalk -c public -v 1 leeuwarden 1.3.6.1.2.1.25.1.2
HOST-RESOURCES-MIB::hrSystemDate.0 = STRING: 2011-8-25,13:37:22.0,+2:0

Comment 13 Jan Safranek 2011-08-25 12:27:25 UTC
(In reply to comment #12)
> hmmm, after applying the patch it still not good:


That's why I mentioned daylight saving in comment #10, you need also SVN rev. 20169 and 20172 to calculate it correctly (or wait for RHEL 6.2 Beta).

Comment 15 errata-xmlrpc 2011-12-06 17:11:42 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2011-1524.html


Note You need to log in before you can comment on or make changes to this bug.