Wireshark-bugs: [Wireshark-bugs] [Bug 9643] New: False BER error indicated when IMSI is present
Date: Thu, 16 Jan 2014 12:56:17 +0000
Bug ID 9643
Summary False BER error indicated when IMSI is present in segmented TCAO MO message
Classification Unclassified
Product Wireshark
Version unspecified
Hardware x86
OS Windows 7
Status UNCONFIRMED
Severity Normal
Priority Low
Component Wireshark
Assignee bugzilla-admin@wireshark.org
Reporter gahan.robert@gmail.com

Created attachment 12476 [details]
pcap for bug

Build Information:
Version 1.11.3-SVN-54548 (SVNRev 54548 from /trunk)

Copyright 1998-2014 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 (32-bit) with GTK+ 3.4.4, with Cairo 1.10.2, with Pango 1.30.1, with
GLib 2.32.4, with WinPcap (4_1_3), with libz 1.2.5, 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 Jan  1 2014),
with AirPcap.

Running on 32-bit Windows 7 Service Pack 1, build 7601, 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) i5-2430M CPU @ 2.40GHz, with 3240MB 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.




--
Here is an example of a TCAP Segmented MO
message submission. The IMSI is legitimately
included (optional field) but is being displayed 
as "BER Error: This field lies beyond the end 
of the known sequence definition."

The TCAP primitive lacks an application context
(this is to be expected for TCAP segmentation) 
but the opcode value alone, could be used to detect 
and decode the IMSI correctly (as it indicates MO)

MO-ForwardSM-Arg ::= SEQUENCE {
    sm-RP-DA        SM-RP-DA,
    sm-RP-OA        SM-RP-OA,
    sm-RP-UI        SignalInfo,
    extensionContainer  ExtensionContainer  OPTIONAL,
    ... ,
    imsi            IMSI        OPTIONAL }

MO-ForwardSM-Res ::= SEQUENCE {
    sm-RP-UI        SignalInfo  OPTIONAL,
    extensionContainer  ExtensionContainer  OPTIONAL,
    ...}

MT-ForwardSM-Arg ::= SEQUENCE {
    sm-RP-DA        SM-RP-DA,
    sm-RP-OA        SM-RP-OA,
    sm-RP-UI        SignalInfo,
    moreMessagesToSend  NULL            OPTIONAL,
    extensionContainer  ExtensionContainer  OPTIONAL,
    ...,
    smDeliveryTimer SM-DeliveryTimerValue   OPTIONAL,
    smDeliveryStartTime Time            OPTIONAL,
    smsOverIP-OnlyIndicator [0] NULL        OPTIONAL }
    -- SM-DeliveryTimerValue contains the value used by the SMS-GMSC

This extract in packet-gsm_map-template.c should not take application_context
into consideration

  case 46: /*mo-forwardSM(v3) or ForwardSM(v1/v2)*/
    if (application_context_version == 3)
      offset=dissect_gsm_map_sm_MO_ForwardSM_Arg(FALSE, tvb, offset, actx,
tree, -1);
    else {
      offset=dissect_gsm_old_ForwardSM_Arg(FALSE, tvb, offset, actx, tree, -1);
    }
    break;

    perhaps something like the following change  ??

  case 46: /*mo-forwardSM(v3) */
    offset=dissect_gsm_map_sm_MO_ForwardSM_Arg(FALSE, tvb, offset, actx, tree,
-1);
    break;


No.     Time        Source                Destination           Protocol Length
Info
      1 0.000000    65793                 131586                GSM SMS  330   
invoke forwardSM 

Frame 1: 330 bytes on wire (2640 bits), 330 bytes captured (2640 bits)
Ethernet II, Src: Private_01:01:01 (01:01:01:01:01:01), Dst:
MS-NLB-PhysServer-02_02:02:02:02 (02:02:02:02:02:02)
Internet Protocol Version 4, Src: 1.1.1.1 (1.1.1.1), Dst: 2.2.2.2 (2.2.2.2)
Stream Control Transmission Protocol, Src Port: 4901 (4901), Dst Port: 4901
(4901)
MTP 3 User Adaptation Layer
Signalling Connection Control Part
Transaction Capabilities Application Part
GSM Mobile Application
    Component: invoke (1)
        invoke
            invokeID: 89
            opCode: localValue (0)
            sm-RP-DA: serviceCentreAddressDA (4)
            sm-RP-OA: msisdn (2)
            sm-RP-UI: 31850b819063698665f20008ff8806450646002006a90647...
            BER Error: This field lies beyond the end of the known sequence
definition.
GSM SMS TPDU (GSM 03.40) SMS-SUBMIT
    0... .... = TP-RP: TP Reply Path parameter is not set in this SMS
SUBMIT/DELIVER
    .0.. .... = TP-UDHI: The TP UD field contains only the short message
    ..1. .... = TP-SRR: A status report is requested
    ...1 0... = TP-VPF: TP-VP field present - relative format (2)
    .... .0.. = TP-RD: Instruct SC to accept duplicates
    .... ..01 = TP-MTI: SMS-SUBMIT (1)
    TP-MR: 133
    TP-Destination-Address - (09369668562)
        Length: 11 address digits
        1... .... :  No extension
        .000 .... :  Type of number: (0) Unknown
        .... 0001 :  Numbering plan: (1) ISDN/telephone (E.164/E.163)
        TP-DA Digits: 09369668562
    TP-PID: 0
    TP-DCS: 8
        00.. .... = Coding Group Bits: General Data Coding indication (0)
        00.. .... :  General Data Coding indication
        ..0. .... :  Text is not compressed
        ...0 .... :  Reserved, no message class
        .... 10.. :  Character set: UCS2 (16 bit)
        .... ..00 :  Message Class: Class 0 (reserved)
    TP-Validity-Period: 63 week(s)
    TP-User-Data-Length: (136) depends on Data-Coding-Scheme
    TP-User-Data
        [SMS text: XXXXXXXXXXXXXXXXXXXXXXXXXXX]


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