Bug #2354
SMSC: Store&Forward not working for subscribed but unregistered MS
90%
Description
The following issue is specific to the splitted NITB components (MSC, BSC, HLR, etc). Using NITB the following is handled correctly.
While writing osmo-gsm-tester smpp test to check use of Store&Forward mode, I run into the following scenario:
- Core network + BTS is turned on, no MS available yet
- An esme connects to the SMSC, and sends an SMS ("submit_sm" message with mode="Store&Forward") to an MS which is still not registered into the network (but it is subscribed, ie. it is on the database).
- the SMSC should store the SMS and send a submit_sm_resp message with everything correct, but instead it sends an error:
smpplib.exceptions.PDUError: ('(11) submit_sm_resp: Invalid Destination Address', 11)
I asked Neels about this and here's his detailed answer on the topic:
<neels> pespin: makes sense, because in the NITB we have the HLR information in the local database. With the MSC we need to ask the HLR to know whether a subscriber exists -- and so far we do this only for location updating and authentication when the subscriber attaches. <neels> pespin: it seems we need to either store all SMS unconditionally or add an FSM that asks the HLR whether to accept an SMS for a given number
The esme_ms_sms_storeforward.py test contains commnented code to trigger the issue. Once this is fixed, that part of the test needs to be uncommented and validated with it.
Related issues
History
#1 Updated by pespin over 3 years ago
- Project changed from OsmoSMSC to OsmoMSC
I just realized this is not the correct project for this bug report, as I'm talking about the openbsc implementation here. Moving to OsmoMSC.
#2 Updated by laforge over 3 years ago
- Priority changed from Normal to High
#3 Updated by laforge about 3 years ago
- Assignee set to pespin
#4 Updated by laforge about 3 years ago
- Assignee changed from pespin to stsp
#5 Updated by stsp almost 3 years ago
- Status changed from New to In Progress
#6 Updated by stsp almost 3 years ago
- Status changed from In Progress to Resolved
Fixed with https://gerrit.osmocom.org/#/c/5997/
#7 Updated by pespin almost 3 years ago
- Status changed from Resolved to In Progress
- Assignee changed from stsp to pespin
Re-opening and assigning to me as osmo-gsm-tester needs to be re-enabled.
#8 Updated by pespin almost 3 years ago
- Status changed from In Progress to Feedback
- % Done changed from 0 to 90
Patch revert disabled part of the test in https://gerrit.osmocom.org/#/c/6150/
#9 Updated by pespin almost 3 years ago
- Status changed from Feedback to In Progress
- Assignee changed from pespin to stsp
I merged the revert patch to re-enable the test but it seems it is still failing. In there we are using a different code path (smpp->smsc->msc->ms).
handle_smpp_submit in osmo-msc osmo-msc/src/libmsc/smpp_openbsc.c
you can find the pcap trace in https://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester_run/4966/artifact/trial-4966-run.tgz and inside that archive: run.2018-01-30_09-23-05/aoip_smpp/esme_ms_sms_storeforward.py/osmo-msc_10.42.42.6/pcap/
the ESME connected to the SMSC sends a submit_sm message to send an SMS to an MS which is in the subscriber db but didn't register yet (it's still powered off).
as a result, the SMS seems to fail and sends back error:
Frame 20: 84 bytes on wire (672 bits), 84 bytes captured (672 bits) Linux cooked capture Internet Protocol Version 4, Src: 10.42.42.6, Dst: 10.42.42.1 Transmission Control Protocol, Src Port: 2775, Dst Port: 54168, Seq: 34, Ack: 290, Len: 16 Short Message Peer to Peer, Command: Submit_sm - resp, Status: "Invalid destination address", Seq: 3, Len: 16 Length: 16 Operation: Submit_sm - resp (0x80000004) Result: Invalid destination address (0x0000000b) Sequence #: 3
you can see osmo-msc log in run.2018-01-30_09-23-05/aoip_smpp/esme_ms_sms_storeforward.py/osmo-msc_10.42.42.6/stderr
Important related bits:
[0;m20180130101806745 [1;34mDSMPP[0;m <000c> smpp_smsc.c:745 [esme-63594] smpp_pdu_rx(00 00 00 7d 00 00 00 04 00 00 00 00 00 00 00 02 00 01 01 36 33 35 39 34 00 01 01 36 33 35 39 35 36 33 35 39 34 00 03 00 00 00 00 00 00 00 00 47 6d 65 73 73 61 67 65 20 6e 72 2e 20 31 35 2c 20 73 6d 70 70 20 6d 65 73 73 61 67 65 20 77 69 74 68 20 77 72 6f 6e 67 20 64 65 73 74 2c 20 66 72 6f 6d 20 36 33 35 39 34 2c 20 74 6f 20 36 33 35 39 35 36 33 35 39 34 02 04 00 02 00 01 ) [0;m20180130101806745 [1;32mDSMPP[0;m <000c> smpp_smsc.c:727 [esme-63594] Rx SUBMIT-SM (6359563594/1/1) [0;m[1;38m20180130101806745 [1;33mDLSMS[0;m[1;38m <0016> smpp_openbsc.c:109 SMPP SUBMIT-SM for unknown subscriber: 6359563594 (NPI=1) [0;m20180130101807164 [1;34mDSMPP[0;m <000c> smpp_smsc.c:745 [esme-63594] smpp_pdu_rx(00 00 00 7b 00 00 00 04 00 00 00 00 00 00 00 03 00 01 01 36 33 35 39 34 00 01 01 36 33 35 39 35 00 03 00 00 00 00 01 00 00 00 4a 6d 65 73 73 61 67 65 20 6e 72 2e 20 31 36 2c 20 73 6d 70 70 20 73 65 6e 64 20 6e 6f 74 2d 79 65 74 2d 72 65 67 69 73 74 65 72 65 64 20 6d 65 73 73 61 67 65 2c 20 66 72 6f 6d 20 36 33 35 39 34 2c 20 74 6f 20 36 33 35 39 35 02 04 00 02 00 02 ) [0;m20180130101807164 [1;32mDSMPP[0;m <000c> smpp_smsc.c:727 [esme-63594] Rx SUBMIT-SM (63595/1/1) [0;m[1;38m20180130101807164 [1;33mDLSMS[0;m[1;38m <0016> smpp_openbsc.c:109 SMPP SUBMIT-SM for unknown subscriber: 63595 (NPI=1)
so it seems the error message comes from function "submit_to_sms"
#10 Updated by stsp almost 3 years ago
The above problem is fixed by https://gerrit.osmocom.org/#/c/6192/ and another tweak to the regression test by Pau.
#11 Updated by stsp almost 3 years ago
- Status changed from In Progress to Resolved
