Commit Graph

6676 Commits

Author SHA1 Message Date
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
Neels Hofmeyr 8e2c6a31c1 use only accepted ran_conns for new transactions
In connection_for_subscriber(), do not return a ran_conn that is not yet
authenticated nor one that is already in release.

Using a ran_conn that is not yet authenticated may cause an auth/ciph
violation.

Using a ran_conn that is already in release may cause a use-after-free, see
OS#3842 for a description.

To be paranoid, upon releasing a conn, go through the transaction freeing
motions again by calling trans_conn_closed(), just in case some odd code path
added another transaction while the conn was already in release.

Related: OS#3842
Change-Id: Id957032e0ae1ff8ba055a75c3523447d3d06cbc3
2019-03-07 03:58:29 +01:00
Keith Whyte a3a8821167 Don't deliver alert notifications to ESME not yet bound.
We create a new ESME in smsc->esme_list on establishment
of a TCP connection, yet we do not know the system id 
or anything else, until the ESME identifies and authenticates.

So do not send alert notifications until
we know the bind status (and system_id)

Change-Id: Iec92d4c145ca050c2e212139572eeaae581b99df
2019-02-28 14:18:29 +00:00
Vadim Yanitskiy 477cbc6d93 libmsc/msc_vty.c: drop dead comparison against null
Since vsub->sgs.mme_name is allocated statically, comparing it
to null doesn't make sense - it's always != NULL.

Change-Id: Ib2933a20471ebff9dfe1d9fdddf39d177504c951
Fixes: CID#178166 Array compared against 0 (NO_EFFECT)
2019-02-28 00:14:21 +07:00
Vadim Yanitskiy 4d75877e61 libmsc/sgs_vty.c: always write server address and VLR name
Comparing an array to null is not useful, because the expression
will always evaluate as true. Let's just always write SGs server
address and VLR name, no mater whether default values are used
or not, same as we do for the HLR address and port.

Change-Id: If045e42fca0315b0777eb86c44bf934ce58b340b
Fixes: CID#190871 Array compared against 0 (NO_EFFECT)
2019-02-28 00:14:15 +07:00
Vadim Yanitskiy e9ef7c6b9a libmsc/sgs_iface.c: fix SGS_STATE_NS11 counter reference
The SGS_STATE_TS11 is not for counters, it's for timers!

Change-Id: Ifbb1a37e644ae8bf8e7959f6f6cd6403ac1f2f1b
Fixes: CID#190872 Out-of-bounds read (OVERRUN)
2019-02-26 23:16:45 +00:00
Vadim Yanitskiy 1396e1ca35 libmsc/ran_conn.c: add missing 'break' to OSMO_RAT_EUTRAN_SGS
Change-Id: I18dfd08ea0857f2751164a295dd9de20a2024ac3
Fixes: CID#190874
2019-02-26 23:16:10 +00:00
Oliver Smith 0dfa61e39e debian: depend on libdbd-sqlite3
Make sure that we don't fail at startup with:

<0009> db.c:621 Failed to create database connection to sqlite3 db
'sms.db'; Is the sqlite3 database driver for libdbi installed on this
system?

Tested by building the Debian package and looking at its depends.

Related: OS#3771
Change-Id: I7c099212a6ad7d87978c3dce63ce7385d8076bd1
2019-02-25 14:59:03 +01:00
Vadim Yanitskiy 64623e1848 libmsc/gsm_09_11.c: implement guard timer for NCSS sessions
It may happen that either the MS or an EUSE would become
unresponsive during a call independent SS session, e.g.
due to a bug, or a dropped message. In such cases, the
corresponding transaction would remain unfreed forever.

This change introduces a guard timer, that prevents keeping
'stalled' NCSS sessions forever. As soon as it expires, both
sides (i.e. MS and EUSE) are getting notified, and the
transaction is being released.

By default, the timer expires after 30 seconds. As soon as
either the MS, or an EUSE initiates any activity,
the watchdog timer is rescheduled.

The timeout value can be configured from the VTY:

  msc
   ...
   ! Use 0 to disable this timer
   ncss guard-timeout 30

Please note that changing the timeout value at run-time
doesn't affect the existing NCSS sessions, excepting the
case when the timer is disabled at run-time.

This change makes TC_lu_and_ss_session_timeout pass.

Change-Id: Icf4d87c45e90324764073e8230e0fb9cb96dd9cb
Related Change-Id: (TTCN) I3e1791773d56617172ae27a46889a1ae4d400e2f
Related: OS#3655
2019-02-20 03:22:38 +07:00
Harald Welte 390d140b56 a_iface: Fix hexdumping of N-DATA.req
For some reason the existing code was using msgb_hexdump_l2() while the
L2 header is not used by the BSSAP transmit code.  Let's fix this.

Change-Id: I52a1eb3a867ece63fcfa4c2a720d035ebfb90a7b
2019-02-18 13:52:09 +01:00
Harald Welte fd96d45049 a_iface: use 'const' qualifier for ran_conn whenever possible
Change-Id: I8a15c9baae2071569e2ecc4635ddaf5a0001f959
2019-02-18 13:52:09 +01:00
Harald Welte 977b5486b1 a_iface: Centralize/wrap BSSAP / N-DATA transmission
We don't want multiple callers to osmo_sccp_tx_data_msg() each having
to hex-dump a log message about the to-be-transmitted message, with
half of the caller sitest missing that printing.  Let's centralize
all calls of osmo_sccp_tx_data_msg() in a wrapper function which
takes care of the related OSMO_ASSERT() and the related printing.

Change-Id: I6159ea72cc8e0650eda6c49544acd65e9c15e817
2019-02-18 13:52:05 +01:00