Commit Graph

58 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 63b246453b gsup: indicate CN-Domain in SendAuthInfo Requests
In order for osmo-hlr to be able to 100% guarantee distinct INDs for CS and PS,
set CN-Domain = CS in all SendAuthInfo Requests.

In Milenage auth, it is highly desirable that osmo-hlr guarantees use of
distinct INDs for CS and PS domains.  If an MSC and SGSN attached at the same
time use the same IND bucket to generate Milenage SQN, that collision would
rapidly waste SQNs and load osmo-hlr with requesting new auth tuples on each
CS/PS Complete-Layer3.

So far, osmo-msc did not indicate the CN domain in the GSUP SendAuthInfo
Request, which was neither required nor evaluated. The CN-Domain is only sent
for the UpdateLocation Request that usually follows later.

Related: OS#4318
Change-Id: I22f44068268e62801cadbf6542efaf153423cd65
2019-12-12 02:10:06 +01: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
Neels Hofmeyr 14c34d8bec add msc_vlr tests for UMTS without ciphering
Following I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7, have tests for UMTS
authentication both for cases with and without encryption.

- Rename test_umts_authen_utran to test_umts_auth_ciph_utran() (uses
- Again add test_umts_authen_utran() not using encryption.
- Likewise with test_umts_authen_resync_utran().

Some permutations are still missing, like UMTS AKA on GERAN with encryption
enabled; not bothering at the moment.

Related: OS#2783
Change-Id: I54227f1f08c38c0bf69b9c48924669c4829b04b9
2019-08-05 23:24:47 +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
Vadim Yanitskiy c11342ec4e libmsc/gsm_04_11.c: fix double init of both SMR and SMC FSMs
Change-Id: I23700a2c575a96057ef22bc5d8ab6271104d619b
2019-05-12 04:17:20 +07: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 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 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
Max 4813152691 Enable SMS-related log in VLR tests
The likely reason why it was disabled is due to
paging_cb_mmsms_est_req() logging pointers which results in unstable log
output. Fixing this allows us to track SMS-related regressions properly.

Change-Id: I44ae817d9edb73d182ff33ff5a2fd942e224e344
2019-01-16 12:56:30 +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 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
Vadim Yanitskiy 24e025e3e2 libmsc/gsm_04_11.c: refactor MT SMS message handling
According to GSM TS 04.11, the SMC (Short Message Control) state
machine is a part of CM-sublayer of L3, that is responsible for
connection management (establisment and releasing), and SM-RP
(Relay Protocol) message delivery.

For some reason, the connection establisment request from SMC
(GSM411_MMSMS_EST_REQ) was not handled properly - it was
always assumed that connection is already established.

This is why the code initiating a MT (Mobile Terminated) SMS
transfer had to establish a radio connection with subscriber

Let's benefit from having the SMC state machine, and offload
connection establishment to it. This change makes the local
implementation closer to GSM TS 04.11, and facilitates the
further integration of GSUP transport.

NOTE: the expected unit test output is changed, because now we
always allocate a transaction first, and then establish a
connection, not vice versa.

Change-Id: I4a07ece80d8dd40b23da6bb1ffc9d3d745b54092
2018-11-29 02:54:54 +07: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
Vadim Yanitskiy 2760585cca msc_vlr_tests: don't abuse USSD-request to conclude connections
Previously the '*#100#' USSD-request was abused in order to
conclude the current subscriber connection. This makes the unit
tests depend on each other, for example, if one break something
in the GSM 09.11 implementation, a half of tests would fail.

Moreover, the further changes in the GSM 09.11 implementation
will make the results less predictable (i.e. session ID, etc.).
So let's introduce a separate unit test with simple request-
response logic, while more complex tests will be in TTCN.

Change-Id: I40b4caac3113263f5a06c861dff5e10d43c319b5
2018-07-29 16:22:06 +02:00
Vadim Yanitskiy 10c6419798 libmsc/ussd.c: use connection ref-counting and transactions
A subscriber may have a few active transactions at the same time.
For example, one can receive SMS messages during a call, or during
an active SS/USSD session.

We already have connection ref-counting and transactions for CC
and SMS, so let's also use both for SS/USSD.

Change-Id: I21c6777cb88f1f4f80f75dcd39734e952bd4e8b0
2018-06-10 22:28:40 +07:00
Vadim Yanitskiy 7d7ee427b3 tests/msc_vlr: fix expected SS message names
Since the I697639d8469e5dda617b27995c4a92e1f0c0bead, call
independent SS messages are also supported by

So, instead of 'NCSS:0x3b' it will return 'GSM0480_MTYPE_REGISTER'.
Let's correct the expected message names.

Change-Id: If9e854ee84882d104cf2ffaceb3862fda6862f19
2018-04-17 19:28:55 +07: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 12e17be1a0 cosmetic: msc_vlr_tests: enable CC logging in debug
There are a number of bad failures in CC teardown handling we're solving. It
helps to see CC logging in the msc_vlr_tests.

Change-Id: I56ac269d46b48b6b85efad81c4d2343bfc41ea90
2018-03-15 14:24:57 +00:00
Neels Hofmeyr fe718bc760 cosmetic: vlr_auth: log decision to send UMTS or GSM AKA challenge
Also indicate in msc_vlr_test_gsm_authen.c that we're indeed sending no
capability to do R99 in the Classmark 1 during LU request.

Change-Id: Id79a77ca1f218d55dad21d9dd3de92445fb5d6bf
2018-03-15 14:24:57 +00:00
Neels Hofmeyr a9099bc99a cosmetic: vlr_auth_fsm: log RAN and size along with SRES/RES
Change-Id: Ib0f9f573ffac2302fbd3ee28f48ccd8fce5fe286
2018-03-10 22:23:13 +01:00
Neels Hofmeyr 11d2ce3e34 cosmetic: vlr_auth_fsm: clarify decision on UMTS AKA or GSM AKA
The code deciding on whether UMTS AKA is used was cascaded and convoluted. By
flattening the decisions, they become easier to read and possibly catch more
weird corner cases / log information more clearly.

- First decide what AKA the RES length reflects.
- Then decide whether all prerequisites for UMTS AKA are satisfied.
- Finally, on UTRAN, turn down the auth if we don't have UMTS AKA, and neatly
  log all of the potential causes.

One corner case that should never occur is that the UMTS AKA RES length is
actually the same length as the GSM AKA SRES. If this nevertheless occurs, log
this as an error, though not turning down authentication because of it. (The
effect is that we would favor UMTS AKA when it has a res_len == sizeof(sres)
and would not succeed to GSM AKA. At least the log will tell us why, now.)

Adjust an expected test output, trivial logging difference.

Change-Id: I43f7f301ea85e518bac91f707391a53182e54fab
2018-03-10 22:23:13 +01:00
Neels Hofmeyr 31adcae654 msc_vlr_test_umts_authen: test response with only SRES half of RES
Change-Id: I0e9099625bd9d3de3db5ee29fbf81b2d8a30071d
2018-03-10 22:23:13 +01:00
Neels Hofmeyr c6d20dd5a2 msc_vlr_test_umts_authen: test response with too long RES
Change-Id: Ie5473f06fc2d04c6a9f343da5764ec95b292a5f9
2018-03-10 22:23:13 +01:00
Neels Hofmeyr 15ed426df2 msc_vlr_test_umts_authen: test response with too short RES
Change-Id: Ia1bc57b3dc1f3c3c654ba2d907b16ba925cd03e8
2018-03-10 22:23:13 +01:00
Neels Hofmeyr d97821f8e5 cosmetic: gsm48_rx_mm_auth_resp(): log 'UMTS AUTH', not 'R99 AUTH'
Change-Id: Iba43c685cbe238d96175267e9cc954b2f2f3e7fc
2018-03-10 22:22:56 +01:00
Neels Hofmeyr dbabfd3c43 msc_vlr_tests: clearly separate Ciph Mode from Security Mode checking
Clearly distinguish between Ciphering Mode Command on GERAN and Security Mode
Control on UTRAN.

Cosmetic: explicitly verify the key strings in the testing code (not only in
the expected output).

Change-Id: Ica93ed06c4c63dc6768736d25231de8068001114
2018-03-10 20:58:20 +00:00
Neels Hofmeyr da21a52c92 msc_vlr_tests: improve cipher mode coverage
Actually call msc_vlr_set_ciph_mode() and wrap away a_iface_tx_cipher_mode()
and ranap_iu_tx_sec_mode_cmd(). Hence we'll see decisions and errors in
msc_vlr_set_ciph_mode() as well.

Change-Id: Id23bc245d4b5707edcd27c44db272fbb211bf9bd
2018-03-02 17:00:37 +01: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 71c51df07d Shift ciphering algorithm selection from VLR to MSC
The VLR code seems to have the assumption that there is one particular
algorithm to be used, as opposed to one of a set of algorithms.

What's missing is basically to decide when/where to pick the best
algorithm within the capabilities of the phone (classmark) and the
network configuration (net->a5_encryption_mask).  So far, libvlr has no
notion of classmark.  Rather, libmsc has.

Why does the VLR care about the particular algorithm at all?  The VLR
should probably simply decide if it should use encryption or not, and if
so, the MSC will figure which algorithm to use.

Change-Id: I5ed80ca2086560a5975a758ec568a034a9a8ab89
2018-01-28 00:09:41 +00: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 4cf4fddf28 vlr: debug log: log Ciphering Mode details
Change-Id: Ib19dfd7255bda01ebace62386df4ec89697d9d14
2017-12-18 03:48:24 +01:00