Catched by ASan on db_sms_test unit test:
DDB NOTICE test_db_sms_get('Empty TP-UD'): osmo-msc/src/libmsc/db.c:796:2: runtime error: null pointer passed as argument 2, which is declared to never be null
That happens on empty PDU because dbi_result_get_binary returns NULL,
and sms->user_data_len is 0, so it's harmless but we can avoid calling
mempcy and make ASan happy.
Change-Id: I545967464c406348b8505d1729213cfb4afcd3e2
Thanks to db_sms_test, it was discovered that storing an SMS with
empty TP-User-Data (TP-UDL=1) causes buffer overruns in libdbi
and it's SQLite3 driver (libdbdsqlite3):
DDB NOTICE test_db_sms_store('Empty TP-UD'): ==7791== Invalid write of size 2
==7791== at 0x857DC60: dbd_quote_binary (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==7791== by 0x5B2B321: dbi_conn_quote_binary_copy (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==7791== by 0x4073B1: db_sms_store (db.c:701)
==7791== by 0x405BB5: test_db_sms_store (db_sms_test.c:310)
==7791== by 0x405BB5: main (db_sms_test.c:546)
==7791== Address 0x7ed1cf0 is 0 bytes after a block of size 0 alloc'd
==7791== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7791== by 0x857DC4B: dbd_quote_binary (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==7791== by 0x5B2B321: dbi_conn_quote_binary_copy (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==7791== by 0x4073B1: db_sms_store (db.c:701)
==7791== by 0x405BB5: test_db_sms_store (db_sms_test.c:310)
==7791== by 0x405BB5: main (db_sms_test.c:546)
...
DDB NOTICE test_db_sms_get('Empty TP-UD'): ==8051== Invalid read of size 1
==8051== at 0x5B30510: _dbd_decode_binary (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==8051== by 0x857D957: dbd_fetch_row (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==8051== by 0x5B2C86E: dbi_result_seek_row (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==8051== by 0x40828F: next_row (db.c:188)
==8051== by 0x40828F: db_sms_get (db.c:805)
==8051== by 0x406C29: test_db_sms_get (db_sms_test.c:390)
==8051== by 0x405C14: main (db_sms_test.c:547)
==8051== Address 0x8f74641 is 0 bytes after a block of size 1 alloc'd
==8051== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8051== by 0x5DBEB49: strdup (strdup.c:42)
==8051== by 0x857D93C: dbd_fetch_row (in /usr/lib/x86_64-linux-gnu/dbd/libdbdsqlite3.so)
==8051== by 0x5B2C86E: dbi_result_seek_row (in /usr/lib/x86_64-linux-gnu/libdbi.so.1.1.0)
==8051== by 0x40828F: next_row (db.c:188)
==8051== by 0x40828F: db_sms_get (db.c:805)
==8051== by 0x406C29: test_db_sms_get (db_sms_test.c:390)
==8051== by 0x405C14: main (db_sms_test.c:547)
==8051==
success, as expected
DDB NOTICE verify_sms('Empty TP-UD'): user_data_len mismatch: E0 vs A3
Apparently, dbi_conn_quote_binary_copy() doesn't properly handle
zero-length input. Let's guard against this.
Observed with:
- libdbi-dev 0.9.0-1
- libdbd-sqlite3:amd64 0.9.0-2ubuntu2
Change-Id: If0b2bb557118c5f0e520a2e6c2816336f6028661
Since OsmoMSC has built-in SMSC, it needs to store the messages
somewhere. Currently we use libdbi and SQLite3 back-end for that.
For a long time, the db_sms_* API remained uncovered by unit tests.
This change aims to fix that, and does cover the following calls:
- db_sms_store(),
- db_sms_get(),
- db_sms_get_next_unsent(),
- db_sms_mark_delivered(),
- db_sms_delete_sent_message_by_id(),
- db_sms_delete_by_msisdn(),
- db_sms_delete_oldest_expired_message().
Due to performance reasons, the test database is initialized in
RAM using the magic filename ':memory:'. This is a feature of
SQLite3 (and not libdbi), see:
https://www.sqlite.org/inmemorydb.html
Of course, this unit test helped to discover some problems:
1) Storing an SMS with empty TP-User-Data (TP-UDL=0) causes
buffer overruns in both db_sms_store() and db_sms_get().
2) TP-User-Data-Length is always being interpreted in octets,
regardless of DCS (Data Coding Scheme). This results in
storing garbage in the database if the default 7-bit
encoding is used. Fortunately, the 'user_data' buffer
in structure 'gsm_sms' is large emough, so we don't
experience buffer overruns.
3) db_sms_delete_oldest_expired_message() doesn't work
as expected. Instead of removing the *oldest* expired
message, it tries to remove the *newest* one.
The current test expectations do reflect these problems.
All of them will be fixed in the follow-up patches.
Change-Id: Id94ad35b6f78f839137db2e17010fbf9b40111a3
In the most cases we need to check whether particular char buffer
is empty or not. Using strlen() for that involves more CPU power,
so let's just check the first character against '\0'.
Change-Id: I8728876b80c870e82247e6e56f719e10ed322a95
The current way of printing subscriber, connection, and transaction
info is ugly (sorry) and has several problems:
- the terminal width should be large enough to fit quite long lines,
otherwise the output is unreadable and looks misaligned;
- some fields (such as subscriber name) can be larger than it's
expected, so either they're getting truncated, or again, the
output is misaligned and unreadable;
- adding new info fields would require one to think about the
alignment and would make the output even more cumbersome.
Here is an example output of 'show connection' command:
_Subscriber_______________________________________ _LAC_ _RAN___________________ _MSC-A_state_________ _MSC-A_use_
IMSI-123456789012345:MSISDN-12345:TMSI-0x12345678 1 GERAN-A-4294967295:A5-3 WAIT_CLASSMARK_UPDATE 2=cm_service,trans_cc
IMSI-123456789012356:MSISDN-234567:TMSI-0x123ABC78 65535 UTRAN-Iu-4294967295 COMMUNICATING 2=cm_service,trans_sms
IMSI-262073993158656:MSISDN-123456:TMSI-0x493026BA 1 GERAN-A-1 MSC_A_ST_COMMUNICATING 1=1 (silent_call)
Another 'show subscriber' command mixes the information about
subscriber, its connections and transactions without any alignment,
what also decreases the readability.
This change introduces a hierarchical approach, based on the old
'field per line' formatting. First of all, the VTY commands were
extended with optional flags:
show connection [trans]
show subscriber cache [(conn|trans|conn+trans)]
show subscriber TYPE ID [(conn|trans|conn+trans)]
so it can be decided, whether to print child connections and/or
transaction, or not. For example:
show connection trans
would print all connections and their child transactions with
hierarchical alignment:
Connection #00:
Subscriber: IMSI-262073993158656:MSISDN-123456:TMSI-0x76760B75
RAN connection: GERAN-A-1
RAN connection state: MSC_A_ST_COMMUNICATING
LAC / cell ID: 1 / 0
Use count total: 1
Use count: 1 (silent_call)
Transaction #00:
Unique (global) identifier: 0x00000000
GSM 04.07 identifier (MT): 0
Type: silent-call
another example is:
show subscriber cache conn+trans
which would print all known subscribers,
their active connections and transactions:
Subscriber #00:
MSISDN: 123456
LAC / cell ID: 1 / 0
RAN type: GERAN-A
IMSI: 262073993158656
TMSI: 76760B75
...
Connection:
RAN connection: GERAN-A-1
RAN connection state: MSC_A_ST_COMMUNICATING
...
Transaction #00:
Unique (global) identifier: 0x00000000
GSM 04.07 identifier (MT): 0
Type: silent-call
Transaction #01:
Unique (global) identifier: 0x00000001
GSM 04.07 identifier (MO): 0
Type: SMS
Transaction #02:
Unique (global) identifier: 0x00000002
GSM 04.07 identifier (MT): 0
Type: SMS
Please note that we don't print redundant info in child nodes
(i.e. connection and transaction info), such as subscriber name
in connection info, nor connection name in transaction info - it
is clear from the hierarchical formatting.
Change-Id: I5e58b56204c3f3d019e8d4c3c96cefdbb4af4d47
The HLR (which is connected via the GSUP interface) may fail and
disconnect. On the next location update the VLR will try to talk to the
HLR and fail. This failure event is not communicated towards the SGs
related code and the SGs-association will remain in the LA-PRESENT state
forever. Lets add code to report the problem to the SGs code and trigger
a RESET an the SGs interface.
- Add a flag to report an HLR problem back to the SGs code
- Fix the FSM that controls the reset
- Make sure the all SGs associations are reset when the failure occurs.
Change-Id: Icc7df92879728bc98c85fc1d5d8b4c6246501b12
Related: OS#3859
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
DB counters has been used to save osmo_counters & osmo_rate_ctr to a local
sqlite databases every 60 seconds.
This is quite slow e.g. 1000 subscriber might slow the msc down.
Change-Id: Id64f1839a55b5326f74ec04b7a5dbed9d269b89c
Later on we want to do extra steps upon receiving a Rx Reset Ack
(checking for Osmux support from peer). Let's move handling of this
message into its own function to have handling implementation in one
place.
Change-Id: I516c4baf6071d26f6c530726d93677bed968efd1
Prepare for Rhizomatica's subscriber on demand use case, in which the
network access is disabled by default for new subscribers, but the IMEI
is required in the HLR to find out which user has which IMSI. Due to the
network access being disabled, the location update request towards the
HLR fails and the MS gets rejected, so we need to get the IMEI early.
Related: OS#2542, OS#3755
Change-Id: I256224194c3b8caf2b58a88d11dccd32c569201f
In ran_a_make_handover_request() we do prevent destination buffer
(r.encryption_information.key) overflow, but not source buffer
(n->geran.chosen_encryption->key) overrun if an incorrect key
length is received. Let's fix this.
Change-Id: I278bb72660634c2d535e1bd3d7fce5696da23575
Fixes: CID#198450 Out-of-bounds access
We basically need to make sure that one of two possible IEs
is not NULL, while another is NULL (eXclusive OR). This can
be done using at least two conditional branches.
Change-Id: Ie0f9b5c1bbbfb744e0615da07d76037d91b0abc8
Fixes: CID#198444 Logically dead code
For some reason, having ternary operator there makes Coverity think
that 'n->geran.chosen_encryption' is dereferenced before checking
against NULL. Let's make it happy, and move the assignment.
Change-Id: I95051d0f02e2fdd3ec8da3a506109e7b23e99b4b
Fixes: CID#198454 Dereference before null check
In gsm48_rx_mm_serv_req() we need to make sure that a given message
buffer is large enough to contain both 'gsm48_hdr' and
'gsm48_service_request' structures.
Comparing msg->data_len with size of pointer if wrong because:
- we actually need to compare with size of struct(s),
- we need msgb_l3len(), not length of the whole buffer.
Moreover, since we have to use the pointer arithmetics in order
to keep backwards compatibility with Phase1 phones, we also
need to check the length of both Classmark2 and MI IEs.
Change-Id: I6e7454d7a6f63fd5a0e12fb90d8c58688da0951e
Since in parse_umts_auth_resp() we are checking the length of
GSM48_IE_AUTH_RES_EXT TLV, we need to print its length, but
not the length of the whole L3.
Change-Id: I2bfebce6d017be834bfe7628ffa2b341eb82c11c
The MSC_A_EV_HANDOVER_END exists as parent term event for the msc_ho_fsm, but
it is not actually required as functional event, since all cleanup is handled
in msc_ho_fsm_cleanup().
That's why I never bothered to add the event to msc_a_fsm, but of course that
means we get an error message after each (successful and unsuccessful)
handover, that the MSC_A_EV_HANDOVER_END is not permitted.
Allow the event and ignore it to silence the error message.
Explain in a comment.
Change-Id: Ie8dc0c0a631b7da43111f329562007766a21b134
After neels/ho was merged, SMS over IuCS/RANAP was failing in both
MO and MT direction. The reason was that all mobile-terminated SMS-CP
layer messages were sent in RANAP with SAPI-0 instaed of SAPI-1.
Change-Id: I98e6eddb52d5c61c4e2d34bdfcd43cf460296ad7
Closes: OS#3993
The event is actually never dispatched and useless, because when an RTP stream
releases, the call_leg terminates directly anyway (which wasn't apparent when
starting to design the call_leg FSM yet).
Change-Id: I6b2fc1225c960fa2f7c46adf241520217a07821c
The SMPP 3.4 specification defines the password field as a
"Variable-length octet string with maximum length of 9", and according
to table 3-1 this means including the terminating NUL-byte.
However, OsmoMSC allows to configure longer passwords in the ESME
configuration. Those passwords will then never match, as libsmpp34
performs length validation and generates a parser error for anyone
trying to send a longer password via SMPP.
The same applies for system-id, where we have to permit only 15
characters with zero termination, but not 16 characters.
Change-Id: I81ef593e84bf1e15f6746386fc145495fae29354
Closes: OS#3166
Instead of calling trans_log_subsys() for each LOG_TRANS() log line, rather
store in trans->log_subsys once on trans_alloc() and use that.
Do not fall back to the RAN's own subsystem (DBSSAP / DIUCS), it makes little
sense and may cause logging to switch subsystems depending on the RAN state.
In trans_log_subsys(), add missing switch cases:
- Log silent call transactions also on CC.
- Log USSD on DMM.
About USSD: we currently have no dedicated USSD logging category. As a result,
after LOG_TRANS() was introduced [1], USSD logged on DBSSAP/DIUCS or DMSC,
depending on whether a RAN was associated with the trans or not. Before that
change, USSD always logged on DMM, so, until we have a separate logging
category for USSD, consistenly use DMM again.
[1] in I2e60964d7a3c06d051debd1c707051a0eb3101ba / ff7074a0c7
Related: coverity CID 198453
Change-Id: I6dfe5b98fb9e884c2dde61d603832dafceb12123
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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>
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
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
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
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
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
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
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)
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)
The SGS_STATE_TS11 is not for counters, it's for timers!
Change-Id: Ifbb1a37e644ae8bf8e7959f6f6cd6403ac1f2f1b
Fixes: CID#190872 Out-of-bounds read (OVERRUN)
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
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
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
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
The connection ref-counting implementation is specific to RAN
connections, and is not applicable for anything else. Moreover,
the API of this code is declared in 'ran_conn.h', so let's
move the code to a more logical place.
Change-Id: I593675d9bf56eaef12afdaf596ee1337b9a44259
According to GSM 04.80, section 2.5.1, Release complete message
may have an optional Cause IE. Let's add a new function, that
allows to specify cause location and value.
This function will be used by the upcoming changes.
Change-Id: I3b9e8e4f473d113d5b9e9e5d33f7914202077203
Depends Change-Id: (libosmocore) Ie3ac85fcef90a5e532334ba3482804d5305c88d7
The previous implementation of msc_send_ussd_release_complete() was
based on gsm0480_create_ussd_release_complete(), that doesn't
allow to specify GSM 04.07 transaction identifier.
The ability to specify particular transaction identifier
is required for handling multiple SS/USSD transactions.
Change-Id: Id2975c3383f18e83124ba38927c03980d67ddadb
Depends Change-Id: (libosmocore) Ie3ac85fcef90a5e532334ba3482804d5305c88d7
When a call ends that has been established in an CSFB context, we should
add a CSFB Indication IE to the BSSMAP CLEAR COMMAND to instruct the BSC
to add further CSFB related IEs into the RR RELEASE.
- Check if an SGs association exists and add CSFB Indication IE
Change-Id: I6cfa4b3becdd0138d74e2e1eddd83a0b1568c1de
Related: OS#3778
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
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
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
The need to pass a pointer to RAN connection in order to find
a transaction limits possible use cases of trans_find_by_sm_rp_mr(),
e.g. when we need to find a transaction, but RAN connection is not
established yet.
Moreover, the pointer to RAN connection was only used to obtain
pointers to gsm_network and vlr_subscr, so we can just
pass them directly.
Change-Id: I093f36d63e671e50e54fc6236e97a777cc6da77b
Log transaction allocation errors as such. While at it, use proper
subsystem to log missing VLR subscriber.
Change-Id: I617be8793b9416ccd49022c72f7d93df7f4fb4d9
After libosmocore commit
If1e851ac605c8d2fde3da565b0bd674ea6350c2e
b27e6feb699712345373e87a48187dc622e4fa92
the osmo-msc master build is broken.
Apply the msgb_wrap_with_TL() rename to msgb_push_tl() to unbreak the build.
Change-Id: I1d4675e0c907b2f92f2ec79b02356391a6d72aa8
After recent changes to vlr_subscr_name() result became variable-length
which messes up old vty code. Fix this by moving it to the very end and
adjusting headers as necessary. While at it, make sure we don't print
headers if we have nothing else to show.
Change-Id: Id06b4277ff790d95457d0cc2f94ef6bf5366bb21
Adds (no) alert-notifications as a per-esme vty command,
in order to allow some ESMEs to be excluded from alerts.
The default is still to send alert notifications to all esme,
so no changes are required to the config file to maintain
identical operation after this patch.
Change-Id: I57f4d268ca6fe6a233f2caaffce62e4aade01274
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
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
The pointers conn, conn->vsub and conn->vsub->last_tuple are checked,
but before the check those pointers are already dereferenced during
assignment. This defeats the purpose of the check. Lets dereference
those pointers after the check.
Fixes: CID#190404
Change-Id: Ice4992606f3799eac13154ec0b9f53e46d2e178e
Instead of
MGW(MGW_99)
use a name of
msc-mgcp(MSISDN:2331_GERAN_A:00000017_trans99)
1. The FSM is communication towards an MGW, not the MGW itself. When reading
combined logging (gsmtap_log), it is confusing to read 'MGW' in a log coming
from the MSC. The API is also called msc_mgcp_*.
2. Calling the FSM instance 'MGW_' again doesn't make sense.
3. Indicate 'trans' before the trans_id (trans_id was already shown, but not
indicated what it was).
4. Also indicate the actual subscriber's identification.
5. Also indicate the RAN connection and conn_id.
This comes up while trying to understand a call coming in on an already
established call: parsing the log with a human brain is near torture without
this info, taking extremely long to get grips on.
Change-Id: Ie5fc1ffb7eba0209fee4666a075655cd24d27473
ran_conn_get_conn_id(): instead of a talloc allocated string, return a static
buffer in ran_conn_get_conn_id(). So far this function had no callers.
Refactor ran_conn_update_id() API: during early L3-Complete, when no subscriber
is associated yet, update the FSM Id by the MI type seen in the L3 Complete
message: ran_conn_update_id_from_mi(). Later on set the vsub and re-update.
Call vlr.ops->subscr_update when the TMSI is updated, so that log context
includes the TMSI from then on.
Enrich context for vlr_subscr_name and ran_conn fi name.
Include all available information in vlr_subscr_name(); instead of either IMSI
or MSISDN or TMSI, print all of them when present. Instead of a short log,
rather have more valuable context.
A context info would now look like:
Process_Access_Request_VLR(IMSI-901700000014706:MSISDN-2023:TMSI-0x08BDE4EC:GERAN-A-3:PAGING_RESP)
It does get quite long, but ensures easy correlation of any BSSAP / IuCS
messages with log output, especially if multiple subscribers are busy at the
same time.
Print TMSI and TMSInew in uppercase hexadecimal, which is the typical
representation in the telecom world.
When showing the RAN conn id
GERAN_A-00000017
becomes
GERAN-A-23
- We usually write the conn_id in decimal.
- Leading zeros are clutter and might suggest hexadecimal format.
- 'GERAN-A' and 'UTRAN-Iu' are the strings defined by osmo_rat_type_name().
Depends: I7798c3ef983c2e333b2b9cbffef6f366f370bd81 (libosmocore)
Depends: Ica25919758ef6cba8348da199b0ae7e0ba628798 (libosmocore)
Change-Id: I66a68ce2eb8957a35855a3743d91a86299900834
When a CM Service Req is being rejected, we should do so before changing the
state of the current conn.
Concerning multiple CM Service Requests: in fact we should store multiple
requests, but first fix the status quo of rejecting multiple requests.
Change-Id: I39209ee6662694aa054a2fc0d21eae76fb33e2f1
For each conn, set a default logging category, to distinguish categories for
BSSMAP and RANAP based conns.
LOG_RAN_CONN(): log with the conn's default category,
LOG_RAN_CONN_CAT(): log with a manually set category (mostly for keeping
previous DMM logging on the same category).
In some places, replace LOGP() using manual context with LOG_RAN_CONN(), and
remove the manual context info, now provided by the conn->fi->id.
This is loosely related to inter-BSC and inter-MSC handover: to speed up
refactoring, I want to avoid the need for manual logging context and just use
this LOG_RAN_CONN().
Change-Id: I0a7809840428b1e028df6eb683bc5ffcc8df474a
In gsm0911_rcv_nc_ss() we sometimes use pdisc parsed from msgb and
sometimes constant. This function is only called when protocol
discriminator is GSM48_PDISC_NC_SS so there's no point in parsing it
again from msgb.
Let's make it consistent and always use constant.
Change-Id: Iae40bf9906fe676ff817c709120015fca4c9e042
Remove "0 =", "1 =" in-front of the boolean descriptions of
auth-tuple-reuse-on-error. The online VTY doc and the pdf manual
prepend the value automatically.
Change-Id: Ifd14c2fb3f58701eaf66570d729a660233fb83ed
Rationale: reading pcaps becomes so much easier when each of osmo-bsc and
osmo-msc address their MGW with differing domain names. Otherwise, both will
have a '0@mgw' endpoint and it gets really confusing.
After this, with according configuration, there can be a '0@bsc' and a '0@msc'
endpoint.
osmo-mgw-for-msc.cfg:
mgcp
domain msc
osmo-msc.cfg:
msc
mgw endpoint-domain msc
Depends: Ia662016f29dd8727d9c4626d726729641e21e1f8 (osmo-mgw)
Change-Id: I87ac11847d1a6d165ee9a2b5d8a4978e7ac73433
Replace locally defined enum ran_type with libosmocore's new enum
osmo_rat_type, and value_string ran_type_names with osmo_rat_type_names.
The string representations change, which has cosmetic effects on the test suite
expectations.
Depends: I659687aef7a4d67ca372a39fef31dee07aed7631 (libosmocore)
Change-Id: I2c78c265dc99df581e1b00e563d6912c7ffdb36b
during code review, I completely overlooked this:
We've added the 'ipa-name', which identifies the MSC on the GSUP link to the
HLR, under the 'msc' section, while all other GSUP/HLR related config is under
the 'hlr' section.
Before we roll that out in a release, move it over to 'hlr'.
Related: OS#3355
Change-Id: I1a572865aa90c5fa43c6f57282a6e2b06776e425
If Assignment fails in the BSC, trigger an EV_TEARDOWN_ERROR in the mgcp_ctx
FSM instance, so that the call gets torn down immediately. Before this, the
non-call would idle around without anything happening.
Related: OS#3236
Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore)
Change-Id: I358cfbaf0f44f25148e8b9bafcb9257b1952b35a
If a call is already busy and another call is coming in, do not try to
immediately assign an lchan (before this patch, it fails because there already
is an mgcp_ctx for the conn). Leave the second CC transaction waiting.
When a call is hung up, as soon as the old mgcp_ctx is discarded, look for
other CC transactions that are waiting. If there is one, trigger assignment, so
a new mgcp_ctx is set up for the new call.
This fixes the following scenario:
- from A, call B.
- from C, call B; B rings during ongoing call.
- in B, pick up the call, choose to drop the old call.
After this patch, and with osmo-bsc patch with change-id
I0c00ec2c120e5008281755adcd4944a3ce4d8355
we are now able to talk to the new caller.
I currently haven't tested yet what happens if there is *three* peers trying to
talk to the same number, running out of lab phones (not really, just not
bothering now). Possibly we should be taking over the particular call indicated
by the CC TI; instead, the current patch version takes on whichever waiting
call it finds first. This is fine if *one* additional call comes in on an
ongoing call, and this is already a huge improvement to what we had before.
Related: OS#3735
Change-Id: I0ba216b737909e92080a722db26e3577726c63cb
The flag is set to true when an assignment has been started, and it is only
relevant for a CC transaction. So fix naming and place in cc struct.
Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and
I0ba216b737909e92080a722db26e3577726c63cb/
Change-Id: I8dacf46141ba0b664e85b0867ade330c97d8495f
Various places in the code check a flag whether assignment was started and
launch it. To fix incoming-call-during-ongoing-call, I will tweak that logic.
To be able to do that only in one place, remove code dup.
Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and
I0ba216b737909e92080a722db26e3577726c63cb/
Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore: LOGPFSMSL)
Change-Id: I11c0b7dc3f1a747028629b48e522bb3b864884ba
In rare cases, a conn is already associated with a subscriber. So far, we
abort()ed on that, bringing the entire osmo-msc down. Rather log an error and
keep the service running.
In vlr.ops.subscr_assoc, add success/failure return value, and abort the
LU/PARQ on error.
I haven't figured out in detail yet why/how a subscriber would re-launch a
LU/PARQ on a conn that is already associated, so far it is merely clear that we
do not want to crash the MSC if that happens. A log is in OS#3742.
Related: OS#3742, OS#3743
Change-Id: Ic0d54644bc735700220b1ef3a4384c217d57d20f
Do not break the currently ongoing call when rejecting a second incoming
caller.
There may be multiple (up to seven) simultaneous CC transactions, and there is
one mgcp_ctx for the currently active RTP stream.
Release the MGCP context only when the active CC transaction is releasing.
Before this patch, any CC transaction release would destroy the single MGCP
context, possibly breaking the currently ongoing call (another CC trans).
This also fixes a possible use-after-free if there were pending MGCP message
responses for the MGCP context; they are canceled properly for a released
transaction, but since one transaction would free the other transaction's MGCP
state, the clean up did not take place and possibly caused an mgcp client
response handling to access a freed mgcp_ctx.
Related: OS#3735
Change-Id: I1f8746e7babfcd3028a4d2c0ba260c608c686c76
Use local variables instead of writing trans->conn-> all the time.
Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and
I0ba216b737909e92080a722db26e3577726c63cb/
Change-Id: I99717b3b72a9d7cbc95455ea25b2018ec1755308
As a rudiment of OsmoNiTB, OsmoMSC is still involved in SMS
processing, storage (in SQLite DB), and routing (via SMPP).
In real networks this is done by the external entity called
SMSC (SMS Centre), while the MSC is doing re-encapsulation
of GSM 04.11 SM-TL (Transport Layer) payload (i.e. TPDU)
between SM-RL (Relay Layer) and MAP.
Since OsmoMSC itself is not a 'Network in The Box' anymore, it
makes sense to replicate the 'traditional' behaviour of MSC.
The problem is that this behaviour cannot co-exist with the
current implementation, so the key idea is to rip out the
local SMS storage and routing from OsmoMSC, and (re)implement
it in a separate process (OsmoSMSC?).
As a temporary solution, this change introduces a 'kill-switch'
VTY option that enables routing of SMS messages over GSUP
towards ESME (through VLR and HLR), but breaks the local
storage and routing. This is why it's disabled by default.
As soon as we move the SMS processing and storage away from
OsmoMSC, this behaviour would be enabled by default, and
the VTY option would be hidden and deprecated. At the moment,
this option basically does nothing, and will take an effect
in the follow-up changes.
Change-Id: Ie57685ed2ce1e4c978e775b68fdffe58de44882b
Related: OS#3587
We can check if we're parsing the config file by checking
whether vty->type equals VTY_FILE. This avoids the use of
an extra local variable to track the parsing state.
Change-Id: I85161575e025f7c389832427a434bd8e2d6ecc75
Fixes: 1051c42088
Related: OS#3355
When the VLR subscriber information is shown on the VTY it shows IMSI
and TMSI, but not IMEI and IMEISV. Since in some cases this information
might be helpful, lets display it as well.
Change-Id: Iedd75dbb9850388ec1fedb984ed0b8bf4c62e780
Always use LAC which is part of Cell Global ID otherwise we might end up
in a situation where separately stored LAC differs.
Both are described in 3GPP TS 23.008 $2.4 as temporary subscriber data
to be stored in VLR. Both are defined in 3GPP TS 23.003. The LAC is part
of LAI which is part of CGI so there should be no case when those values
differ for a given subscriber.
Change-Id: I993ebc3e14f25e83124b6d3f8461a4b18f971f8e
When a subscriber is displayed the RAN type is not included in the
overview. Meanwhile the MSC supports multiple different ran types it
becomes important to see in which RAN the subscriber is currently
active.
Change-Id: I000cafd5e41b9951d51b6bd6672ee68a224b8212
Related: OS#3615
When a VLR subscriber is displayed on the VTY we get a lot of meta
information, but there are also some flags to handle the internal
subscriber status e.g. conf_by_radio_contact_ind. Lets display those
flags as well as this information can be very helpful when debugging
problems in the VLR
Change-Id: I59a9145a4daad50d68de3fd5c3291f027256917f
Do not show the VTY command's own use count during 'show subscriber <ID>'.
When using 'show subscriber msisdn 2023', I was surprised to see a use count of
2 and suspected a use count leak. With 'show subscriber cache' however, the use
count is 1.
So I realized it is the vty command's own use count that makes it two, besides
the lu_complete=true one.
Change-Id: Id02b57b7ed299b010b9f8b9e809548eb1e6aa699