https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9478
Bug ID: 9478
Summary: GSM SMS UDH fill bits still incorrect
Classification: Unclassified
Product: Wireshark
Version: 1.10.3
Hardware: x86
OS: Windows XP
Status: UNCONFIRMED
Severity: Trivial
Priority: Low
Component: Dissection engine (libwireshark)
Assignee: bugzilla-admin@xxxxxxxxxxxxx
Reporter: michael.lum@xxxxxxxxxxxxxxxxx
Build Information:
Version 1.10.3 (SVN Rev 53022 from /trunk-1.10)
Copyright 1998-2013 Gerald Combs <gerald@xxxxxxxxxxxxx> 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 (32-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, with MIT Kerberos, with GeoIP, with
PortAudio V19-devel (built Nov 1 2013), with AirPcap.
Running on Windows XP Service Pack 3, build 2600, 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)2 Duo CPU T9300 @ 2.50GHz, with 3581MB 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.
--
I believe 3432 corrected one bug and created another.
Given this:
http://anonsvn.wireshark.org/viewvc/trunk/epan/dissectors/packet-gsm_sms.c?r1=39494&r2=39493&pathrev=39494
I believe the only problem was that the array was sized to 6.
It should have been 7 and the first element of the array should have
been 0x00.
static guint8 fill_bits_mask[7] =
{ 0x00, 0x80, 0xc0, 0xe0, 0xf0, 0xf8, 0xfc };
The change to the least significant bit bitmasks was incorrect thus
causing non-zero fill bits to be shown. The fill bits bring the octet-based
header to a septet boundary.
The change for determining the number of bits is mathematically the
exact same as the original as far as I can tell.
Anyway a patch will be attached.
--
You are receiving this mail because:
You are watching all bug changes.