Bug #2256

Malformed packet sending an SMS

Added by pespin over 2 years ago. Updated 3 months ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


While running the "sms" test from osmo-gsm-tester with 2 Sierra Wireless modems and a SysmoBTS+NITB. Scenario: 2 modems register to the network, one sends an SMS to the other one.
Sometimes the test fails and the receiving modem gets unregistered from the network without receiving the SMS.

I was trying to find out the differences between the PASS case and the FAIL case. I attach now the run directory for both cases. THey contain a pcap file from the NITB + GSMTAP enabled on the BTS.

Strangely enough, the malformed packet is on the test run which PASSed, while the same packet on the FAILed is not malformed. See frame number 1406 in run-good/osmo-nitb_10.42.42.1/pcap/*.pcap for the malformed packet: length inside CP-DATA should be 59 but it's 60.

runs.tar.gz runs.tar.gz 244 KB pespin, 05/15/2017 11:25 AM
malformed_packet_dtap.pcap malformed_packet_dtap.pcap 412 Bytes pespin, 01/31/2018 05:42 PM
malformed_sms_edited.pcap malformed_sms_edited.pcap 413 Bytes fixeria, 05/08/2019 04:06 PM


#1 Updated by neels over 2 years ago

  • Description updated (diff)

#2 Updated by laforge over 2 years ago

  • Subject changed from Malformet packet sending an SMS to Malformed packet sending an SMS
  • Assignee set to pespin
  • Priority changed from Normal to Low

#3 Updated by pespin about 2 years ago

The issue about the MS not registering or becoming unregistered is almost 100% the issue already tracked (and for now it seems already solved by using incremental LAC) in #2456.

However, it may still be helpful to leave the ticket open to investigate whether the CP-DATA sent by the SMS is wrong or if there's a bug in wireshark not handling the data in there correctly.

#4 Updated by pespin almost 2 years ago

Related specs can be found in TS 124.011 7.2.1 (CP-DATA)
Referenced Protocol Discriminator is found in TS 124.007 TS 124.011. If TIO is 111, then a 2nd full octet is used as the id, but that's not the case in any of the messages in the traces.
As far as I can tell, the malformed packet announces a length of 60 bytes (3c), and has 60 bytes of payload. I'm not sure if the octet of the length is to be included in the count or not. If it should be included, then we miss 1 byte and it's a bug in the MS. If it should not be included, then there's a bug in wireshark dissector.

Related wireshark dissector bits:
file: epan/dissectors/packet-gsm_a_dtap.c
functions: dtap_sms_cp_data (I think it asserts inside ELEM_MAND_LV).

#5 Updated by pespin almost 2 years ago

I upload a pcap file containing only the 4 lapdm packets used to reconstruct the upper level one. It may be useful to test the dissector with only related important packets.

#6 Updated by laforge 9 months ago

  • Assignee changed from pespin to fixeria

maybe fixeria can share some of his SMS knowledge and review the pcap file?

#7 Updated by fixeria 9 months ago

Here is the result of my manual parsing:

0000  09 01 3c 00 1d 00 02 91  f7 35 15 b7 04 81 01 44   ..<..... .5.....D
0010  00 00 a7 31 ed f2 7c 1e  3e 97 41 6e b9 0b 14 63   ...1..|. >.An...c
0020  81 cc f2 77 1b f4 9a a7  cb 72 79 38 12 63 81 cc   ...w.... .ry8.c..
0030  f2 77 1b 14 83 d1 66 2c  10 fd 0d 8a 09 04         .w....f, ......

09 - Protocol discriminator (see struct gsm48_hdr)
01 - Message type: CP-DATA (TLV)
    3c - Length of the following RPDU (60 octets)
    RPDU (RP-DATA) follows. Actual length is 59 octets!
        00 - Message Type: RP-DATA (MS to Network)
        1d - SM-RP-MR: Message Reference (29)
        00 - SM-RP-OA: Originating Address (LV, 0 octets)
        02 - SM-RP-DA: Destination Address (LV, 2 octets)
            91 - Type of Number (SMSC address?)
                1... .... = Extension: No Extension
                .001 .... = Type of number: International Number (0x1)
                .... 0001 = Numbering plan identification: ISDN/Telephony Numbering (ITU-T Rec. E.164 / ITU-T Rec. E.163) (0x1)
            f7 - Called Party BCD Number: 7
        35 - Length of the following TPDU (53 octets)
        TPDU (TP-DATA) follows. Actual length is 52 octets!
            15 - TP message header
            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
            ..0. .... = TP-SRR: A status report is not requested
            ...1 0... = TP-VPF: TP-VP field present - relative format (2)
            .... .1.. = TP-RD: Instruct SC to reject duplicates
            .... ..01 = TP-MTI: SMS-SUBMIT (1)
            b7 - TP-MR: 183
            04 - TP-Destination-Address (LV, 4 digits)
                81 - Type of number (receiver address?)
                    1... .... = Extension: No extension
                    .000 .... = Type of number: Unknown (0)
                .... 0001 = Numbering plan: ISDN/telephone (E.164/E.163) (1)
                01 44 - TP-DA Digits: 1044
            00 - TP-PID: 0
                00.. .... = Defines formatting for subsequent bits: 0x0
                ..0. .... = Telematic interworking: no telematic interworking, but SME-to-SME protocol
                ...0 0000 = The SM-AL protocol being used between the SME and the MS: 0
            00 - TP-DCS: 0
                00.. .... = Coding Group Bits: General Data Coding indication (0)
                Special case, GSM 7 bit default alphabet
            a7 - TP-Validity-Period: 24 hours 0 minutes
            31 - TP-User-Data-Length: since DCS is 0x00, 49 septets
            APDU (User-Data) follows. Actual length is 42 octets!
            for 49 septets it should be at least 43 octets!!!

I find this message malformed because:

  • the indicated length of RPDU (RP-DATA) is incorrect: 60 octets, actual is 59 octets;
  • the indicated length of TPDU (TP-DATA) is incorrect: 53 octets, actual is 52 octets;
  • the indicated length of APDU (TP-User-Data) is incorrect: 49 septets, actual is 42 octets (shall be at least 43 octets);

Please see an attached capture where I hacked all three length values to get at least something decoded.
It looks like a few bytes (at least 3) at the end of the message are lost somehow. The decoded text is incomplete.

#8 Updated by fixeria 9 months ago

The decoded text is incomplete.

"SMS text: message nr. 1, from /sierra_1, from 1043, to 1$$"

I guess it should be "... to 123"?

It looks like a few bytes (at least 3)

Most likely, we are missing one octet.

#9 Updated by fixeria 9 months ago

  • Status changed from New to Feedback
  • Assignee changed from fixeria to pespin

If it should not be included, then there's a bug in wireshark dissector.

It shall indicate the length of the following part of the message, similar to a normal TLV.

If it should be included, then we miss 1 byte and it's a bug in the MS.

What if this is a bug of the LAPDm implementation (just guessing)?

maybe fixeria can share some of his SMS knowledge and review the pcap file?

That's all I can conclude, assigning back to Pau...

#10 Updated by pespin 3 months ago

  • Status changed from Feedback to Closed

I haven't seen this one for a while and it seems a bug from MS anyway, so closing it. We can always reopen it if we see something similar again.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)