Wireshark-bugs: [Wireshark-bugs] [Bug 11347] New: Text for GSM H/L flags is not correct

Date: Wed, 08 Jul 2015 08:31:09 +0000
Bug ID 11347
Summary Text for GSM H/L flags is not correct
Product Wireshark
Version Git
Hardware x86
OS Windows 7
Status UNCONFIRMED
Severity Major
Priority Low
Component Dissection engine (libwireshark)
Assignee [email protected]
Reporter [email protected]

Created attachment 13715 [details]
File with SI1 message showing the issue.

Build Information:
Version 1.99.6-CustomizedVersionForSierraWireless-v1.3 (Git Rev Unknown from
unknown)

Copyright 1998-2015 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
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.23, with Cairo 1.12.16, with Pango 1.36.8,
with
WinPcap (4_1_3), with libz 1.2.8, with GLib 2.42.0, with SMI 0.4.8, with c-ares
1.9.1, with Lua 5.2, with GnuTLS 3.2.15, with Gcrypt 1.6.2, with MIT Kerberos,
with GeoIP, with PortAudio V19-devel (built Jul  6 2015), with AirPcap.

Running on 64-bit Windows 7 Service Pack 1, build 7601, with locale
French_France.1252, with WinPcap version 4.1.3 (packet.dll version 4.1.0.2980),
based on libpcap version 1.0 branch 1_0_rel0b (20091008), with GnuTLS 3.2.15,
with Gcrypt 1.6.2, without AirPcap.
Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz (with SSE4.2), with 7986MB of physical
memory.


Built using Microsoft Visual C++ 12.0 build 31101
--
The GSM H/L flags management is not correct: the gsm_rr_csn_HL_flag function
(in packet-gsm_a_rr.c) returns the right value for H or L, but the associated
text is not correctly displayed. (For more information on H and L values in
GSM, see 3GPP 24.007 section B.1.2.2.)

The "true" text value is indeed displayed when the corresponding bit is set to
1, and not when it is set to H. Same thing for the "false" text value, which is
used when the bit is set 0 and not when it is set to L.

There is no problem with the last stable Wireshark version (v1.12.6-0-gee1fce6
from master-1.12). I think that the issue was introduced by this commit :
https://code.wireshark.org/review/#/c/4435, as the proto_tree_add_bits_item
function has no knowledge of H and L values for one bit, but only of 0 and 1
values.
On a side note, this commit also removed the H/L notation in the bit field to
replace it by 0/1, which is not so clear.

You will find attached a pcap file showing the problem: in the SI1 Rest Octets,
the "Band Indicator" value is not correct. 
The master-1.12 version rightly displays:
.... ..L.: Band Indicator: 1800
while the master version wrongly displays:
.... ..1. = Band Indicator: 1900


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