Bug #2256

Malformed packet sending an SMS

Added by pespin 10 months ago. Updated about 2 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 (244 KB) pespin, 05/15/2017 11:25 AM

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


#1 Updated by neels 10 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 3 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 about 2 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 about 2 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