aboutsummaryrefslogtreecommitdiffstats
path: root/openbsc/src/libmsc
AgeCommit message (Collapse)AuthorFilesLines
2018-06-15gsm0408_dispatch: Fix uninitialized var warningPau Espin Pedrol1-1/+1
Got this warning since my upgrade to gcc 8.1.0. Quick check tells me it's probably a false positive, but let's fix the warning anyway. openbsc/openbsc/src/libmsc/gsm_04_08.c: In function ‘gsm0408_dispatch’: openbsc/openbsc/src/libmsc/gsm_04_08.c:1260:5: error: ‘res_len’ may be used uninitialized in this function [-Werror=maybe-uninitialized] if (res_len != 4) { ^ openbsc/openbsc/src/libmsc/gsm_04_08.c:1223:10: note: ‘res_len’ was declared here uint8_t res_len; ^~~~~~~ Change-Id: Ifa45f73645c9ab022c18a012abe03214aa21526f
2018-04-17smpp_smsc_conf: Fix heap-use-after-freePau Espin Pedrol1-2/+7
Backport from osmo-msc Change-Id Iaf0d251c8d2912266a087ada4d20905146e08592. Fixes following error catched by enabling address sanitizer: ==20792==ERROR: AddressSanitizer: heap-use-after-free on address 0x60b000122610 at pc 0x7f9c9c3fe063 bp 0x7ffd2e68f600 sp 0x7ffd2e68edb0 READ of size 11 at 0x60b000122610 thread T0 #0 0x7f9c9c3fe062 (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x3c062) #1 0x7f9c9beb8ee4 in talloc_strdup (/usr/lib/x86_64-linux-gnu/libtalloc.so.2+0x6ee4) #2 0x56096a7cf75b in smpp_smsc_conf src/libmsc/smpp_smsc.c:983 #3 0x56096a7cf9df in smpp_smsc_start src/libmsc/smpp_smsc.c:1015 #4 0x56096a7d4935 in smpp_openbsc_start src/libmsc/smpp_openbsc.c:785 #5 0x56096a755ad0 in main src/osmo-msc/msc_main.c:598 #6 0x7f9c9927b2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0) #7 0x56096a756979 in _start (/home/jenkins/workspace/osmo-gsm-tester_run-prod/trial-805/inst/osmo-msc/bin/osmo-msc+0xf0979) Related: OS#3181 Change-Id: Ifce107dc5f0971d7580b7adc09f05e334792bace
2018-03-29Migrate from OpenSSL to osmo_get_rand_id()Neels Hofmeyr3-11/+10
Drop OpenSSL/libcrypto dependency, use osmo_get_rand_id() instead. Backport osmo-msc 753c15de2f00e24f76ac9b01a20e1e2ff0f86ce2 = I71cd631704a4dc155c6c752fee2a42cd6e2fa336 " Migrate from OpenSSL to osmo_get_rand_id() This avoids potential licensing incompatibility and makes integration of Debian packaging patches easier. " Apply similar changes in bsc-nat, mm_auth_test etc. Tested manually with osmo-nitb and sysmoBTS, and verified that Authentication Requests send heterogenous RAND tokens. Related: OS#1694 Change-Id: I81ebd55c7c90a436c5f2090e6790d78b773d2c92
2018-03-22backport support for 3-digit MNC with leading zerosneels/mnc3Neels Hofmeyr1-9/+1
Backport the patches with the following change-ids: osmo-bsc.git: I5b097dbb6329f284e3b4914a744d5c3ad628f715 I8e722103344186fde118b26d8353db95a4581daa I78f30aef7aa224b2e9db54c3a844d8f520b3aee0 I38ac98a4d25159cfd4f686efbfbaf8f00625a6d8 osmo-iuh.git: I29ebcddd45fe3079f8883589a83cc7216a535475 Also apply change of ipac_bcch_info.cgi to struct osmo_cell_global_id in src/ipaccess/network_listen.c, a change that appears to not have been necessary in the new split repositories. Related: OS#3010 Change-Id: Ibf50fd7e1ca5472d0a38fcb87c68227d6de44f42
2018-01-21src/libmsc/ussd.c: drop useless forward declarationVadim Yanitskiy1-13/+10
There is no any significant reason to define static function 'send_own_number' after the code that calls it. Change-Id: I8d804398cfa460eaa5a5f84f0ed90909488d0bdd
2018-01-12libmsc: add support for both comp128v2 and comp128v3Vadim Yanitskiy3-5/+41
This change adds support for both comp128v2 and comp128v3 GSM A3/A8 algorithms. Since they already implemented in libosmocore, the corresponding it's API is used. Change-Id: Ic761be0220397d100c9e6345d4d01af4889dc7c1
2017-12-12sms.db: silence libdbi warnings on out-of-range indexNeels Hofmeyr1-18/+25
Apparently, since libdbi 0.9.0 aka 0.9.0-5 on debian-testing, osmo-msc barfs numerous libdbi warnings whenever a query rightfully returns no rows. Trivially query whether there are any rows first by adding an inline wrap function next_row(). Silenced: DDB <000d> ../../../../src/osmo-msc/src/libmsc/db.c:188 DBI: -6: An invalid or out-of-range index was passed to l DDB <000d> ../../../src/libosmocore/src/backtrace.c:47 backtrace() returned 11 addresses DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/local/bin/osmo-msc(+0xfb81) [0x555555563b81] DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/lib/x86_64-linux-gnu/libdbi.so.1(_error_handle DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/lib/x86_64-linux-gnu/libdbi.so.1(dbi_result_ne DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/local/bin/osmo-msc(+0x11172) [0x555555565172] DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/local/bin/osmo-msc(+0x1e6bc) [0x5555555726bc] DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/local/bin/osmo-msc(+0x1e7f6) [0x5555555727f6] DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/local/bin/osmo-msc(+0x1f1d2) [0x5555555731d2] DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/local/bin/osmo-msc(+0xbb86) [0x55555555fb86] DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0 DDB <000d> ../../../src/libosmocore/src/backtrace.c:57 /usr/local/bin/osmo-msc(+0xbfba) [0x55555555ffba] Related: OS#2737 OS#2667 Change-Id: I43cf4eed22425554826d59857eded5b4cc0d2c52
2017-11-01vty: skip installing cmds now always installed by defaultNeels Hofmeyr2-4/+0
vty_install_default() and install_default() will soon be deprecated. Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b Change-Id: I4951982fc78ae167d8e16a672d7af44d703721a9
2017-09-14libmsc: Log Rx DELIVER-SM RESP before calling gsm411_send_rp_ackKeith1-4/+4
This patch just makes the log match chronologically what is happening. We receive the deliver_sm_resp before we send the RP ACK to the MS. Change-Id: I29270652957f58093be8bf7f2e898b0b4933bd93
2017-09-13libmsc: sms_route_mt_sms() may return uninitialized return valuePablo Neira Ayuso1-20/+21
If smpp_first is set off and there is a local receiver for this sms, then return 0. Without this patch, we return 'rc' which is uninitialized in the scenario that I'm describing above. Change-Id: I0c0bcd919cc3275d491995d17c6a32bb61c6afe1
2017-09-13fix vty tests: vty no longer goes to parent node implicitlyNeels Hofmeyr1-0/+1
Fix four instances of VTY tests working because it used to include implicit 'exit' commands to the parent node. Since libosmocore change-id Id73cba2dd34676bad8a130e9c45e67a272f19588 = commit d64b6aed235f6e4d84a2cb8e84b32c3179260254, we no longer do this implicit-exit in interactive VTY shells. *) the nitb node lacked the default command set (including 'end' and 'exit'), so it was impossible to leave the nitb node. This hit in testSubscriberCreateDelete. Add vty_install_default(NITB_NODE). *) in testPingPongConfiguration, the intention is to enter the /msc 0 node. Drop prior entry of the 'network' node, which looks like an oversight. So far the 'msc 0' caused an implicit 'exit' and thus worked, now fails. *) Two instances following comments "# Check searching for outer node's commands", which look like they are intended to check for this implicit-exit behavior. This is obsolete, drop those parts of the tests. Change-Id: I77931d6a09c42c443c6936000592f22a7fd06cab
2017-09-11libmsc: annotate esme route in the sms object from deliver_to_esme()Pablo Neira Ayuso2-3/+12
Annotate this esme route, so we can use it to return -EINPROGRESS to skip sending premature RP-ACK to the mobile station, in case we're handling sms routes through SMPP. Now that we have this information in place, we use it wherever possible to avoid kludgy checks on sms->receiver. sms_free() already releases references to this object, so we should be fine with this. Fixes: 4e5b90a594f9 ("libmsc: remove 'deferred' parameter in sms_route_mt_sms()") Change-Id: Ib8a8fd9bbb0d3b6aff7931e4bacbea99d000e484
2017-08-18libmsc: Use actual delivery time in delivery reports.Keith2-2/+3
Set the time on the status report to the time the message was delivered, as this may not be the same as the time when we are delivering the report to the originating MS. Change-Id: I9056429d40bf02731f004b7833f1de45a0d1add8
2017-08-18libmsc: Fix wrong handling of user_message_reference parameterPau Espin Pedrol1-2/+2
libsmpp34 already converts received TLV integer values to native endianess in libsmpp34_(un)pack. Converting them again at receive time swaps the 2 bytes of user_message_reference, then using a wrong value. As GSM03.40 spec uses only 1 byte for the id, then only the high byte of the initial value is used and eventually sent back to the ESME. Again, at that time, htons() is not needed because libsmpp34 already handles that part. See OS-#2429 for more details. Change-Id: If748548a4a223e529a1110c89e483b599b406e8b
2017-08-16smpp: Fix compilation warningPau Espin Pedrol1-1/+1
I already stumbled into 2 compilation environments which had Werror enabled for -Wmaybe-uninitialized and the build failed, so let's workaround this warning. | smpp_openbsc.c: In function 'handle_smpp_submit': | smpp_openbsc.c:216:9: error: 'sms_msg_len' may be used uninitialized in this function [-Werror=maybe-uninitialized] | memcpy(sms->user_data, sms_msg, sms_msg_len); | ^ | smpp_openbsc.c:100:15: note: 'sms_msg_len' was declared here | unsigned int sms_msg_len; | ^ | cc1: some warnings being treated as errors Change-Id: I0901ddadb5f72e1585cb1797ac22c8ab95e83146
2017-08-15LIBMSC: Use sms->text, not sms->user_data to construct report bodyKeith1-1/+1
gsm_04_11.c sms_report_alloc() Use the sms->text, not the sms->user_data to construct the report body. This also prevents the potential output of non printable characters to the log and or vty. Change-Id: Id51bc9483ad6f52d6da74135605cfd12434c7c96
2017-08-15LIBMSC: Place correct dst address in status reportKeith1-1/+1
gsm_04_11.c: gsm340_gen_sms_status_report_tpdu() When we construct the status report PDU, use sms->src instead of sms->dst as the destination address This way we tell the MS that the message was delivered to the destination and not to itself. This is relevant for phones that display a textual representation of the delivery report. Change-Id: I2d4f87ac777465de9bfb5a775a789a2691755ee9
2017-08-15libmsc: use SMPP34_DELIVERY_RECEIPT_* in libsmpp34Pablo Neira Ayuso1-7/+1
Use new definitions in libsmpp34 to set the registered_delivery field accordingly, as provided by I5b3afff1b3b77cccd949e0606914c7ac3ba6114c. Moreover, do not set this header field to zero if status reports are off, the deliver_t structure has been already zeroed so this not required. Change-Id: Ie78e17323796120f576b9c0e1bc5ccc32da8ee12
2017-08-13libmsc: use new smpp34 esm_class definitionsPablo Neira Ayuso1-10/+8
Replace magic numbers by esm_class definitions, which have been added to latest libsmpp34 in Change-Id I91afd8b462b8fd3b2c4c5b54f4eeb7ec5b730b65 Change-Id: I6c458690da60c8f3637680efbd718f6e8c6feb4c
2017-08-12libmsc: use smpp34_tlv_for_each() to avoid suboptimal TLV handlingPablo Neira Ayuso1-30/+40
submit_to_sms() now handles two TLVs, so find_tlv() is suboptiomal and it can be removed, since it would result in two passes on the TLV list. Use new smpp34_tlv_for_each() helper to iterate over the list of TLVs that is available since I446929feed049d0411e1629ca263e2bc41f714cc. Change-Id: I53a65164a6cc4abc6bf57d9a8dc275cf21c90222
2017-08-10libmsc: Remove comment not applying anymorePau Espin Pedrol1-1/+0
The change-id I7276d356d805a83ebeec72b02c8563b7135ea0b6 added msg_ref to the databse but forgot to remove the comment stating it's not being stored. Change-Id: I204f098c8f2a480405446113e2181b2c53700cf3
2017-08-10libmsc: gsm340_gen_oa_sub() may return negative valuePablo Neira Ayuso1-2/+9
gsm340_gen_oa() returns a negative value if the output buffer that the caller passes is too small, so we have to check the return value of this function. Fixes: CID 174178 Fixes: CID 174179 Change-Id: I47215d7d89771730a7f84efa8aeeb187a0911fdb
2017-08-09libmsc: support GSM 03.40 status report for nitbPablo Neira Ayuso1-0/+5
This patch adds support for GSM 03.40 in nitb mode. MS GSM 03.40 SMSC | | | SMS-SUBMIT | |--------------------------->| | GSM 04.11 RP-ACK | |<---------------------------| | SMS-DELIVER | |<---------------------------| | GSM 04.11 RP-ACK | |--------------------------->| | SMS-STATUS-REPORT | |<---------------------------| | GSM 04.11 RP-ACK | |--------------------------->| | | Change-Id: I5cc7bb4ebadde0940f44d10c3df34707b0615160
2017-08-09libmsc: handle delivery ack via SMPP SUBMIT SM / send GSM 03.40 status reportPablo Neira Ayuso2-2/+54
This patch adds gsm340_sms_send_status_report_tpdu() to build a status-report. Moreover, set sms->report field if we see a SMPP SUBMIT_SM with Delivery Acknowledgment esm_class, so this identifies that this is a delivery report. MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | | SUBMIT-SM | | | esm_class = Delivery Ack | | |<-------------------------------| | | SUBMIT-SM-RESP | | |------------------------------->| | | | | SMS-STATUS-REPORT | | |<----------------------------| | | GSM 04.11 RP-ACK | | |---------------------------->| | | | | There is a FIXME message in this patch, that I just copied from gsm340_gen_sms_deliver_tpdu() since TP-MMS is not supported by OpenBSC. Change-Id: Ib70e534840308ed315f7add440351e649de3f907
2017-08-09libmsc: update database to accomodate SMS status-report fieldsPablo Neira Ayuso1-6/+162
SMPP DELIVER_SM messages with esm_class = Delivery Receipt need to send this message reference (that the mobile phone allocates) to the ESME. Thus, the ESME propagates it via SUBMIT_SM with esm_class = Delivery Acknoledgment so that the SMSC sends the GSM 03.40 status-report to the origin including this. Given this field is useful for status-reports, we need to store it in the HLR database. Moreover, we need a new field that specifies if the entry represents a SMS status-report, to do the right handling from the gsm411_send_sms() - such new handling comes in a follow up patch entitled "libmsc: handle delivery ack via SMPP SUBMIT SM / send GSM 03.40 status report". This patch includes the migration routines to the new database schema revision 5, it's quite a bit of dbi boilerplate code - copied-pasted and adapted. Change-Id: I7276d356d805a83ebeec72b02c8563b7135ea0b6
2017-08-09libmsc: add support for SMPP delivery receiptsPablo Neira Ayuso3-1/+75
If the mobile phone requests a status report via SMS, send a DELIVER_SM with esm_class = Delivery Receipt to ESME to indicate that the SMS has been already delivered to its destination. MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | SMS-DELIVER | | |<----------------------------| | | GSM 04.11 RP-ACK | | |---------------------------->| | | | DELIVER-SM | | | esm_class = Delivery Receipt | | |------------------------------->| | | DELIVER-SM-RESP | | |<-------------------------------| | | | This patch implements "Appendix B. Delivery Receipt Format" as specified in the SMPP 3.4 specs. This string is conveyed in the SMS message as data, and it is only meaningful to the ESME, for logging purposes. The "submit date" and "done date" are not yet set, and other fields are just sent with dummy values, so they are left to be finished as future work. The new SMPP TLV tag TLVID_user_message_reference is added to the SMPP messages inconditionally now since this information is required by delivery-reports to associate the status-report with the original SMS. Change-Id: Ic1a9023074bfa938099377980b6aff9b262fab2a
2017-08-09libmsc: missing bit shift in status report flag when stored in sms objectPablo Neira Ayuso1-1/+1
So we just store 0 or 1 depending on what the mobile phone requests. Change-Id: Idb7d5594219c0e458ccb561383a59604bc1a4201
2017-08-09libmsc: report status report request flag from SMPP SUBMIT_SMPablo Neira Ayuso1-0/+1
Restore the sms status report request flag from SUBMIT_SM. Change-Id: Iac05252253f8933a3875b4904599b7a225191a4b
2017-08-09libmsc: set registered_delivery field in SMPP 3.4 DELIVER_SM messagesPablo Neira Ayuso1-1/+8
Propagate the status report request field to the SMPP message through the registered_delivery field, so the ESME knows that the mobile phone is asking for explicit delivery acknowledgment is required. See SMPP 3.4 specs section 5.2.17. Change-Id: I59af60fa89cd10ae973c5e122789e3e03e3728ee
2017-08-08libmsc: move gsm340_rx_sms_submit() to sms_route_mt_sms()Pablo Neira Ayuso1-19/+22
Move the sms message-type-identifier (mti) handling away from the routing logic. This patch allows us to reuse the sms_route_mt_sms() function in a follow up patch for sms reports send through SMPP DELIVER_SM with esm_class = Delivery Receipt whose Change-Id is Ic1a9023074bfa938099377980b6aff9b262fab2a. Change-Id: I3f3d30e0762b91e2099243b0be1a4b67cbb5e9c0
2017-08-08libmsc: remove 'deferred' parameter in sms_route_mt_sms()Pablo Neira Ayuso3-30/+24
No need to cache the sms object, just cache what we need into the smpp_cmd structure. This simplifies what that I introduced in 93ffbd0029d1 ("libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP"). Change-Id: Iba5f864f9bb963baff95969e306b1b7cff00c1e3
2017-08-08libmsc: remove duplicate lines in deliver_to_esme()Pablo Neira Ayuso1-2/+0
This code is accidentally doing the same thing twice, remove it. Change-Id: I68087a850399e22951d2407e4d8a09c671a775c9
2017-08-08libmsc: remove dead code in sms_route_mt_sms()Pablo Neira Ayuso1-3/+0
The following branch: if (!rc && !gsms->receiver) rc = GSM411_RP_CAUSE_MO_NUM_UNASSIGNED; at the end of sms_route_mt_sms() always evaluates false. Just a bit before, in such function, we have this: if (!gsms->receiver) { ... #ifdef BUILD_SMPP ... #else ... #endif return rc; } So, if there is no receiver, we just stop running code and return the RP cause via the rc variable. Same applies to the smpp_first check under the BUILD_SMPP ifdef (that I have removed in this snippet to keep this commit message small). Change-Id: Ic3502b5b169bc7a73a67fd6ff53d8b6c0dc045c8
2017-08-08libmsc: do not leak pending SMPP command object on error pathPablo Neira Ayuso1-5/+6
Make sure the SMPP command object is released on errors. Change-Id: I474584425d23fb379a9d71b33e29ac0e24f01e61
2017-08-08gsm_04_11: get rid of unused parameter in sms_route_mt_sms()Pablo Neira Ayuso1-5/+6
This parameter is unused, remove it. Change-Id: I797abce3f91447e8f397c7cf726db7425479fe0e
2017-07-11transaction: reject calls from unidentified subscribersBenoit Bolsee1-0/+7
A valid subscriber is indespensible when allocating a new transaction. Return NULL if no subscriber is supplied. This will cause unidentified subscribers to be rejected. Note: Under normal conditions, the problem does not occour, but it is still possible that a misbehaving MS might trigger the problem by sending a SETUP command before authenticating the subscriber. (unencrypted networks) Change-Id: Ia8739b6e329ab02c0064270d02ad1d6ee245520d
2017-07-10Add VTY commands for experimentation with TS 04.14 commandsHarald Welte1-0/+94
TS 04.14 (TS 44.014) specifies a series of commands specific to conformance testing. Let's add some VTY commands to play (at least initially) with closing and opening voice loops in the MS. Change-Id: I38b1ee9dbf26f5689c38cb83b1b3c5e9eaad7678
2017-07-10Support for TS 04.14 conformance test commandsHarald Welte3-0/+137
Change-Id: Ib27edbfc8ccdedf00589ec715ced7bed435fa94c
2017-07-10libmsc: Fix VTY output for handover counters.Alexander Chemeris1-5/+5
Handover countrs belong to BSC, but we mistakenly take values from MSC counters. Change-Id: I9512330f2e91d2f526751c5228e6e8e0fe17d579
2017-07-1004.08: find a portable way to obtain the timezone offsetBenoit Bolsee1-3/+10
Portable GMT offset calculation to display correct time on GSM. Change-Id: I673f17af2550c9708c4771e4ea4eafbbfafbb824
2017-07-08smpp: fix return causeBenoit Bolsee4-12/+17
Return cause 38 when default SMPP route is unavailable. This is better than cause 1. Change-Id: If3241d50a78fa611981e55fef6ae4c72b0a2a167
2017-07-06smpp_smsc.c: Log on sending deliver_sm messagePau Espin Pedrol1-0/+3
Change-Id: Ie16294df6d5bc0065f8d2b49320ead61f535f271
2017-05-20libmsc: Map SMPP command status to GSM 04.11 causeKeith3-7/+41
Send SMS RP ERROR with a failure cause that relates to the status returned by the ESME in the deliver_sm_resp. Actual mapping array is limited as most phones I tested don't seem to care about the failure cause anyway, although some will display a different notification for GSM411_RP_CAUSE_MO_NUM_UNASSIGNED Change-Id: I61fb2d9ef4f2d2eabdc49b53d9966ad328d15e51
2017-05-12fix subscriber random extension allocation rangeNeels Hofmeyr1-4/+4
The VTY config allows above 32bit range extensions, but db_subscriber_alloc_exten() was unable to generate extensions outside of 32bit. Add VTY regression test and fix the problem by using proper 64bit types. Related: OS#2253 Change-Id: I9afe6a8833004ecd2f3f936b2d5aa4de8e7dbcb0
2017-05-12fix VTY parsing: subscriber-create-on-demand randomNeels Hofmeyr1-1/+1
Fix parsing of the 'subscriber-create-on-demand random' VTY: atoi() is not enough to include the specified range of 1-9999999999. Use atoll() instead to ensure a large enough number space also on 32bit systems. (Note: for me, atoll() truncates at 32 bit when <stdlib.h> is not included.) Add a VTY regression test for this. Related: OS#2253 Change-Id: I353e04481ec567adca383d6b51ba8fb865eed73e
2017-05-10src: use osmo_timer_setup()Pablo Neira Ayuso3-12/+7
Use new function available in libosmocore to set up timers. Compile tested only. Change-Id: Ibcfd915688e97d370a888888a83a7c95cbe16819
2017-05-08libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESPPablo Neira Ayuso4-17/+174
Hold on with the GSM 04.11 RP-ACK/RP-ERROR that we send to the MS until we get a confirmation from the ESME, via SMPP DELIVER-SM-RESP, that we can route this sms somewhere we can reach indeed. After this change, the conversation looks like this: MS GSM 03.40 SMSC SMPP 3.4 ESME | | | | SMS-SUBMIT | | |------------------->| | | | DELIVER-SM | | |---------------->| | | | | | DELIVER-SM-RESP | | |<----------------| | GSM 04.11 RP-ACK | | |<-------------------| | | | | Before this patch, the RP-ACK was sent back straight forward to the MS, no matter if the sms can be route by the ESME or not. Thus, the user ends up getting a misleading "message delivered" in their phone screen, when the message may just be unroutable by the ESME hence silently dropped. If we get no reply from the ESME, there is a hardcoded timer that will expire to send back an RP-ERROR to the MS indicating that network is out-of-order. Currently this timer is arbitrarily set to 5 seconds. I found no specific good default value on the SMPP 3.4 specs, section 7.2, where the response_timer is described. There must be a place that describes a better default value for this. We could also expose this timer through VTY for configurability reasons, to be done later. Given all this needs to happen asyncronously, ie. block the SMSC, this patch extends the gsm_sms structure with two new fields to annotate useful information to send the RP-ACK/RP-ERROR back to the MS of origin. These new fields are: * the GSM 04.07 transaction id, to look up for the gsm_trans object. * the GSM 04.11 message reference so the MS of origin can correlate this response to its original request. Tested here using python-libsmpp script that replies with DELIVER_SM_RESP and status code 0x0b (Invalid Destination). I can see here on my motorola C155 that message cannot be delivered. I have tested with the success status code in the SMPP DELIVER_SM_RESP too. Change-Id: I0d5bd5693fed6d4f4bd2951711c7888712507bfd
2017-05-08libmsc: use GSM411_RP_CAUSE_MO_NUM_UNASSIGNED as return valuePablo Neira Ayuso2-6/+5
Instead of hardcoded value of 1 plus comment of the right hand side of the statement. Change-Id: I865bdbd6da17a0389044a8e749deeeebcb9cae06
2017-05-04ctrl: remove boilerplate codeMax1-12/+1
Define subscriber-list-active-v1 ctrl command as RO and remove unnecessary functions. Change-Id: I88fe905c22cf7563415d470b88cb43fca0d52a7f
2017-04-26Fix MS TO measurement representationMax1-2/+2
* set proper flag when saving MS Timing Offset * use gsm_subscriber's IMSI or lchan's name if bsc_subscriber is unknown * add comments with spec reference * store/display MS Timing Offset instead of raw Timing Offset field from RSL * Compute MS Timing Offset [-63; 192] from Timing Offset field [0; 255], adjust structure gsm_meas_rep with proper type to store it Change-Id: I7e003d23a6edb714c5f17688fd6a8edac131161d Related: OS#1574