Wireshark-bugs: [Wireshark-bugs] [Bug 11349] New: Potentially wrong dissection of Time Zone (DST
Date: Thu, 09 Jul 2015 10:44:13 +0000
Bug ID 11349
Summary Potentially wrong dissection of Time Zone (DST not taken into account in TZ)
Product Wireshark
Version unspecified
Hardware All
OS All
Status UNCONFIRMED
Severity Minor
Priority Low
Component Dissection engine (libwireshark)
Assignee bugzilla-admin@wireshark.org
Reporter aggelos.asonitis@nsn.com

Build Information:
Version 1.10.7 (v1.10.7-0-g6b931a1 from master-1.10)

Copyright 1998-2014 Gerald Combs <gerald@wireshark.org> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Compiled (64-bit) with GTK+ 2.24.14, with Cairo 1.10.2, with Pango 1.30.1, with
GLib 2.34.1, with WinPcap (4_1_3), with libz 1.2.5, without POSIX capabilities,
without libnl, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.1, without Python,
with GnuTLS 2.12.18, with Gcrypt 1.4.6, without Kerberos, with GeoIP, with
PortAudio V19-devel (built Apr 22 2014), with AirPcap.

Running on 64-bit Windows 7 Service Pack 1, build 7601, with WinPcap version
4.1.3 (packet.dll version 4.1.0.2980), based on libpcap version 1.0 branch
1_0_rel0b (20091008), GnuTLS 2.12.18, Gcrypt 1.4.6, without AirPcap.
       Intel(R) Core(TM) i5-3340M CPU @ 2.70GHz, with 8071MB of physical
memory.


Built using Microsoft Visual C++ 10.0 build 40219

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.
--
>From the dissection code in file packet-gsm_a_dtap.c the comment says that it
conforms to 3GPP TS 23.040 version 6.6.0 Release 6.

/*
 * [3] 10.5.3.9 Time Zone and Time
 */
static guint16
de_time_zone_time(tvbuff_t *tvb, proto_tree *tree, packet_info *pinfo _U_,
guint32 offset, guint len _U_, gchar *add_string _U_, int string_len _U_)
{
    guint8    oct;
    guint32    curr_offset;
    char    sign;
    nstime_t tv;
    struct tm tm;

    curr_offset = offset;

    /* "unused" part of structure */
    tm.tm_wday = 0;
    tm.tm_yday = 0;
    tm.tm_isdst = -1;

    oct = tvb_get_guint8(tvb, curr_offset);
    tm.tm_year = (oct & 0x0f)*10 + ((oct & 0xf0) >> 4) + 100;
    oct = tvb_get_guint8(tvb, curr_offset+1);
    tm.tm_mon = (oct & 0x0f)*10 + ((oct & 0xf0) >> 4) - 1;
    oct = tvb_get_guint8(tvb, curr_offset+2);
    tm.tm_mday = (oct & 0x0f)*10 + ((oct & 0xf0) >> 4);
    oct = tvb_get_guint8(tvb, curr_offset+3);
    tm.tm_hour = (oct & 0x0f)*10 + ((oct & 0xf0) >> 4);
    oct = tvb_get_guint8(tvb, curr_offset+4);
    tm.tm_min = (oct & 0x0f)*10 + ((oct & 0xf0) >> 4);
    oct = tvb_get_guint8(tvb, curr_offset+5);
    tm.tm_sec = (oct & 0x0f)*10 + ((oct & 0xf0) >> 4);

    tv.secs = mktime(&tm);
    tv.nsecs = 0;

    proto_tree_add_time_format_value(tree, hf_gsm_a_dtap_time_zone_time, tvb,
curr_offset, 6,
                                     &tv, "%s", abs_time_to_ep_str(&tv,
ABSOLUTE_TIME_LOCAL, FALSE));
    curr_offset += 6;

    /* 3GPP TS 23.040 version 6.6.0 Release 6
     * 9.2.3.11 TP-Service-Centre-Time-Stamp (TP-SCTS)
     * :
     * The Time Zone indicates the difference, expressed in quarters of an
hour,
     * between the local time and GMT. In the first of the two semi-octets,
     * the first bit (bit 3 of the seventh octet of the
TP-Service-Centre-Time-Stamp field)
     * represents the algebraic sign of this difference (0: positive, 1:
negative).
     */

    oct = tvb_get_guint8(tvb, curr_offset);
    sign = (oct & 0x08)?'-':'+';
    oct = (oct >> 4) + (oct & 0x07) * 10;

    proto_tree_add_text(tree,
        tvb, curr_offset, 1,
        "Timezone: GMT %c %d hours %d minutes",
        sign, oct / 4, oct % 4 * 15);

    curr_offset++;

    /* no length check possible */

    return(curr_offset - offset);
}

>From the 3GPP 23.040 document itself the Timezone is said to:
... "take into account daylight saving time, such that when the sending entity
changes from regular (winter) time to daylight saving (summer) time, there is a
change to the value in the Time Zone field, for example in the UK the winter
setting is 00000000 and the summer setting is 01000000"...

The way I understand this, is that apart from the most significant bit, that is
used as a sign, the 2nd most significant bit is used to denote the daylight
saving time. If my interpretation is correct then the dissector would translate
the DST bit as a number and would affect the calculated timezone value much
more than a simple +1 hour during summer.


You are receiving this mail because:
  • You are watching all bug changes.