Commit Graph

6887 Commits

Author SHA1 Message Date
Neels Hofmeyr 911e5979ed make msc_a_vsub() and others NULL-safe
Fixes: coverity CID 198451
Change-Id: Icd146ae512236a09cad080ed3eb85944e8f5cee4
2019-05-10 07:04:50 +00:00
Neels Hofmeyr 4deb8c9ea0 ran_a_make_handover_request(): allow no encryption
Fixes: coverity CID 198454
Change-Id: Ifb83ab2a8b6148b457224687ffada2dff4c3204f
2019-05-10 07:04:50 +00:00
Vadim Yanitskiy 4eca09fdb1 libmsc/gsm_04_11.c: properly handle TP-User-Data-Length
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-10 03:22:32 +07:00
Vadim Yanitskiy 53d3e0e54a libmsc/ran_peer.c: fix msgb memleak in ran_peer_rx_reset()
It was noticed that SCCP_RAN_MSG_RESET_ACK message is not freed after
sending. Since ran_peer_rx_reset() calls sccp_ran_down_l2_cl(), which
then calls osmo_sccp_user_sap_down_nofree(), which doesn't free the
message buffer (what's clear from its name).

  OsmoMSC# show talloc-context application full filter msgb
  full talloc report on 'osmo_msc' (total  20155 bytes in  88 blocks)
    msgb                  contains   4640 bytes in   5 blocks (ref 0)
      bssmap: reset ack   contains   1160 bytes in   1 blocks (ref 0)
      bssmap: reset ack   contains   1160 bytes in   1 blocks (ref 0)
      bssmap: reset ack   contains   1160 bytes in   1 blocks (ref 0)

Let's free it after sending (or in case of error).

Change-Id: Ic174f6eecd6254af597dfbdc1c9e3d65716f0a76
2019-05-10 02:56:07 +07:00
Neels Hofmeyr f839967f91 comment: apply function renames to message cycle explanation
The misnomed 'nas_decode' and 'nas_encode' APIs have been renamed to
'ran_decode' and 'ran_encode', which was forgotten in the large comment
explaining the message path in sccp_ran.h. Apply the rename there.

Change-Id: I742fb4844ac8a9ad76f59883ae9447eb8819b82d
2019-05-09 11:45:59 +00:00
Harald Welte db6855c9f9 msub_check_for_release(): Initialize msc_role_a_c
This fixes the following compiler error:

msub.c: In function ‘msub_fsm_active’:
msub.c:85:35: error: ‘msc_role_a_c’ may be used uninitialized in this function
[-Werror=maybe-uninitialized]
   || (msc_role_a_c && msc_role_a_c->ran->type == OSMO_RAT_EUTRAN_SGS)))
                       ~~~~~~~~~~~~^~~~~
msub.c:59:26: note: ‘msc_role_a_c’ was declared here
  struct msc_role_common *msc_role_a_c;
                          ^~~~~~~~~~~~

Change-Id: Id518dea77d01ed0518ca7cba6b1b363f1c8e6543
2019-05-09 08:42:48 +00:00
Neels Hofmeyr 880b950862 vty/cfg: add missing write-back of inter-BSC and inter-MSC HO config
Add missing 'show running-config' test to test_neighbor_ident.vty transcript
test.

Change-Id: Ie3b084e169da9509b37f6ab91ade79440c1b36d2
2019-05-09 02:06:42 +02:00
Neels Hofmeyr 5255874529 fix regression: fix internal MNCC operation
While developing the inter-MSC handover refactoring, I was annoyed by the fact
that mncc_tx_to_cc() receives an MNCC message struct containing a msg_type, as
well as a separate msg_type argument, which may deviate from each other. So, as
a first step I wanted to make sure that all callers send identical values for
both by inserting an OSMO_ASSERT(msg_type == msg->msg_type). Later I was going
to remove the separate msg_type argument.

I then forgot to
- carry on to remove the argument and
- to actually test with internal MNCC (it so happens that all of our ttcn3
  tests also use external MNCC).

As a result, the "large refactoring" patch for inter-MSC Handover breaks
internal MNCC operation.

Fix that: remove the separate msg_type argument and make sure that all callers
of mncc_tx_to_cc() indeed pass the desired msg_type in msg->msg_type, and hence
also remove the odd duality of arguments.

Various functions in mncc_builtin.c also exhibit this separate msg_type
argument, which are all unused and make absolutely no sense. Remove those as
well.

Related: OS#3989
Change-Id: I966ce764796982709ea3312e76988a95257acb8d
2019-05-09 01:23:09 +02:00
Harald Welte e39f6cd752 smpp: Make libsmpp34 use talloc for its allocations
We are just introducing smpp34_set_memory_functions() in libsmpp34
to allow applications like OsmoMSC to provide their own heap allocator
callback functions.  Let's used this to integrate with talloc and
hence allow talloc tracking/debugging for libsmpp34 internal
allocations.

Depends: libsmpp34 Change-Id I3656117115e89638c093bfbcbc4369ce302f7a94
Change-Id: Ie2725ffab6a225813e65768735f01678e2022128
Related: OS#3913
2019-05-08 23:49:45 +02:00
Neels Hofmeyr 4ac8009c29 rename bscconfig.h to config.h, cleanup
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-08 17:02:32 +02:00
Neels Hofmeyr e27fa15022 GSUP: include terminating nul in inter-MSC source/destination name
Before, I was testing with osmo-hlr patch
I01a45900e14d41bcd338f50ad85d9fabf2c61405 applied, but that patch is currently
in an abandoned state.

This is the counterpart implemented in osmo-msc: always include the terminating
nul char in the "blob" that is the MSC IPA name.

The dualities in the formats of routing between MSCs is whether to handle it as
a char*, or as a uint8_t* with explicit len (a blob).

In the VTY config to indicate target MSCs for inter-MSC handover, we have
strings. We currently even completely lack a way of configuring any blob-like
data as a VTY config item.

In osmo-hlr, the IPA names used for routing are currently received as a char*
which *includes* the terminating nul char. So in osmo-msc, if we also always
include the nul char, it works.

Instead, we could just send the char* part without the nul char, and apply
above mentioned osmo-hlr patch. That patch would magically match a name that
lacks a nul with a name that includes one. I think it is better to agree on one
format on the GSUP wire now, instead of making assumptions in osmo-hlr on the
format of the source/target names for routing. This format, from the way GSUP
so far transmits the IPA SERNO tag when a client attaches to osmo-hlr, happens
to include the terminating nul char.

Change-Id: I9ca8c9eef104519ed1ea46e2fef46dcdc0d554eb
2019-05-08 17:02:32 +02:00
Neels Hofmeyr c4628a3ad4 large refactoring: support inter-BSC and inter-MSC Handover
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-08 17:02:32 +02:00
Neels Hofmeyr 56f90132b8 gsm_04_11: use gsm48_decode_bcd_number2(), evaluate rc
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-08 01:51:06 +02:00
Neels Hofmeyr 5b1e0309b5 fix various missing line endings in logging
Change-Id: I013eb0eeb5673c06034465020e5dc5230f45ddf5
2019-05-06 23:45:28 +02:00
Neels Hofmeyr 08aae21fca vlr subscr get/put: also check against NULL
Change-Id: I36929a4ba4abb46909181068d1d0af967b1f5a94
2019-04-26 18:55:25 +00:00
Vadim Yanitskiy 03e8754960 libmsc/gsm_04_11.c: clarify implicit CP-ACK handling
Change-Id: I3c5327a5019590c65d0ccb33a52f07b3988ea952
2019-04-25 20:01:19 +00:00
Vadim Yanitskiy baccf3a74b libmsc/db.c: print info about database name and libdbi version
Change-Id: Iaed452548eb2d847738b78d3489bf6f507a2e3c1
2019-04-25 21:24:19 +02:00
Vadim Yanitskiy bfd45d514d configure.ac: drop useless SQLite3 dependency
We don't use SQLite3 directly, we use libdbi and libdbdsqlite3.

Change-Id: Ibf4eb53e60a2957eca99a2c8e613f75a8c43ac89
2019-04-25 21:23:35 +02:00
Philipp Maier bb5ba8b7df vlr_sgs_fsm: make sure vsub is marked used when LA is present
When the LU is accepted and the subscriber (vsub) is not claimed as "in
use" in the ref counting system.

- Make sure vlr_subscr_get() is called when the LU is accepted.

Change-Id: Iba90be095569cc5212c61ab8e8a9bfd4ae51fd44
Related OS#3934
2019-04-17 12:50:07 +02:00
Vadim Yanitskiy a45e7458e3 configure.ac: drop rudimentary check for -fvisibility=hidden
This looks like a rudiment from OpenBSC, where we have:

  #define BSC_API __attribute__((visibility("default")))

However, we don't use this attribute in OsmoMSC.

Change-Id: Ie2f18e9b47eca478f6e4702606068814546e34ce
2019-04-15 15:04:48 +00:00
Neels Hofmeyr 0714002e28 smpp: fix vlr_subscr use count bugs
In smpp_openbsc.c submit_to_sms(), "get" the appropriate use count upon
assigning sms->receiver, fixing a -1 use count upon sms_free().

Also, avoid a "put" of a NULL subscriber in the same function.

Related: OS#3930
Change-Id: Idaf01cd3cfa08088ce0d543d0576db957dc94262
2019-04-15 13:46:47 +02:00
Omar Ramadan e2bd9eb37d Allow MME name preformatted as FQDN in SGsAP
Change-Id: I2d55f9524b9fc15d661e5cb6b5df6d715c52ccf9
2019-04-13 21:55:18 +00:00
Neels Hofmeyr c65cfe8696 gsm_04_08_cc: improve logging for CC trans
Pass trans around more functions as log context.
Add missing "rx" logging for two cases.

Change-Id: If79f724a2faca70023271398c618cfe490fb294e
2019-04-12 02:15:25 +02:00
Neels Hofmeyr ff7074a0c7 add LOG_TRANS, proper context for all transactions
Change-Id: I2e60964d7a3c06d051debd1c707051a0eb3101ba
2019-04-12 02:15:25 +02:00
Neels Hofmeyr 7c5346cd70 vlr_subscr: use osmo_use_count
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore)
Change-Id: Ib06d030e8464abe415ff597d462ed40eeddef475
2019-04-12 02:15:25 +02:00
Neels Hofmeyr d553c085e7 sms queue: avoid repeated Paging for a failed SMS
So far, sms_pending_failed() starts a new sms_queue_trigger() run. The
intention behind that might have been to fill up the queue when sending SMS has
failed, but the practical effect is actually bad:

As current ttcn3-msc-test runs show, a failed MT SMS gets triggered multiple
times in short succession, i.e. osmo-msc repeatedly sends Paging Requests for
the same subscriber.

This special case happens actually only when there are few SMS still in the DB
to be delivered. In the TTCN3 test, there is exactly one MT SMS for one
subscriber, and retriggering the queue brings up the same SMS every time.

See f_tc_lu_and_mt_sms_paging_and_nothing() and f_tc_sgsap_mt_sms_and_nothing()
which say:
"/* Expect the MSC to page exactly 10 times before giving up */"

This is bad because an MSC should send a Paging Request exactly once. Retrying
failed Paging is clearly the task of the BSC, not the MSC. The remaining code
around Paging correctly follows this paradigm, but this retrigger doesn't.

Do not immediately trigger the SMS queue on a failed MT SMS. Instead, leave it
up to the periodical SMS queue trigger to decide.

This patch will cause the MT SMS tests in ttcn3-msc-tests to fail, because the
test expectations are bogus. The patch fixing the test run is listed 'Related'
below.

Related: I7dce12942a65eaaf97f78ca69401c7f93faacb9e (osmo-ttcn3-hacks)
Change-Id: I24bf9f1c1167efe1080ae4cf47ed2ef0bd981e49
2019-04-12 02:15:25 +02:00
Neels Hofmeyr e4f7e71204 enable osmo_fsm_term_safely(), apply logging changes
Start using osmo_fsm_term_safely(true), the recently added feature of
libosmocore's fsm.c. Deallocates in slightly changed order and with slightly
modified logging. Adjust test expectations.

Depends: I8eda67540a1cd444491beb7856b9fcd0a3143b18 (libosmocore)
Change-Id: I195a719d9ec1f6764ee5a361244f59f0144dc253
2019-04-12 02:15:25 +02:00
Philipp Maier 7231edb732 sgs_iface: fix nullpointer dereference
The function sgs_tx() is using the sgs connection pointer as context,
even though it has done a check for a nullpointer in the line before.
This is very prone to lead into a segfault when the SGs connection dies.

Change-Id: I88b95e3f8cd35241ad68f08d94c6ad7067b842e6
Related: OS#3859
2019-04-11 07:32:48 +00:00
Harald Welte 5dede769e7 smpp_smsc: Call destroy_tlv() when using build_tlv()
The libsmpp34 build_tlv() function is allocating dynamic memory
which we need to release again by calling destroy_tlv().

Change-Id: Iacc74c9948fb10fa79c0dd7b0cb72d4adbefdeed
Closes: OS#3912
2019-04-10 10:53:23 +00:00
Pau Espin f8af776fba sms_queue: Print dest msisdn instead of unknown subscriber
If subscriber is NULL, vlr_subscr_msisdn_or_name() returns string
"unknown", which is less informative than printing destination msisdn
expected for the queued sms.
This happens for instance if an sms was queued with Store&Forward and
destination subscriber is not currently registered

Change-Id: I4b8b54c9c41b17d4e1fa7ece63aa91a98036ef11
2019-04-09 19:45:03 +07:00
Vadim Yanitskiy 0f52319765 msc/gsm_data.h: drop unused SMS_HDR_SIZE macro
Change-Id: Iea32a26673ebb57b18dc7e86ad321d9ed48e0948
2019-04-08 07:34:20 +00:00
Philipp Maier 4826465708 vlr_sgs: start lu expiration timer on sgs eps detach
When the subscriber is detached from SGs services (but not from 2g
services). Then the subscriber essentially becomes a regular 2g
subscriber, which means thet the lu expiration timer needs to be
started.

Change-Id: If95c63706dc1c5a537f7cd1b6481252427cbf234
Related: OS#3614
2019-04-07 18:57:39 +00:00
Philipp Maier 0803d88d9a vlr_sgs: fix SGs IMSI detech from non EPS services
When the subscriber is detached from non EPS services while the
SGs-association is not SGs-NULL, it needs to be removed from the VLR
database.

Change-Id: I575cf6036ad39468f590b2d57a06cd3512a4c31c
Related: OS#3614
2019-04-07 18:57:31 +00:00
Vadim Yanitskiy 6c766c6464 tests/sms_queue: track the use of NULL talloc memory contexts
As we don't initialize all talloc contects of libmsc, let's make
sure that there is nothing left in the NULL context after the
unit test execution is finished.

Change-Id: I99fd82750aff376e4d90eaa2402ec41f4d59ef86
2019-04-01 12:02:57 +00:00
Vadim Yanitskiy 96262a7ca6 libmsc/sms_queue.c: fix memleak in smsq_take_next_sms()
A memleak has been noticed after executing some of TTCN-3 test
cases. For example, the following ones:

  - MSC_Tests.TC_lu_and_mo_sms,
  - MSC_Tests.TC_lu_and_mt_sms.

The key point is that MSC_Tests.TC_lu_and_mo_sms basically sends
a MO SMS to a non-attached subscriber with MSISDN 12345, so this
message is getting stored in the SMSC's database.

As soon as the SMSC's queue is triggered, sms_submit_pending() would
retrieve pending messages from the database by calling function
smsq_take_next_sms() in loop and attempt to deliver them.

This function in it's turn checks whether the subscriber is attached
or not. If not, the allocated 'gsm_sms' structure would not be
free()ed! Therefore, every time smsq_take_next_sms() is called,
one 'gsm_sms' structure for an unattached subscriber is leaked.

Furthermore, there is a unit test called 'sms_queue_test', that
actually does cover smsq_take_next_sms() and was designed to
catch some potential memory leaks, but...

In order to avoid emulating the low-level SQLite API, the unit
test by design overwrites some functions of libmsc, including
db_sms_get_next_unsent_rr_msisdn(), that is being called by
smsq_take_next_sms().

The problem is that the original function in libmsc does
allocate a 'gsm_sms' structure on heap (using talloc), while
the overwriting function did this statically, returning a
pointer to stack. This critical difference made it impossible
to spot the memleak in smsq_take_next_sms() during the
unit test execution.

Let's refactor 'sms_queue_test' to use dynamic memory allocation,
and finally fix the evil memleak in smsq_take_next_sms().

Change-Id: Iad5e4d84d8d410ea43d5907e9ddf6e5fdb55bc7a
Closes: OS#3860
2019-04-01 12:02:57 +00:00
Keith Whyte 18f1138a6d Write configuration correctly from vty (alert notifications)
The default is [yes] alert-notifications, therefore write
"no alert-notifications" in the case that this has
been set, in order to preserve configuration after
write is called from vty.

Change-Id: I079aea96ee83fbf04f782dcab344d41a4ef04657
2019-03-29 22:48:38 +00:00
Vadim Yanitskiy 81635d3400 libmsc: fix: properly initialize the SGs server
It was observed that the SGs server is started before
the actual VTY configuration is parsed. For example:

  sgs
   local-port 9999
   local-ip 127.0.0.1
   vlr-name vlr.example.net

produces the following debug output:

  <0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=0.0.0.0:29118
  DLSS7 NOTICE <001e> osmo_ss7.c:1284 0: ASP Restart for server not implemented yet!
  DSGS NOTICE <0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=0.0.0.0:9999
  DSGS NOTICE <0011> sgs_server.c:185 SGs socket bound to r=NULL<->l=127.0.0.1:9999
  DMNCC DEBUG <0004> msc_main.c:604 Using internal MNCC handler.

The first startup is triggered by sgs_iface_init(), before reading
the VTY configuration, so the logging style is different. The next
two calls to sgs_server_open() are triggered during reading of the
VTY configuration by cfg_sgs_local_port() and cfg_sgs_local_ip().

Let's avoid starting the SGs server three times, and do it once,
after the VTY configuration is parsed. Also, keep the possibility
to change the binding parameters at run-time.

Change-Id: Ie0c31205ac48be7e50d0380a89833771b2708da4
2019-03-28 17:10:11 +07:00
Vadim Yanitskiy 1d802e2635 libmsc/sgs_vty.c: don't print SGs socket error twice
Because sgs_server_open() already does this.

Change-Id: Ifea308645c7829691dbcf53e4f59841090119006
2019-03-28 10:09:11 +00:00
Vadim Yanitskiy 4eaefc2222 libmsc/sgs_iface.c: register sgs_vlr_reset_fsm on DSO load
Change-Id: I80cd2e5645d6e391080376250c0853a3f3f821ef
2019-03-28 10:09:11 +00:00
Vadim Yanitskiy 118a0b890e libmsc/sgs_iface.c: fix copy-paste error
Change-Id: I57b773659302ad4c92b6e670c6156e90a50189ba
2019-03-28 10:09:11 +00:00
Pau Espin 0dad52d0b7 debian/control: Fix typo
Change-Id: I3392d8e184413203d27fc3d75371de4d66f205b9
2019-03-27 11:42:29 +00:00
Neels Hofmeyr 83e311fa3e vlr_subscr_name(): use OSMO_STRBUF
We now have a nicer way to compose strings in a buffer than this.
(Cosmetic preparation for inter-MSC handover patch.)

Change-Id: I7813068032475deb3850af05f7ba5a6f652e7fa2
2019-03-24 16:49:07 +00:00
Philipp Maier 8fa2dbe5b1 msc_vty: add missing header file
The symbol GSM0808_SPEECH_FULL_BM is used in msc_vty.c, but gsm_08_08.h,
where the symbol is declared is not included.

Change-Id: I31a8894031aa2321d7dbf2586d076bc303247278
2019-03-19 18:52:56 +01:00
Sylvain Munaut da9f37ed20 libvlr: Allow 2G auth tuples to be re-used without going through AUTH
If the key_seq we get in the first messages matches the last_tuple, then
both we and the MS already know the key to use and we don't need the
AUTH REQUEST/RESPONSE cycle.

Security wise ... not so good, and so IMHO the 'auth required' option
in the MSC should always be set. But this allows to turn on ciphering on
a channel without doing any MM transaction, and so the MS doesn't turn
on the T3240 timer which allows to have a ciphered silent-call channel
that won't timeout.

Change-Id: Ief840a2ae7a0ffd2bf0bf726f209a79e3f787646
Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2019-03-19 15:24:01 +00:00
Harald Welte 31f4c1f927 a_iface: OSMO_ASSERT() if we ever want to send BSSAP with invalid length
Let's add a safeguard against sending BSSAP messages with invalid length
values.  This should never happen, and we'd rather see osmo-msc assert
during the development cycle than ever releasing a version which sends
invalid messages out on the wire.

Change-Id: I94327a0d276c65b528a8c7e33dde61ed53582284
Related: OS#3805
2019-03-19 13:39:14 +00:00
Philipp Maier 9286114f6f silent_call: use osmo_strlcpy() instead of strncpy()
If gsm_silent_call_start() is called with an over long string in
traffic_dst_ip, then the target string might be left unterminated. Lets
use osmo_strlcpy() so that we can be sure the result in scd->traffic_ip
is always terminated.

Fixes: CID#196068
Change-Id: Ic81842175e412ae7d97d023b612412f33411d60c
2019-03-15 09:51:15 +01:00
Sylvain Munaut 935583069d libmsc: Allow different channel types to be requested as silent calls
Change-Id: I82645708dd27864cf33ea9cc993ead0983415602
2019-03-14 12:39:31 +00:00
Neels Hofmeyr f90496f577 vty: add cmd subscriber ID sms delete-all
In ttcn3-msc-tests, so far we leave an intentionally failed MT SMS in the SMS
queue, which may cause it to re-appear in subsequent tests.

Allow removing all SMS for a given subscriber from the SMS database for good.

(I dimly remember a user report where the SMS queue spams failed SMS attempts,
and the only way to get rid of SMS for a given subscriber is to tamper with the
sms.db file directly. This should no longer be necessary with this command.)

Related: I7dce12942a65eaaf97f78ca69401c7f93faacb9e (osmo-ttcn3-hacks)
Change-Id: I637cbd7adc075a192f49752b38779391472ff06d
2019-03-08 04:51:18 +01:00
Neels Hofmeyr 34a36da3ef SMS queue: properly log failed attempts number
Change-Id: I16f2d29855eb715eccbdc5def225f43c110fab8e
2019-03-07 04:17:53 +01:00
Neels Hofmeyr 864d32c043 gsm_04_11_gsup.c: drop unused conn lookup
An earlier code state used the conn to lookup the transaction, but this is now
done by vsub. Hence the conn lookup is not used and not needed.

conn is no longer used since 36c44b2100,
change-Id I093f36d63e671e50e54fc6236e97a777cc6da77b,
"transaction: change arguments of trans_find_by_sm_rp_mr()"

Change-Id: Ia878d70138c883cb1a1d983516aff83efa6488ce
2019-03-07 04:17:47 +01:00