https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6477
Summary: Wireshark packet_gsm-sms, display bug: SMS text
sparebits decode to '@'
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
Created an attachment (id=7284)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=7284)
pcap with SMS problem at frame 1497
Build Information:
Version 1.2.11
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.
--
Display a normal SMS text message (normal means: GSM 7 bit default alphabet)
with 15 character: "SMS from a toAA" is decoded and displayed by wireshark as
"SMS from a toAA@". Attached new_bug.pcap shows problem at frame # 1497.
The SMS text message "SMS from a toAA" takes 15 ASCII character. Applying usual
GSM 7 bit default alphabet encoding (pretty example in
http://www.dreamfabric.com/sms/hello.html), for each ASCII character the most
significant bit (elder hackers may remember this as "parity bit") is truncated,
so that a chain of 15 "septetts" or 105 bits is formed. The protocol carrying
the 15 septetts however is octet-oriented, so the last octet has only one
significant bit and 7 filler bits which have no meaning. To ensure proper
decoding, the septett count is transmitted in the SMS protocol
"TP-User-Data-Length".
The wireshark seems not to consider this TP-User-Data-Length when decoding and
displaying the SMS text message. The wireshark seems to take the last 7 filler
bits as a further septett and decodes it as '@' which is character of '000
0000' according SMS encoding scheme (3GPP TS 23.038).
Attached new_debug.pcap is taken from usual 3GPP Iu-PS interface. I recommend
to set "Filter" to "ranap" to make it easier to read. The problem described
above is found at frame # 1497 with 15 charater SMS "SMS from a toAA". You will
find also proper decoded SMSs at frame # 1458 with 14 character "SMS from a
toX" and at frame # 1536 with 16 character "SMS from a toBBB".
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.