Project

General

Profile

Bug #2256

Malformed packet sending an SMS

Added by pespin 11 months ago. Updated 3 months ago.

Status:
New
Priority:
Low
Assignee:
Target version:
-
Start date:
05/15/2017
Due date:
% Done:

0%

Spec Reference:

Description

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 (244 KB) pespin, 05/15/2017 11:25 AM

malformed_packet_dtap.pcap (412 Bytes) pespin, 01/31/2018 05:42 PM

History

#1 Updated by neels 11 months ago

  • Description updated (diff)

#2 Updated by laforge 9 months 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 4 months 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 3 months 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 3 months 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.

Also available in: Atom PDF