Wireshark packet_gsm-sms, display bug: Filler bits in TP-User Data Header
This issue was migrated from bug 6469 in our old bug tracker.
Original bug information:
Reporter: Konrad Lenz
Status: RESOLVED FIXED
Product: Wireshark
Component: GTK+ UI
OS: Debian
Platform: x86-64
Version: 1.2.11
Attachments:
bug6469_gsmfillbits.pcap: pcap showing reported problem at frame # 1492/1495/...
packet-gsm_sms-fillbit.patch: GSM SMS fillbit fix
Activity
Build Information: Version 1.2.11
Copyright 1998-2010 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 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@ng4t.comadded osdebian uigtk version1.2 labels
-
Created attachment 7274 pcap showing reported problem at frame # 1492/1495/... PCAP showing the GSM/SMS Fill bit problem, as requested 2 by Comment #2 from Jaap Keuter. PCAP shows typical 3G UMTS traffic at Iu-CS interface with Mobile Phone Users registering and sending SMSs. Setting "Filter" to "ranap" makes reviewing easier. Between frame # 1490 and # 1510 you will see a Mobile Phone sending /etc/passwd as SMS which is split into 7 parts to form a "Concatenated SMS". Each part in frames 1492, 1495, 1496, 1498, 1499, 1501 and 1502 shows the problem described in this bug report. Note: the "malformed packets" around frame # 1540 are *not* from this bug or from wireshark, but corrupted SMS "Deliver" messages generated from our simulation. mentioned in issue #6477 (closed)