Malformed packet sending an SMS
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.
#3 Updated by pespin over 1 year 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 over 1 year 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:
functions: dtap_sms_cp_data (I think it asserts inside ELEM_MAND_LV).
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.
- 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...