Bug #6358
closed
SMS from 4G fails - RP-DATA (MO) without DST or TPDU ?!?
Added by keith 3 months ago.
Updated 3 months ago.
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 to Bug #6207: "MO SMS without prior CM Service Request" for every SMS in 4G added
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
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?
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).
- Status changed from New to Closed
- Priority changed from High to Normal
Uf..
After reading some TS 100 942 (04.11), TS 23.272 and TS 23.040:
I see, RP-DA is the SMSC number. Somebody (!) programmed a SIM card without any SMSC number. :-(
I guess it's all good.
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.
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..
Also available in: Atom
PDF
