aboutsummaryrefslogtreecommitdiffstats
path: root/src/libmsc/gsm_04_11.c
AgeCommit message (Collapse)AuthorFilesLines
2022-05-19sms: Introduce VTY-configurable minimum SMS validity periodHarald Welte1-0/+6
This is meant as a safeguard against users or user equipment which doesn't set a reasonable validity period. Using this setting, the SMSC administrator can set a minimum SMS validity period. Any SMS submitted with lower validity period will be extended to that minimum. Change-Id: I192528a6f9059d158fa12876a247d61bd7edaec8 Related: OS#5567
2021-11-29libmsc: fix another memleak (struct gsm_sms) in gsm340_rx_tpdu()Vadim Yanitskiy1-1/+1
Change-Id: I42e819fb83096c1432df16f501b9d1f6a6160ae7 Fixes: I2c50904349dd4ed229b60b8468d776b817c0bd44
2021-11-29libmsc: fix memory leak (struct gsm_sms) in gsm340_rx_tpdu()Vadim Yanitskiy1-1/+2
If a MO SMS gets successfully routed through SMPP, we return early in gsm340_rx_tpdu() and leak a chunk of type 'struct gsm_sms'. Change-Id: I8a745d747f06baa7109418ffe600b27b3c0a5228 Fixes: [1] Ic34d398e0a850856e20380ae35e5c2ae5e3c539b Fixes: OS#5334
2021-06-04Use new osmo stat items/ctr APIsPau Espin Pedrol1-10/+10
Generated using several semantinc patches with spatch. Change-Id: I3ee853539949a763a309856bf2e7196415b23741
2020-09-22Don't Store an SMS in the database when the ESME is not BoundKeith Whyte1-0/+10
We may never be able to deliver this SMS if it depends on the ESME, as we will not resubmit the SMS to the ESME. Better to reject it at this time and have the MS try again later. Change-Id: I2c50904349dd4ed229b60b8468d776b817c0bd44 Related: OS#4740
2020-01-15libmsc: SMS, Avoid premature RP-ACK to MSPablo Neira Ayuso1-2/+8
There was one libmsc commit to openbsc that was thus far missing in osmo-msc. This commit completes the work on delayed response from an ESME. Without this patch, the SMR sends an RP-ACK to the mobile station, and subsequently a DELIVER_SM_REPONSE from the ESME provokes either a second RP-ACK, or an RP-ERROR; both of which result in "unhandled at this state (IDLE)" from the SMR After this patch, we have two things corrected: 1) RP-ERROR respects Deliver-SM error cause. 2) No more "unhandled as this state" error from the SMR Extract from original commit message: -------- libmsc: annotate esme route in the sms object from deliver_to_esme() 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. -------- Fixes: #OS4351 Change-Id: Ic34d398e0a850856e20380ae35e5c2ae5e3c539b
2020-01-13Trivial: code simplification, return earlyKeith Whyte1-19/+19
This commit also, (for what it is worth) removes a difference to the same file in openbsc, which I found while looking for changes that affected SMPP delivery. This is essentially a "forward-port" of [1] [1] https://gerrit.osmocom.org/#/c/openbsc/+/3899/ Change-Id: I350c19f5bb70b2656171c096334c2ee83f49df7e
2019-06-20libmsc/gsm_04_11.c: do not abuse LOG_TRANS() in gsm411_alloc_mt_trans()Vadim Yanitskiy1-2/+2
This change is similar to I6b68a0f0b32eb126e0f7e914a314130254d28467. If we 100% sure that trans == NULL, it makes more sense to use generic LOGP(DLSMS, LOGL_*, ...) call, so the logs can reflect more information than such dummy prefix: trans(NULL NULL callref-0x0 tid-0) ... Change-Id: I3c1e633aee5dd7cd0d367404a3def9cffe0b3baa
2019-05-19libmsc/gsm_04_11.c: properly handle MMTS indicationVadim Yanitskiy1-1/+33
According to 3GPP TS 29.002, section 7.6.8.7, MMS (More Messages to Send) is an optional IE of MT-ForwardSM-Req message which is used by SMSC to indicate that there are more (multi-part) MT SMS messages to be sent. The MSC needs to use this indication in order to decide whether to keep the RAN connection with a given subscriber open. Related Change-Id: (TTCN) I6308586a70c4fb3254c519330a61a9667372149f Change-Id: Ic46b04913b2e8cc5d11a39426dcc1bfe11f1d31e Related: OS#3587
2019-05-13libmsc/gsm_04_11.c: fix NULL-pointer dereference in gsm340_rx_tpdu()Vadim Yanitskiy1-5/+16
Change-Id: I1e9b351e949efe596295d18f98c8a73c8e013763 Fixes: CID#198451
2019-05-12libmsc/gsm_04_11.c: cosmetic: restructure gsm411_mm_send()Vadim Yanitskiy1-4/+2
Change-Id: I22e99f40ab2252a0b716969091e4d24b3b4268a2
2019-05-12libmsc/gsm_04_11.c: fix double init of both SMR and SMC FSMsVadim Yanitskiy1-4/+0
Change-Id: I23700a2c575a96057ef22bc5d8ab6271104d619b
2019-05-10libmsc/gsm_04_11.c: properly handle TP-User-Data-LengthVadim Yanitskiy1-12/+29
As per 3GPP TS 03.40, section 9.2.3.16 "TP-User-Data-Length (TP-UDL)", if the TP-User-Data is coded using the GSM 7-bit default alphabet, the TP-User-Data-Length field indicates the *number of septets* within the TP-User-Data field to follow. Otherwise, i.e. in case of 8-bit or UCS-2 encoded data, the *number of octets* is indicated. Since we store the original TP-UDL value (as received), we might need to convert septets to octets before passing it to memcpy(). Otherwise this would lead to a buffer overrun. Also, as we receive TPDU from untrusted source (i.e. subscriber), the TP-UDL value needs to be checked against the corresponding maximum (160 septets or 140 octets) and truncated if needed. Please note that buffer overrun is still possible, e.g. when an indicated TP-UDL value is grather than the remaining TPDU length. Preventing this would require adding an additional check. Change-Id: I4b08db7665e854a045129e7695e2bdf296df1688 Depends-on: (core) I54f88d2908ac47228813fb8c049f4264e5145241
2019-05-08rename bscconfig.h to config.h, cleanupNeels Hofmeyr1-1/+1
Get rid of the legacy name bscconfig.h from osmo-nitb times. Remove the #include from some of the files that aren't actually using it. Instead of '#include "../../config.h"', use plain '#include "config.h"' because we're anyway passing $top_srcdir as -I during compilation. Change-Id: Id4f683be1f36f0630c83da54e02868aae847aeec
2019-05-08large refactoring: support inter-BSC and inter-MSC HandoverNeels Hofmeyr1-90/+78
3GPP TS 49.008 '4.3 Roles of MSC-A, MSC-I and MSC-T' defines distinct roles: - MSC-A is responsible for managing subscribers, - MSC-I is the gateway to the RAN. - MSC-T is a second transitory gateway to another RAN during Handover. After inter-MSC Handover, the MSC-I is handled by a remote MSC instance, while the original MSC-A retains the responsibility of subscriber management. MSC-T exists in this patch but is not yet used, since Handover is only prepared for, not yet implemented. Facilitate Inter-MSC and inter-BSC Handover by the same internal split of MSC roles. Compared to inter-MSC Handover, mere inter-BSC has the obvious simplifications: - all of MSC-A, MSC-I and MSC-T roles will be served by the same osmo-msc instance, - messages between MSC-A and MSC-{I,T} don't need to be routed via E-interface (GSUP), - no call routing between MSC-A and -I via MNCC necessary. This is the largest code bomb I have submitted, ever. Out of principle, I apologize to everyone trying to read this as a whole. Unfortunately, I see no sense in trying to split this patch into smaller bits. It would be a huge amount of work to introduce these changes in separate chunks, especially if each should in turn be useful and pass all test suites. So, unfortunately, we are stuck with this code bomb. The following are some details and rationale for this rather huge refactoring: * separate MSC subscriber management from ran_conn struct ran_conn is reduced from the pivotal subscriber management entity it has been so far to a mere storage for an SCCP connection ID and an MSC subscriber reference. The new pivotal subscriber management entity is struct msc_a -- struct msub lists the msc_a, msc_i, msc_t roles, the vast majority of code paths however use msc_a, since MSC-A is where all the interesting stuff happens. Before handover, msc_i is an FSM implementation that encodes to the local ran_conn. After inter-MSC Handover, msc_i is a compatible but different FSM implementation that instead forwards via/from GSUP. Same goes for the msc_a struct: if osmo-msc is the MSC-I "RAN proxy" for a remote MSC-A role, the msc_a->fi is an FSM implementation that merely forwards via/from GSUP. * New SCCP implementation for RAN access To be able to forward BSSAP and RANAP messages via the GSUP interface, the individual message layers need to be cleanly separated. The IuCS implementation used until now (iu_client from libosmo-ranap) did not provide this level of separation, and needed a complete rewrite. It was trivial to implement this in such a way that both BSSAP and RANAP can be handled by the same SCCP code, hence the new SCCP-RAN layer also replaces BSSAP handling. sccp_ran.h: struct sccp_ran_inst provides an abstract handler for incoming RAN connections. A set of callback functions provides implementation specific details. * RAN Abstraction (BSSAP vs. RANAP) The common SCCP implementation did set the theme for the remaining refactoring: make all other MSC code paths entirely RAN-implementation-agnostic. ran_infra.c provides data structures that list RAN implementation specifics, from logging to RAN de-/encoding to SCCP callbacks and timers. A ran_infra pointer hence allows complete abstraction of RAN implementations: - managing connected RAN peers (BSC, RNC) in ran_peer.c, - classifying and de-/encoding RAN PDUs, - recording connected LACs and cell IDs and sending out Paging requests to matching RAN peers. * RAN RESET now also for RANAP ran_peer.c absorbs the reset_fsm from a_reset.c; in consequence, RANAP also supports proper RESET semantics now. Hence osmo-hnbgw now also needs to provide proper RESET handling, which it so far duly ignores. (TODO) * RAN de-/encoding abstraction The RAN abstraction mentioned above serves not only to separate RANAP and BSSAP implementations transparently, but also to be able to optionally handle RAN on distinct levels. Before Handover, all RAN messages are handled by the MSC-A role. However, after an inter-MSC Handover, a standalone MSC-I will need to decode RAN PDUs, at least in order to manage Assignment of RTP streams between BSS/RNC and MNCC call forwarding. ran_msg.h provides a common API with abstraction for: - receiving events from RAN, i.e. passing RAN decode from the BSC/RNC and MS/UE: struct ran_dec_msg represents RAN messages decoded from either BSSMAP or RANAP; - sending RAN events: ran_enc_msg is the counterpart to compose RAN messages that should be encoded to either BSSMAP or RANAP and passed down to the BSC/RNC and MS/UE. The RAN-specific implementations are completely contained by ran_msg_a.c and ran_msg_iu.c. In particular, Assignment and Ciphering have so far been distinct code paths for BSSAP and RANAP, with switch(via_ran){...} statements all over the place. Using RAN_DEC_* and RAN_ENC_* abstractions, these are now completely unified. Note that SGs does not qualify for RAN abstraction: the SGs interface always remains with the MSC-A role, and SGs messages follow quite distinct semantics from the fairly similar GERAN and UTRAN. * MGW and RTP stream management So far, managing MGW endpoints via MGCP was tightly glued in-between GSM-04.08-CC on the one and MNCC on the other side. Prepare for switching RTP streams between different RAN peers by moving to object-oriented implementations: implement struct call_leg and struct rtp_stream with distinct FSMs each. For MGW communication, use the osmo_mgcpc_ep API that has originated from osmo-bsc and recently moved to libosmo-mgcp-client for this purpose. Instead of implementing a sequence of events with code duplication for the RAN and CN sides, the idea is to manage each RTP stream separately by firing and receiving events as soon as codecs and RTP ports are negotiated, and letting the individual FSMs take care of the MGW management "asynchronously". The caller provides event IDs and an FSM instance that should be notified of RTP stream setup progress. Hence it becomes possible to reconnect RTP streams from one GSM-04.08-CC to another (inter-BSC Handover) or between CC and MNCC RTP peers (inter-MSC Handover) without duplicating the MGCP code for each transition. The number of FSM implementations used for MGCP handling may seem a bit of an overkill. But in fact, the number of perspectives on RTP forwarding are far from trivial: - an MGW endpoint is an entity with N connections, and MGCP "sessions" for configuring them by talking to the MGW; - an RTP stream is a remote peer connected to one of the endpoint's connections, which is asynchronously notified of codec and RTP port choices; - a call leg is the higher level view on either an MT or MO side of a voice call, a combination of two RTP streams to forward between two remote peers. BSC MGW PBX CI CI [MGW-endpoint] [--rtp_stream--] [--rtp_stream--] [----------------call_leg----------------] * Use counts Introduce using the new osmo_use_count API added to libosmocore for this purpose. Each use token has a distinct name in the logging, which can be a globally constant name or ad-hoc, like the local __func__ string constant. Use in the new struct msc_a, as well as change vlr_subscr to the new osmo_use_count API. * FSM Timeouts Introduce using the new osmo_tdef API, which provides a common VTY implementation for all timer numbers, and FSM state transitions with the correct timeout. Originated in osmo-bsc, recently moved to libosmocore. Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore) Ib9af67b100c4583342a2103669732dab2e577b04 (libosmocore) Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore) Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5 (libosmo-sccp) I26be5c4b06a680f25f19797407ab56a5a4880ddc (osmo-mgw) Ida0e59f9a1f2dd18efea0a51680a67b69f141efa (osmo-mgw) I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw) Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd
2019-05-08gsm_04_11: use gsm48_decode_bcd_number2(), evaluate rcNeels Hofmeyr1-2/+6
Avoid deprecation warning: use gsm48_decode_bcd_number2() instead of gsm48_decode_bcd_number(). Validate the return value and add error handling. Change-Id: Ibef71c46d72d2d43123e68f73e5ed554a69243d8
2019-05-06fix various missing line endings in loggingNeels Hofmeyr1-2/+2
Change-Id: I013eb0eeb5673c06034465020e5dc5230f45ddf5
2019-04-25libmsc/gsm_04_11.c: clarify implicit CP-ACK handlingVadim Yanitskiy1-4/+6
Change-Id: I3c5327a5019590c65d0ccb33a52f07b3988ea952
2019-04-12add LOG_TRANS, proper context for all transactionsNeels Hofmeyr1-93/+85
Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-04-12vlr_subscr: use osmo_use_countNeels Hofmeyr1-4/+4
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore) Change-Id: Ib06d030e8464abe415ff597d462ed40eeddef475
2019-02-15transaction: drop meaningless ti_flag of trans_assign_trans_id()Max1-1/+1
According to GSM 04.07, the TI flag takes one bit and can be either of the following: '0'B - transaction is allocated by sender of a message, '1'B - transaction is allocated by receiver of a message. Since we store transaction ID in gsm_trans structure, we also store TI flag (as a part of transaction ID), which in this context means: '0'B - transaction is allocated by us (OsmoMSC), '1'B - transaction is allocated by some MS. In 100% cases, trans_assign_trans_id() is used to assign transaction IDs to transactions allocated by us (i.e. OsmoMSC) for MT connections. And there is no need to use it for MO transactions, because they basically already do contain a valid transaction ID assigned by the MS. Change-Id: Ie11999900b1789652ee078d34636dcda1e137eb0
2019-02-04Add SGs InterfaceHarald Welte1-1/+3
Add an SGs interface (3GPP TS 29.118) to osmo-msc in order to support SMS tunneling and Circuit Switched Fallback (CSFB) Change-Id: I73359925fc1ca72b33a1466e6ac41307f2f0b11d Related: OS#3615
2019-02-01libmsc/gsm_04_11.c: introduce and use gsm411_assign_sm_rp_mr()Vadim Yanitskiy1-3/+29
Initially, it was assumed that if there is no active RAN connection, we can just start counting from 0x00, as there are no other SMS related transactions, and transaction itself is allocated using talloc_zero(). Until now it was looking good, but... As soon as we establish RAN connection with subscriber, we already have a transaction with SM-RP-MR 0x00, but conn->next_rp_ref also remains 0x00 - it isn't being increased! It means that we can face a SM-RP-MR conflict (or collision) if another MT SMS would arrive to the MSC (from SMSC over GSUP) when this transaction is still active, i.e. the first SMS is still being sent, because conn->next_rp_ref++ would return 0x00 again. Moreover, there might be already a MO SMS transaction, and using the conn->next_rp_ref counter wouldn't prevent us from having duplicate SM-RP-MR value. Let's get rid of this per-connection counter, and introduce a function instead, that would iterate over existing transactions and look for an unused SM-RP-MR value. This change makes the following test cases pass: - TC_gsup_mt_sms_rp_mr, - TC_gsup_mo_mt_sms_rp_mr. Discovered by: Neels Hofmeyr Related Change-Id: (TTCN) I3a52d44f4abde9b6b471b9108c1cee905884c9bc Related Change-Id: (TTCN) I17cbbaa64d9bce770f985588e93cd3eecd732120 Change-Id: Ife6d954c46b7d8348a4221ab677d0355eb3ee7ac
2019-02-01libmsc/gsm_04_11.c: also assign SM-RP-MR to MO transactionsVadim Yanitskiy1-0/+2
Previously, SM-RP Message Reference was assigned to MT transactions only, but not to MO transactions. As a result, this could lead to having a few transactions with duplicate SM-RP-MR value, because in case of MO SMS, trans->sms.sm_rp_mr would remain 0x00. Let's parse SM-RP-MR from MO SMS messages in gsm0411_rcv_sms(), and assign it to the new transaction after allocation. Change-Id: I4d07354175444f9764fb0dd6ea188a64494d79fe
2019-01-17SMS: remove code duplication in transaction initMax1-24/+27
Move code which allocates transaction for SMS and initializes corresponding FSM into separate function (shared by MT and MO code paths) to avoid code duplication and simplify further modifications. Change-Id: I3563e11bebb58e656592df2ff7db96f41deaf735
2019-01-16Enable SMS-related log in VLR testsMax1-2/+1
The likely reason why it was disabled is due to paging_cb_mmsms_est_req() logging pointers which results in unstable log output. Fixing this allows us to track SMS-related regressions properly. Change-Id: I44ae817d9edb73d182ff33ff5a2fd942e224e344
2019-01-11libmsc/gsm_04_11.c: accept MT SMS messages over GSUPVadim Yanitskiy1-4/+53
Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2018-12-30libmsc/gsm_04_11.c: forward MO SMS messages over GSUPVadim Yanitskiy1-2/+21
Change-Id: I7d651fde3d608d02f275a74043dc42262aabb1b8 Depends-on: (core) Ic37f3b2114b8095cfce22977e67133b9103942e3 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I7abc95b8e416f7308d54e11be11c08586d18e6c5 Related Change-Id: (TTCN) Id14bbd8bd51558cdacefea0fe042769cd69ed5c8 Related: OS#3587
2018-11-30combine several small .h in msc_common.hNeels Hofmeyr1-1/+0
For hysterical raisins, there are some header files that contain few declarations, and where the name doesn't reflect the content. Combine them to new msc_common.h: - common.h - common_cs.h - osmo_msc.h Change-Id: I9e3a587342f8d398fb27354a2f2475f8797cdb28
2018-11-30rename some RAN conn related stuff to ran_conn_*Neels Hofmeyr1-3/+3
Following previous rename of gsm_subscriber_connection: Some functions and #defines are still called like "msc_conn" or just "msc_", while they are clearly about a RAN conn. To avoid confusion with the future separate concepts of MSC roles and a RAN connection, rename all those to match the common "ran_conn" prefix. Change-Id: Ia17a0a35f11911e00e19cafb5d7828d729a69640
2018-11-30rename gsm_subscriber_connection to ran_connNeels Hofmeyr1-12/+12
In preparation for inter-BSC and inter-MSC handover, we need to separate the subscriber management logic from the actual RAN connections. What better time to finally rename gsm_subscriber_connection. * Name choice: In 2G, this is a connection to the BSS, but even though 3GPP TS commonly talk of "BSS-A" and "BSS-B" when explaining handover, it's not good to call it "bss_conn": in 3G a BSS is called RNS, IIUC. The overall term for 2G (GERAN) and 3G (UTRAN) is RAN: Radio Access Network. * Rationale: A subscriber in the MSC so far has only one RAN connection, but e.g. for inter-BSC handover, a second one needs to be created to handover to. Most of the items in the former gsm_subscriber_connection are actually related to the RAN, with only a few MM and RTP related items. So, as a first step, just rename it to ran_conn, to cosmetically prepare for moving the not strictly RAN related items away later. Also: - Rename some functions from msc_subscr_conn_* to ran_conn_* - Rename "Subscr_Conn" FSM instance name to "RAN_conn" - Rename SUBSCR_CONN_* to RAN_CONN_* Change-Id: Ic595f7a558d3553c067f77dc67543ab59659707a
2018-11-30libmsc/gsm_04_11.c: fix: always use SAPI 3 for MT SMSVadim Yanitskiy1-2/+3
In I4a07ece80d8dd40b23da6bb1ffc9d3d745b54092 I've introduced a regression. According to GSM TS 04.11, section 2.3, SAPI 3 shall be used for both MO/MT SMS transmissions. Due to a mistake, caused by misunderstanding of the meaning of trans->dlci, SAPI 3 was not assigned to SM transactions if there is already an active RAN connection with subscriber. Let's fix this. Let's also drop this misleading comment: /* FIXME: specify SACCH in case we already have active TCH */ because it's a task of the BSC/BTS to decide which lchan to use. Change-Id: I08d0801a89d377441e95fb8e3dd27c8d587f89e9 Related: OS#3716
2018-11-29libmsc/gsm_04_11.c: refactor MT SMS message handlingVadim Yanitskiy1-155/+196
According to GSM TS 04.11, the SMC (Short Message Control) state machine is a part of CM-sublayer of L3, that is responsible for connection management (establisment and releasing), and SM-RP (Relay Protocol) message delivery. For some reason, the connection establisment request from SMC (GSM411_MMSMS_EST_REQ) was not handled properly - it was always assumed that connection is already established. This is why the code initiating a MT (Mobile Terminated) SMS transfer had to establish a radio connection with subscriber manually. Let's benefit from having the SMC state machine, and offload connection establishment to it. This change makes the local implementation closer to GSM TS 04.11, and facilitates the further integration of GSUP transport. NOTE: the expected unit test output is changed, because now we always allocate a transaction first, and then establish a connection, not vice versa. Change-Id: I4a07ece80d8dd40b23da6bb1ffc9d3d745b54092
2018-11-25libmsc/gsm_04_11.c: refactor RP-DATA header validationVadim Yanitskiy1-20/+18
It's much better to have both RP-DATA header parsing and validation code in a single function. There is no need to pass all the header fields (DA, OA, UI) to gsm411_rx_rp_ud() because they are not used there. Change-Id: Iaf295949148e2a613c5403d1f7a926fcd6849c15
2018-11-25libmsc/gsm_04_11.c: don't pass msgb to gsm411_rx_rp_{ack|error}Vadim Yanitskiy1-4/+4
Passing a message buffer containing the whole encoded message, and a pointer to the RP header (struct gsm411_rp_hdr) is redundant. Change-Id: I0eb5c7c485ab7d109966431bd875fa74e00936d7
2018-11-19libmsc: Don't send SMS STATUS REPORT locally if the ESME accepted it.Keith Whyte1-1/+1
When using smpp-first, after the ESME accepts our STATUS REPORT, we were sending it locally into gsm340_rx_sms_submit() anyway. In the case of the ESME mirroring the report back to us, this would result in two copies of the status report in the SMS database, which were also both then delivered to the MS. This causes no visible error to the user but is a waste of radio resources. With this patch, we check if it is the sms_report that has had receiver set in sms_route_mt_sms() and not the original SMS we are reporting on, which of course already has receiver set. Change-Id: I3529b89535800eaa1127721d613fa7bbcb8b23be
2018-04-24Remove unused GSM_PAGING_OOMPau Espin Pedrol1-1/+0
Change-Id: Ie5883953f48d11ec498f47c30ab4201bb956368c
2018-04-09Permit any Sender MSISDN when sending SMS from VTYHarald Welte1-2/+2
In the old days, OsmoNITB couldn't process any SMS that wasn't between two subscribers on the same NITB. We've long re-worked the internals in order to process SMS with arbitrary sender MSISDN (e.g. from SMPP). However, the VTY command "subscriber ... sms" was never updated, it seems. Change-Id: I62b17e0a67989484415f0df2c8cb4ff1f94dbf2b Closes: OS#3151
2018-04-09DTAP: Ensure proper DLCI is used in MSC-originated DTAPHarald Welte1-0/+4
The DLCI field of the DTAP header indicates the SAPI as well as the data link (main DCCH or SACCH). We must make sure to use the correct DLCI when sending DTAP to the BSC. We achieve this by * storing the DLCI in the msgb->cb while parsing the DTAP header * storing the received DLCI (from msgb->cb) in the transaction for mobile-originated transactions * using the trans->dlci to sent msgb->cb when transmitting L3 * filling the DTAP DLCI value from msgb->cb when transmitting DTAP For MSC-originated transactions, we choose a DLCI value corresponding to the service (SAPI=0 for CC, SAPI=3 for SMS) and store that in trans->dlci. Closes: OS#3150 Change-Id: If511b20f52575054cab1346d99a8cb68d827fdbf
2018-03-22dissolve libcommon-cs: move gsm48_* code to libmsc, drop sms_next_rp_msg_ref()Neels Hofmeyr1-1/+1
Move gsm48_* functions from common_cs.c to libmsc/gsm_04_08.c. Drop sms_next_rp_msg_ref(), it is just a bunch of bloat around "next_rp_ref++". Apply the "++" instead, in gsm_04_11.c. libcommon-cs is now empty, to be removed in subsequent commit. Change-Id: Ibc410803ce8e273b626124ab9fc934f04df3ae50
2018-02-09cosmetic: Use msgb_hexdump*() rather than manual osmo_hexdump() on msgHarald Welte1-1/+1
This requires libosmocore Change-Id I98e85397fb541ee0fd711f2e1852f63f3bb87359 Change-Id: Ieeb97a9f1eba2fdef84294b8c8c7ac0984ae5c70
2018-02-05Wrap osmo_strlcpy() callsMax1-4/+4
Using following semantic patch: @@ expression A, B, C; @@ - osmo_strlcpy(A, B, sizeof(A)); + OSMO_STRLCPY_ARRAY(A, B); Which was applied using following command: spatch --dir src -I src --sp-file strlcpy.spatch --in-place --recursive-includes All the calls to osmo_strlcpy() which use destination buffer obtained via sizeof() were replaced with the corresponding wrapper macro. Change-Id: I67b482dedfa11237ac21894fc5930039e12434ab Related: OS#2864
2018-01-25Accept SMS for any receiverStefan Sperling1-3/+4
Accept any SMS and store it in the database, even if the receiver of the message cannot be determined when the message arrives at the MSC. This fixes https://osmocom.org/issues/2354 ("SMSC: Store&Forward not working for subscribed but unregistered MS"). Change-Id: I833c3abd290d2bc5fceec7457e3933c9600e6c24 Depends: Icd6093b7b5d8db84b19a0aa47c68182566113ee2 Depends: I56cbe716e52b679c4b94f6cbb4a171306975be2e Depends: Icf786f9b1efabfe7407fb6414ec0d326d8f7244a Related: OS#2354
2018-01-25remove dead header files bsc_msc.h, bsc_msc_data.h and bsc_rll.hHarald Welte1-1/+0
Related: OS#2528 Change-Id: I13cc4513689af1d594952dd628738b1240560bb7
2018-01-25Massive removal of unused code/structs/headersHarald Welte1-4/+2
osmo-msc still had large amounts of dead code that came along from openbsc.git. This commit removes a lot of it, mostly stuff relevant only to the BSC side of things (or even GPRS). Change-Id: I247def85da2dc3ec461389fb74414a0d964e7e3c Related: OS#2528
2018-01-24remove unused paging.h and osmo_bsc_grace.hHarald Welte1-1/+0
Change-Id: I6af40f65f0634e49939906a3e50a41e0be246794
2017-11-27subscr_conn: introduce usage tokens for ref error trackingNeels Hofmeyr1-2/+2
When hunting a conn use count bug, it was very hard to figure out who's (not) using the conn. To ease tracking down this bug and future bugs, explicitly name what a conn is being reserved for, and track in a bit mask. Show in the DREF logs what uses and un-uses a conn. See the test expectation updates, which nicely show how that clarifies the state of the conn in the logs. On errors, log them, but don't fail hard: if one conn use/un-use fails, we don't want to crash the entire MSC before we have to. Change-Id: I259aa0eec41efebb4c8221275219433eafaa549b
2017-11-14sms_route_mt_sms: Don't return uninitialized variableHarald Welte1-1/+2
Wen there's no SMPP support compiled in, and routing was successful, we shouldn't return an uninitialized value. Change-Id: I4abbbb5ab336a7e8da08d682f396baec3b56fa3a Fixes: Coverity CID#174176
2017-09-06rename include/openbsc to include/osmocom/mscNeels Hofmeyr1-15/+15
Change-Id: I1f96a1285bbd1b4607614856bca935d5c26e2da9
2017-08-29add msg type to SMS rx loggingNeels Hofmeyr1-1/+3
Change-Id: I73ea4eebe57b2d1008045a27f174072178b9f077
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-06 19:20:52 +0000