Bug #6358
closedSMS from 4G fails - RP-DATA (MO) without DST or TPDU ?!?
0%
Description
WE currently cannot send SMS from a UE on 4G RAN
RP-DATA (MO) without DST or TPDU ?!?
20240213001943906 DLSMS DEBUG trans(SMS IMSI-334070000000968:MSISDN-68070122968:TMSI-0x1DCB852B:EUTRAN-SGs:CM_SERVICE_REQ callref-0x4000000c tid-8) RX_RP-DATA: src_len=0, dst_len=0 ud_len=15 (gsm_04_11.c:768) 20240213001943906 DLSMS ERROR trans(SMS IMSI-334070000000968:MSISDN-68070122968:TMSI-0x1DCB852B:EUTRAN-SGs:CM_SERVICE_REQ callref-0x4000000c tid-8) RP-DATA (MO) without DST or TPDU ?!? (gsm_04_11.c:775) 20240213001943906 DLSMS NOTICE trans(SMS IMSI-334070000000968:MSISDN-68070122968:TMSI-0x1DCB852B:EUTRAN-SGs:CM_SERVICE_REQ callref-0x4000000c tid-8) TX: SMS RP ERROR, cause 96 (Invalid Mandatory Information) (gsm_04_11.c:714)
Maybe this is due to a change in latest open5gs?
Files
Related issues
Updated by keith 3 months ago
So, as can be seen in the pcap, the RP-DATA in this NAS message container from open5gs does not have any RP-Destination Address field. (length is 0)
So we fail here:
if (!dst_len || !dst || !rpud_len || !rp_ud) {
LOG_TRANS(trans, LOGL_ERROR,
"RP-DATA (MO) without DST or TPDU ?!?\n");
gsm411_send_rp_error(trans, rph->msg_ref,
GSM411_RP_CAUSE_INV_MAND_INF);
return -EIO;
}
Question: Is this an error on the part of open5gs, or is this RP-DATA spec-legal and we should parse the RP-User Data (TPDU) for the destination address?
NAS message container Element ID: 0x16 Length: 23 GSM A-I/F DTAP - CP-DATA Protocol Discriminator: SMS messages (9) .... 1001 = Protocol discriminator: SMS messages (0x9) 0... .... = TI flag: allocated by sender .101 .... = TIO: 5 DTAP Short Message Service Message Type: CP-DATA (0x01) CP-User Data Length: 20 RPDU (not displayed) GSM A-I/F RP - RP-DATA (MS to Network) Message Type RP-DATA (MS to Network) RP-Message Reference RP-Message Reference: 0xba (186) RP-Originator Address Length: 0 RP-Destination Address Length: 0 RP-User Data Length: 15 TPDU (not displayed) GSM SMS TPDU (GSM 03.40) SMS-SUBMIT 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 ...0 0... = TP-VPF: TP-VP field not present (0) .... .1.. = TP-RD: Instruct SC to reject duplicates .... ..01 = TP-MTI: SMS-SUBMIT (1) TP-MR: 186 TP-Destination-Address - (68070144444) Length: 11 address digits 1... .... = Extension: No extension .000 .... = Type of number: Unknown (0) .... 0001 = Numbering plan: ISDN/telephone (E.164/E.163) (1) TP-DA Digits: 68070144444 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 TP-DCS: 0 00.. .... = Coding Group Bits: General Data Coding indication (0) Special case, GSM 7 bit default alphabet TP-User-Data-Length: (2) depends on Data-Coding-Scheme TP-User-Data SMS text: Ok
Updated by keith 3 months ago
Looking at three phones, and capturing this time the S1AP between the radio and open5gs, (open5gs at a glance and a guess, is simply forwarding the NAS msg container verbatim)
The HTC is indeed sending
RP-Destination Address Length: 0
The other two phones, a samsung and a xiaomi send:
RP-Destination Address - (7) Length: 2 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) Called Party BCD Number: 7
So it looks like we need osmo-msc to accept zero length RP-Destination Address?
Updated by keith 3 months ago
Interesting: Possibly related, https://nickvsnetworking.com/the-surprisingly-complicated-world-of-sms-apple-iphone-mt-sms/
Updated by laforge 3 months ago
Hi Keith,
On Tue, Feb 13, 2024 at 06:25:33PM +0000, keith wrote:
Looking at three phone, and capturing this time, the S1AP between the radio and open5gs, the htc is indeed sending [...]
Are you sure you're using the same SIM card between those attempts? Maybe the EF.SMSP contains different conten between your different phones? Didn't the RP-layer normally contain the GlobalTitle of the SMSC? Or am I mixing things here (sorry, just recalling off my head).
Updated by fixeria 3 months ago
keith wrote in #note-3:
The HTC is indeed sending [...]
keith are you sure you have the SMSC address configured on that HTC phone?
I think we have already seen such behavior in the absence of SMSC address. Some phones require the user to set it before sending SMS, some do not and send with empty RP-Destination Address.
Updated by keith 3 months ago
Thanks laforge and fixeria, Yes I realised what was going on after checking that the spec indeed requires a min length of 2 for the RP-DA and that there are no variations allowed for SMS over SGs, and also observing that the htc phone with this SIM also sends RP-DA of zero length on 2G.
Funny, this post from 2010, (back in the openBTS at the Burning Man days) came into my head, so I'll just leave this link here as it took a while to find it:
https://web.archive.org/web/20120124060701/http://openbts.blogspot.com/2010/10/smsc-address-caching-in-iphones.html
It's not the same issue as no SMSC configured, but maybe somebody is looking up SMSC problems sometime in the future..