Cellular Network Infrastructure

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.

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).

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.

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

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.

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.

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...

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.