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.
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:
functions: dtap_sms_cp_data (I think it asserts inside ELEM_MAND_LV).