https://osmocom.org/https://osmocom.org/favicon.ico?16647414092017-05-15T11:31:02ZOpen Source Mobile CommunicationsCellular Network Infrastructure - Bug #2256: Malformed packet sending an SMShttps://osmocom.org/issues/2256?journal_id=39042017-05-15T11:31:02Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/3904/diff?detail_id=5834">diff</a>)</li></ul> Cellular Network Infrastructure - Bug #2256: Malformed packet sending an SMShttps://osmocom.org/issues/2256?journal_id=45032017-07-10T22:12:29Zlaforge
<ul><li><strong>Subject</strong> changed from <i>Malformet packet sending an SMS</i> to <i>Malformed packet sending an SMS</i></li><li><strong>Assignee</strong> set to <i>pespin</i></li><li><strong>Priority</strong> changed from <i>Normal</i> to <i>Low</i></li></ul> Cellular Network Infrastructure - Bug #2256: Malformed packet sending an SMShttps://osmocom.org/issues/2256?journal_id=67312017-12-11T10:58:51Zpespin
<ul></ul><p>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 <a class="issue tracker-1 status-3 priority-2 priority-default closed" title="Bug: ofono: OsmGsmTester tests fail due to SierraW modem stating it is registered but it's not (Resolved)" href="https://osmocom.org/issues/2456">#2456</a>.</p>
<p>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.</p> Cellular Network Infrastructure - Bug #2256: Malformed packet sending an SMShttps://osmocom.org/issues/2256?journal_id=73762018-01-31T16:50:46Zpespin
<ul></ul><p>Related specs can be found in TS 124.011 7.2.1 (CP-DATA)<br />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.<br />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.</p>
<p>Related wireshark dissector bits:<br />file: epan/dissectors/packet-gsm_a_dtap.c<br />functions: dtap_sms_cp_data (I think it asserts inside ELEM_MAND_LV).</p> Cellular Network Infrastructure - Bug #2256: Malformed packet sending an SMShttps://osmocom.org/issues/2256?journal_id=73772018-01-31T17:42:48Zpespin
<ul><li><strong>File</strong> <a href="/attachments/2917">malformed_packet_dtap.pcap</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/2917/malformed_packet_dtap.pcap">malformed_packet_dtap.pcap</a> added</li></ul><p>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.</p> Cellular Network Infrastructure - Bug #2256: Malformed packet sending an SMShttps://osmocom.org/issues/2256?journal_id=142762019-05-08T14:48:31Zlaforge
<ul><li><strong>Assignee</strong> changed from <i>pespin</i> to <i>fixeria</i></li></ul><p>maybe <a class="user active" href="https://osmocom.org/users/67">fixeria</a> can share some of his SMS knowledge and review the pcap file?</p> Cellular Network Infrastructure - Bug #2256: Malformed packet sending an SMShttps://osmocom.org/issues/2256?journal_id=143112019-05-08T16:07:08Zfixeria
<ul><li><strong>File</strong> <a href="/attachments/3685">malformed_sms_edited.pcap</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3685/malformed_sms_edited.pcap">malformed_sms_edited.pcap</a> added</li></ul><p>Here is the result of my manual parsing:</p>
<pre>
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!!!
</pre>
<p>I find this message malformed because:</p>
<ul>
<li>the indicated length of RPDU (RP-DATA) is incorrect: 60 octets, actual is 59 octets;</li>
<li>the indicated length of TPDU (TP-DATA) is incorrect: 53 octets, actual is 52 octets;</li>
<li>the indicated length of APDU (TP-User-Data) is incorrect: 49 septets, actual is 42 octets (shall be at least 43 octets);</li>
</ul>
<p>Please see an attached capture where I hacked all three length values to get at least something decoded.<br />It looks like a few bytes (at least 3) at the end of the message are lost somehow. The decoded text is incomplete.</p> Cellular Network Infrastructure - Bug #2256: Malformed packet sending an SMShttps://osmocom.org/issues/2256?journal_id=143122019-05-08T16:14:00Zfixeria
<ul></ul><blockquote>
<p>The decoded text is incomplete.</p>
</blockquote>
<p>"SMS text: message nr. 1, from /sierra_1, from 1043, to 1$$"</p>
<p>I guess it should be "... to 123"?</p>
<blockquote>
<p>It looks like a few bytes (at least 3)</p>
</blockquote>
<p>Most likely, we are missing one octet.</p> Cellular Network Infrastructure - Bug #2256: Malformed packet sending an SMShttps://osmocom.org/issues/2256?journal_id=143132019-05-08T16:18:21Zfixeria
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li><li><strong>Assignee</strong> changed from <i>fixeria</i> to <i>pespin</i></li></ul><blockquote>
<p>If it should not be included, then there's a bug in wireshark dissector.</p>
</blockquote>
<p>It shall indicate the length of the following part of the message, similar to a normal TLV.</p>
<blockquote>
<p>If it should be included, then we miss 1 byte and it's a bug in the MS.</p>
</blockquote>
<p>What if this is a bug of the LAPDm implementation (just guessing)?</p>
<blockquote>
<p>maybe fixeria can share some of his SMS knowledge and review the pcap file?</p>
</blockquote>
<p>That's all I can conclude, assigning back to Pau...</p> Cellular Network Infrastructure - Bug #2256: Malformed packet sending an SMShttps://osmocom.org/issues/2256?journal_id=164382019-11-13T09:07:06Zpespin
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Closed</i></li></ul><p>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.</p>