Commit Graph

40 Commits

Author SHA1 Message Date
Neels Hofmeyr 9aac5c2d21 add rudimentary NRI support for MSC pooling
This patch served for a manual testing counterpart for osmo-bsc to implement
MSC pooling.

This enables a basic MSC pooling setup, but for a production setup, osmo-msc
would still lack various features related to unloading subscribers to another
MSC as explained in 3GPP TS 23.236.

Change-Id: Iafe0878a0a2c8669080d757b34a398ea75fced36
2020-06-19 03:58:13 +02:00
Neels Hofmeyr 46d526a3df use new osmo_mobile_identity API everywhere
Depends: Ic3f969e739654c1e8c387aedeeba5cce07fe2307 (libosmocore)
Change-Id: Idfc8e576e10756aeaacf5569f6178068313eb7ea
2020-06-19 03:58:13 +02:00
Neels Hofmeyr c192c0bf71 log which DTAP messages are sent to RAN
So far, the logging said only "RAN encode: BSSMAP: DTAP", but not *which* DTAP
message, which is in fact a very interesting detail when reading osmo-msc logs.

Change-Id: I0cb8d1e3307737ffe53730c64bb984adacedb2da
2019-10-21 00:40:31 +02:00
Alexander Couzens efa7b97133 replace osmo_counter with stat_items
osmo_counter will be soon deprecated. Use the newer and more flexible
osmo_stat_item instead.

Depends on: Id2462c4866bd22bc2338c9c8f69b775f88ae7511 (libosmocore)
Change-Id: I6a20123b263f4f808153794ee8a735092deb399e
2019-07-18 14:50:51 +00:00
Oliver Smith cbf2c93d11 vlr: optionally send IMEI early to HLR
When 'check-imei-rqd 1 early' is set in the config, send the IMEI to
the HLR before doing the location update with the HLR.

The OsmoHLR documentation referenced in the code will be added in
osmo-hlr.git's Change-Id I2dd4a56f7b8be8b5d0e6fc32e04459e5e278d0a9.

Related: OS#2542
Change-Id: I88283cad23793b475445d814ff49db534cb41244
2019-05-15 10:57:43 +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

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
- messages between MSC-A and MSC-{I,T} don't need to be routed via E-interface
- 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

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

* 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

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

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
  [--rtp_stream--]          [--rtp_stream--]

* 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

* 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 7c5346cd70 vlr_subscr: use osmo_use_count
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore)
Change-Id: Ib06d030e8464abe415ff597d462ed40eeddef475
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
Neels Hofmeyr b62289aa27 mm_rx_id_resp(): use osmo_mi_name()
Change-Id: I6bb053def223ed698351ad9f52c1e36293df5d59
2019-01-12 09:51:22 +00:00
Neels Hofmeyr 361e571815 refactor log ctx for vlr_subscr and ran_conn
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:


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
- 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
2019-01-12 09:51:22 +00:00
Neels Hofmeyr 46c06e28c1 add LOG_RAN_CONN() to use the conn->fi->id for context
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
2019-01-12 09:51:22 +00:00
Neels Hofmeyr 55d22d9e5e use osmo_lu_type_name() from libosmocore
Change-Id: Ib562bb5fb272c0c3ae0849f32b28faa2c26f9bb7
2019-01-12 09:51:22 +00:00
Neels Hofmeyr 7814a83298 use osmo_rat_type from libosmocore
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

Depends: I659687aef7a4d67ca372a39fef31dee07aed7631 (libosmocore)
Change-Id: I2c78c265dc99df581e1b00e563d6912c7ffdb36b
2019-01-04 17:26:14 +00:00
Stefan Sperling afa030d6f9 make gsup ipa name configurable in osmo-msc.cfg
Add a 'ipa-name' VTY command which overrides the default IPA name
used by the MSC. This is a prerequisite for inter-MSC handover.

Related: OS#3355
Change-Id: I317d6c59f77e92fbb2b875a83dc0ec2fa5cb6006
2018-12-11 13:08:00 +00:00
Neels Hofmeyr aa14bac370 LU: do not always invoke sub_pres_vlr_fsm_start()
sub_pres_vlr_fsm_start() starts the FSM, invokes the START event, and then this
FSM invariably always directly terminates when vsub->ms_not_reachable_flag ==

So if it is false, there is not much use in instantiating a whole FSM instance
that just terminates again, we might as well directly issue the
parent-term-event and save some logging space.

The same condition is already in place in the vlr_proc_acc_fsm.c in
_proc_arq_vlr_node2_post_vlr() for CM Service Request and Paging Response. Now
also skip this for LU.

Change-Id: Id2303a795dfd381f76e94ff8ff2f495926ca8ba0
2018-12-11 11:37:27 +00:00
Neels Hofmeyr c036b79918 rename gsm_subscriber_connection to ran_conn
In preparation for inter-BSC and inter-MSC handover, we need to separate the
subscriber management logic from the actual RAN connections. What better time
to finally rename gsm_subscriber_connection.

* Name choice:

In 2G, this is a connection to the BSS, but even though 3GPP TS commonly talk
of "BSS-A" and "BSS-B" when explaining handover, it's not good to call it
"bss_conn": in 3G a BSS is called RNS, IIUC.

The overall term for 2G (GERAN) and 3G (UTRAN) is RAN: Radio Access Network.

* Rationale:

A subscriber in the MSC so far has only one RAN connection, but e.g. for
inter-BSC handover, a second one needs to be created to handover to. Most of
the items in the former gsm_subscriber_connection are actually related to the
RAN, with only a few MM and RTP related items. So, as a first step, just rename
it to ran_conn, to cosmetically prepare for moving the not strictly RAN related
items away later.


- Rename some functions from msc_subscr_conn_* to ran_conn_*
- Rename "Subscr_Conn" FSM instance name to "RAN_conn"
- Rename SUBSCR_CONN_* to RAN_CONN_*

Change-Id: Ic595f7a558d3553c067f77dc67543ab59659707a
2018-11-30 22:45:42 +01:00
Neels Hofmeyr d0756b152b GSUP client: send CN domain IE on LU request
Give the HLR a chance to send us updated subscriber data by indicating the CN
domain to be Circuit Switched, only during a LU Request GSUP message.

Adjust msc_vlr_tests to expect the added GSUP CN domain IE to indicate CS, i.e.
append '280102'.

Related: OS#3601
Change-Id: I0c2d33fbfdb4728e480679120d06b7f3a2ccfd76
2018-09-30 23:55:25 +02:00
Neels Hofmeyr 986fe7ed18 store classmark in vlr_subscr, not conn
Store all Classmark information in the VLR.

So, we now always know the Classmark 1 (mandatory IE for LU). This is visible
in the msc_vlr_tests -- they no longer indicate "assuming A5/1 is supported"
because classmark 1 is missing, because we now know the Classmark 1.


During Location Updating, we receive Classmark 1; during CM Service Request and
Paging Response, we receive Classmark 2. So far we stored these only for the
duration of the conn, so as soon as a LU is complete, we would forget CM1.

In other words, for anything else than a LU Request, we had no Classmark 1
available at all.

During Ciphering Mode Command, we rely on Classmark 1 to determine whether A5/1
is supported. That is moot if we don't even have a Classmark 1 for any CM
Service Request or Paging Response initiated connections.

The only reason that A5/1 worked is that we assume A5/1 to work if Classmark 1
is missing. To add to the confusion, if a phone indicated that it did *not*
support A5/1 in the Classmark 1, according to spec we're supposed to not
service it at all. A code comment however says that we instead want to heed the
flag -- which so far was only present in a Location Updating initiated
connection. Now we can make this decision without assuming things.

This got my attention while hacking on sending a BSSMAP Classmark Request from
the MSC if it finds missing Classmark information, and was surprised to see it
it lacking CM1 to decide about A5/1.

Change-Id: I27081bf6e9e017923b2d02607f7ea06beddad82a
2018-09-17 01:12:13 +02:00
Philipp Maier 6f4752e00c vlr_access_req_fsm: use correct cause codes
The FSM that controls the VLR ACCESS uses cause code 9
identity of the MS is currently not known in VLR (MSC-Reboot)
However, this cause code is from the GMM domain and is interpreted
as GSM48_REJECT_SRV_OPT_TMP_OUT_OF_ORDER by the MS, which cauese


Change-Id: Ic058c93387f9be9af4940f8961839c02b93ee370
Closes: OS#3266
2018-05-16 10:34:16 +02:00
Neels Hofmeyr 99a8d235f3 msc conn ref counts: log human readable list of conn owners
Change-Id: I2a09efafbdbdde0399238f7d79feea8612605201
2018-04-12 19:40:01 +00:00
Neels Hofmeyr 158095960b refactor VLR FSM result handling
Instead of keeping separate enums for FSM results and translating between those
and the actual 04.08 reject causes that will ultimately reach the MS, just pass
enum gsm48_reject_value cause codes around everywhere.

Collapse some VLR *_timeout() and *_cancel() api to just *_cancel() with a
gsm48 cause arg.

(Hopefully) improve a few reject causes, but otherwise just aim for more
transparent decisions on which cause value is used, for future fixes of
returned causes.

Depends: I6661f139e68a498fb1bef10c266c2f064b72774a (libosmocore)
Change-Id: I27bf8d68737ff1f8dc6d11fb1eac3d391aab0cb1
2018-04-12 19:40:00 +00:00
Neels Hofmeyr fe4ba7c057 cosmetic: embed compl_l3_type in FSM id
In the subscr_conn_fsm instance's ID, include the Complete Layer 3 type, so
that we can see on the first glance whether a state transition belongs to MO or

The huge patch is due to the cosmetic change affecting nearly every single log
line in the msc_vlr_tests, by nature of changing the FSM's ID.

Related: OS#3122
Change-Id: I2a7e27e0f16df1872dcda64cb928c3b8528ea3f7
2018-04-11 21:39:44 +00:00
Neels Hofmeyr 4068ab278b properly receive BSSMAP Clear Complete and Iu Release Complete
When sending a BSSMAP Clear or Iu Release, do not immediately discard the conn,
but wait until a BSSMAP Clear Complete / Iu Release Complete has been received.

Hence we will no longer show in the log that an incoming Release/Clear Complete
belongs to an unknown subscriber, but will still be around to properly log the

Related: OS#3122
Change-Id: Ie4c6aaba3866d6e5b98004e8870a215e8cf8ffc1
2018-04-11 21:39:44 +00:00
Neels Hofmeyr e3d3dc6ea2 refactor subscr_conn and subscr_conn_fsm de-/alloc

1. Glue the gsm_subscriber_connection alloc to the subscr_conn_fsm.
2. Add separate AUTH_CIPH state to the FSM.
3. Use conn->use_count to trigger conn release.
4. Add separate RELEASING state to the FSM.
5. Add rate counters for each of the three Complete Layer 3 types.


1. Glue the gsm_subscriber_connection alloc to the subscr_conn_fsm.

Historically, a gsm_subscriber_connection was allocated in libbsc land, and
only upon Complete Layer 3 did libmsc add the fsm instance. After splitting
openbsc.git into a separate osmo-msc, this is no longer necessary, hence:

Closely tie gsm_subscriber_connection allocation to the subscr_conn_fsm
instance: talloc the conn as a child of the FSM instance, and discard the conn
as soon as the FSM terminates.

2. Add separate AUTH_CIPH state to the FSM.

Decoding the Complete Layer 3 message is distinctly separate from waiting for
the VLR FSMs to conclude. Use the NEW state as "we don't know if this is a
valid message yet", and the AUTH_CIPH state as "evaluating, don't release".

A profound effect of this: should we for any odd reason fail to leave the FSM's
NEW state, the conn will be released right at the end of msc_compl_l3(),
without needing to trigger release in each code path.

3. Use conn->use_count to trigger conn release.

Before, the FSM itself would hold a use count on the conn, and hence we would
need to ask it whether it is ready to release the conn yet by dispatching
events, to achieve a use_count decrement.

Instead, unite the FSM instance and conn, and do not hold a use count by the
FSM. Hence, trigger an FSM "UNUSED" event only when the use_count reaches zero.
As long as use counts are done correctly, the FSM will terminate correctly.

These exceptions:

- The new AUTH_CIPH state explicitly ignores UNUSED events, since we expect the
  use count to reach zero while evaluating Authentication and Ciphering. (I
  experimented with holding a use count by AUTH_CIPH onenter() and releasing by
  onleave(), but the use count and thus the conn are released before the next
  state can initiate transactions that would increment the use count again.
  Same thing for the VLR FSMs holding a use count, they should be done before
  we advance to the next state. The easiest is to simply expect zero use count
  during the AUTH_CIPH state.)

- A CM Service Request means that even though the MSC would be through with all
  it wants to do, we shall still wait for a request to follow from the MS.
  Hence the FSM holds a use count on itself while a CM Service is pending.

- While waiting for a Release/Clear Complete, the FSM holds a use count on

4. Add separate RELEASING state to the FSM.

If we decide to release for other reasons than a use count reaching zero, we
still need to be able to wait for the msc_dtap() use count on the conn to

(An upcoming patch will further use the RELEASING state to properly wait for
Clear Complete / Release Complete messages.)

5. Add rate counters for each of the three Complete Layer 3 types.

Besides LU, also count CM Service Request and Paging Response
acceptance/rejections. Without these counters, only very few of the auth+ciph
outcomes actually show in the counters.

Related: OS#3122
Change-Id: I55feb379e176a96a831e105b86202b17a0ffe889
2018-04-11 21:39:44 +00:00
Neels Hofmeyr 16c42b5fba subscr_conn: store complete_layer3_type in conn, not FSM event arg
Instead of jumping through hoops to pass the Complete Layer 3 operation that
created this conn via FSM event dispatch parameters, put it right in the
gsm_subscriber_connection struct, where it always belonged.

Move definition of the enum complete_layer3_type to gsm_data.h, where
gsm_subscriber_connection is defined.

Introduce msc_subscr_conn_update_id() to set the complete_layer3_type of the
conn as soon as a Complete Layer 3 message is received.

In msc_subscr_conn_update_id(), already include an mi_string argument to
prepare for an upcoming patch where the FSM will be allocated much earlier when
the Mobile Identity is not known yet, and we'll also update the fi->id here.

The odd logging change in the msc_vlr_tests output uncovers a wrong use of the
osmo_fsm_inst_dispatch() data argument for SUBSCR_CONN_E_CN_CLOSE events: if a
child FSM signals unsuccessful result, instead of the failure cause, it passed
the complete_layer3_type, as requested upon FSM allocation, which was then
misinterpreted as a failure cause. Now a child FSM failure will pass NULL
instead, while other SUBSCR_CONN_E_CN_CLOSE events may still pass a valid cause

Related: OS#3122
Change-Id: Iae30dd57a8861c4eaaf56999f872d4e635ba97fb
2018-04-03 02:13:16 +02:00
Neels Hofmeyr 08b3828995 use osmo_init_logging2() with proper talloc ctx
Since the logging allocations now also show up in the root context report, some
tests need adjusted talloc checks.

In msc_vlr_tests, also output the number of talloc blocks before tests are
started to show that the number didn't change after the tests.

Change-Id: Iae07ae60230c7bab28e52b5df97fa3844778158e
2018-03-30 23:20:03 +02:00
Neels Hofmeyr e9e2f5cde6 cosmetic: rename conn_fsm "bump" event to "release_when_unused"
The naming of "bump" was short and made sense to me at the time of writing, but
it is keeping pretty much everyone else at a distance, no-one intuitively gets
what it is supposed to mean.

Clarify by renaming to "release_when_unused".

Adjust test expectations.

Change-Id: I4dcc55f536f63b13a3da29fff1df5fe16751f83a
2018-03-15 14:24:57 +00:00
Neels Hofmeyr dfdc61de68 msc_vlr_tests: revert IMSI parameter and test nr output
Three recently merged commits take the msc_vlr_tests in a wrong direction.

The IMSI is usually encoded in the hex streams. The rationale behind hex
streams is that it is a) easily copied from a wireshark trace and b) exactly
the bytes as sent by an actual phone. It is hard to parameterize the IMSI
because we would have to employ our encoding functions, which I intentionally
want to keep out of the loop here.

The test number should not appear in the normal test output, so that adding a
test or changing their order does not affect expected output for following
tests. The nr is simply for manual invocation, only seen when invoked with -v.

- "VLR tests: always print test parameters"
- "Expand VLR tests"
- "Move IMSI into test parameters"

Change-Id: Ie1b49237746751021da88f6f07bbb9f780d077c9
2018-03-02 03:22:16 +01:00
Harald Welte 2346619c1a remove unused "authorized-regexp" VTY command
This is another left-over VTY command from the OsmoNITB days.

If such functionality is desired, it must be implemented in OsmoHLR,
but not here.

Related: OS#2528
Change-Id: Icf0897c47388e49ba7886b55acc728a6f7d213fe
2018-02-14 09:04:52 +01:00
Max b0a4314911 VLR tests: always print test parameters
For each test print:
* the test number

Unfortunately tests are organized in such a way that we don't know the
number of particular test in advance. Nevertheless, it make sense to
always print it regardless of -v option presense.

Related: OS#2864
Change-Id: I2e1d7701f5322d2311f32b796148a8b414f53b8e
2018-02-07 12:08:19 +01:00
Harald Welte a3ab1de7dc remove traces of bsc_subscriber
Change-Id: I8672f0a76cb47595444a7ddbc4f34fc4ddaeb375
2018-01-24 23:29:51 +01:00
Harald Welte 80315ef6b5 Fix msc_vlr test results (.err) for new libosmocore GSM48_PDISC names
In I8de7c01f9ea1d66c384e57449c4140186f5ce6c5, libosmocore introduced
shorter names in gsm48_pdisc_names, which has implications on the
expected test output

Change-Id: I4421872a0d609dd50a6b911b928aa5e111d1ad24
2018-01-24 22:55:05 +01:00
Max a263bb215b VLR: log subscriber update
* move log helpers to generic header
* log subscriber update

It's handy for troubleshooting issues with subscriber update via GSUP
from HLR.

Change-Id: I1958aeeb3ea99831c7e2c5ee9a6b59834baf4520
2017-12-31 11:01:46 +00:00
Neels Hofmeyr 6166f29412 subscr_conn: introduce usage tokens for ref error tracking
When hunting a conn use count bug, it was very hard to figure out who's (not)
using the conn. To ease tracking down this bug and future bugs, explicitly name
what a conn is being reserved for, and track in a bit mask.

Show in the DREF logs what uses and un-uses a conn. See the test expectation
updates, which nicely show how that clarifies the state of the conn in the

On errors, log them, but don't fail hard: if one conn use/un-use fails, we
don't want to crash the entire MSC before we have to.

Change-Id: I259aa0eec41efebb4c8221275219433eafaa549b
2017-11-27 15:40:01 +01:00
Neels Hofmeyr 8a656eb3a5 msc_vlr_tests: set a valid lac for fake conns
Change-Id: Ie647d93a54aefad5bde8a9411d983cd60714b83d
2017-11-22 14:40:37 +01:00
Philipp Maier fbf6610dc1 Implement AoIP, port to M3UA SIGTRAN (large addition and refactoring)
This was originally a long series of commits converging to the final result
seen in this patch. It does not make much sense to review the smaller steps'
trial and error, we need to review this entire change as a whole.

Implement AoIP in osmo-msc and osmo-bsc.

Change over to the new libosmo-sigtran API with support for proper
SCCP/M3UA/SCTP stacking, as mandated by 3GPP specifications for the IuCS and
IuPS interfaces.

From here on, a separate osmo-stp process is required for SCCP routing between
OsmoBSC / OsmoHNBGW <-> OsmoMSC / OsmoSGSN build from libosmo-sccp and osmo-iuh master branches now for new

Patch-by: pmaier, nhofmeyr, laforge
Change-Id: I5ae4e05ee7c57cad341ea5e86af37c1f6b0ffa77
2017-08-29 12:51:18 +00:00
Neels Hofmeyr 78ada64be7 04.08: log protocol discriminators and message types by name
On incoming 04.08 messages, we log only the protocol discriminator in
decimal. Enhance: log pdisc and message type in hex, and also log the
protocol and message type as human readable string.

Also adjust the msc_vlr tests' log statements for wrapped rx/tx functions
of dtap from/to the MS.

Adjust the expected output of msc_vlr_tests.

Change-Id: Ida205d217e304337d816b14fd15e2ee435e7397d
Depends: libosmocore change-id I0fca8e95ed5c2148b1a7440eff3fc9c7583898df
2017-08-23 14:35:31 +02:00
Neels Hofmeyr 84da6b1edb Implement IuCS (large refactoring and addition)
osmo-nitb becomes osmo-msc
add DIUCS debug log constant
add iucs.[hc]
add msc vty, remove nitb vty
add libiudummy, to avoid linking Iu deps in tests
Use new msc_tx_dtap() instead of gsm0808_submit_dtap()
libmgcp: add mgcpgw client API
bridge calls via mgcpgw

Enable MSC specific CTRL commands, bsc_base_ctrl_cmds_install() still needs to
be split up.

Change-Id: I5b5b6a9678b458affa86800afb1ec726e66eed88
2017-08-08 19:17:53 +02:00
Neels Hofmeyr 54a706cf92 vlr: LU FSM: enable Retrieve_IMEISV_If_Required
Change-Id: I121b95ad6d5ecb7603815eece2b43008de487a8a
2017-08-07 16:52:25 +02:00
Neels Hofmeyr 6a29d326e0 Add msc_vlr test suite for MSC+VLR end-to-end tests
Change-Id: If0e7cf20b9d1eac12126955b2f5f02bd8f1192cd
2017-07-23 04:30:05 +02:00