RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
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:
Embargoed:


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.