Project

General

Profile

Bug #2354

SMSC: Store&Forward not working for subscribed but unregistered MS

Added by pespin 8 months ago. Updated 14 days ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
07/06/2017
Due date:
% Done:

90%

Resolution:

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:

  1. Core network + BTS is turned on, no MS available yet
  2. 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).
  3. 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.

History

#1 Updated by pespin 7 months 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 6 months ago

  • Priority changed from Normal to High

#3 Updated by laforge about 2 months ago

  • Assignee set to pespin

#4 Updated by laforge about 1 month ago

  • Assignee changed from pespin to stsp

#5 Updated by stsp 28 days ago

  • Status changed from New to In Progress

#6 Updated by stsp 21 days ago

  • Status changed from In Progress to Resolved

#7 Updated by pespin 21 days 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 21 days 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 20 days 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:

20180130101806745 DSMPP <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 )
20180130101806745 DSMPP <000c> smpp_smsc.c:727 [esme-63594] Rx SUBMIT-SM (6359563594/1/1)
20180130101806745 DLSMS <0016> smpp_openbsc.c:109 SMPP SUBMIT-SM for unknown subscriber: 6359563594 (NPI=1)
20180130101807164 DSMPP <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 )
20180130101807164 DSMPP <000c> smpp_smsc.c:727 [esme-63594] Rx SUBMIT-SM (63595/1/1)
20180130101807164 DLSMS <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 20 days 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 14 days ago

  • Status changed from In Progress to Resolved

Also available in: Atom PDF