Bug 684014

Summary: hrSystemDate timezone sign is incorrect
Product: [Fedora] Fedora Reporter: Bryan Mason <bmason>
Component: net-snmpAssignee: Jan Safranek <jsafrane>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: jsafrane
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 683680 Environment:
Last Closed: 2011-09-29 11:14:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 683680    
Bug Blocks:    

Description Bryan Mason 2011-03-10 21:59:35 UTC
+++ This bug was initially created as a clone of Bug #683680 +++

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-21.fc14

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.

--- Additional comment from bmason on 2011-03-10 13:29:41 EST ---

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.

--- Additional comment from bmason on 2011-03-10 13:49:24 EST ---

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 1 Jan Safranek 2011-09-29 11:14:47 UTC
I believe the bug is fixed in net-snmp-5.7, which has been in Rawhide (and F16) for some time.