Wireshark-bugs: [Wireshark-bugs] [Bug 6469] New: Wireshark packet_gsm-sms, display bug: Filler b
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6469
Summary: Wireshark packet_gsm-sms, display bug: Filler bits in
TP-User Data Header
Product: Wireshark
Version: 1.2.11
Platform: x86-64
OS/Version: Debian
Status: NEW
Severity: Minor
Priority: Low
Component: Wireshark
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: konrad.lenz@xxxxxxxx
CC: guy@xxxxxxxxxxxx
Build Information:
Version 1.2.11
Copyright 1998-2010 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 with GTK+ 2.20.1, (64-bit) with GLib 2.24.2, with libpcap 1.1.1, with
libz 1.2.3.4, with POSIX capabilities (Linux), with libpcre 8.2, with SMI
0.4.8,
with c-ares 1.7.3, with Lua 5.1, with GnuTLS 2.8.6, with Gcrypt 1.4.5, with MIT
Kerberos, with GeoIP, with PortAudio V19-devel (built Nov 25 2010), without
AirPcap.
Running on Linux 2.6.32-5-amd64, with libpcap version 1.1.1, GnuTLS 2.8.6,
Gcrypt 1.4.5.
Built using gcc 4.4.5.
--
Decode a Concatenated SMS, according 3GPP TS 23.040 9.2.3.24.1, which has a
TP-User-Data Header and TP User Data encoded GSM 7bit default alphabet.
Wireshark decodes and displays TP User Data Header Information Element Type 0x0
"Concatenated short message, 8-bit reference number (SMS Control)".
According 3GPP spec, after the TP User Data Header, usually 6 octets (48bit), a
filler bit is inserted to meet the requirement of 3GPP spec: "If 7 bit data is
used and the TP‑UD‑Header does not finish on a septet boundary then fill bits
are inserted after the last Information Element Data octet up to the next
septet boundary so that there is an integral number of septets for the entire
TP‑UD header".
There is a display bug in wireshark concerning these Fill bits.
While the TP User Data Header mentioned above takes 48 bit, one Fill bit is
needed to meet septet boundary at 49 bit. This Fill bit is the least
significant bit (Bit0) of next octet.
However, wireshark mentiones two fill bits here taken from the both most
significant bits (Bit8 Bit7) from next octet. This is just a display problem
because rest of data (the TP User Data) are decoded properly.
Looking into source code of packet-gsm_sms.c, the bug is obvious:
Line # 2600 printing variable "oct" as "User Data Header Length" with a value
of 5
Line # 2617: fill_bits = 7 - (((oct+1)*8)%7);
so "fill_bits" get the value of 1 (one fill bit)
Line # 2622: fill_bits used as index into array fill_bits_mask[]
Line # 2551: fill_bits_mask[ 1 ] == 0xc0
Regarding the GSM 7 bit encoding method (see example in
http://www.dreamfabric.com/sms/hello.html ) the improved setting of
fill_bits_mask[] should be:
improved Line 2551:
static guint8 fill_bits_mask[ NUM_FILL_BITS_MASK + 1 ] =
{ 0x0, 0x01, 0x03, 0x07, 0x0f, 0x1f, 0x3f };
Konrad Lenz, NG4T, konrad.lenz@xxxxxxxx
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
