Commit Graph

70 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 0ec7b23ee3 msc_vlr_test_gsm_ciph.c: fix IMEISV MI: even number of digits, clear odd bit
There is an invalid Mobile Identity in the msc_vlr_test_gsm_ciph test data.
This became apparent when applying the new osmo_mobile_identity API (in a
following patch). Current Mobile Identity API ignores the error.

Change-Id: Ib1d54c59acc8b716de471ca275f54f9d22da3574
2020-06-15 03:14:03 +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
Martin Hauke 3f07daceef Fix some typos
Fix typos and common misspellings in code comments and log messages.

Change-Id: Ie66b89065f2100c1d2125ce5a6c9b1d58df7c8ad
2019-11-19 01:04:34 +00: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 38816dab97 log, cosmetic: add "RR" to "Ciphering Mode Complete"
Distinguish the enclosed DTAP RR Ciphering Mode Complete message from the outer
BSSMAP Cipher Mode Complete message in the DEBUG log.

Change-Id: I80c69b491e2ddb932bc4295a01caaf6a903b1fe4
2019-09-02 11:06:05 +02:00
Neels Hofmeyr 364f927ac4 vlr_lu_fsm: ignore ID_IMEISV during VLR_ULA_S_WAIT_HLR_UPD
Change-Id: I2ea4f46efa013671d93892cb07bf830393289150
2019-08-29 05:42:02 +00: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
Oliver Smith b8077b0c1d vlr: when setting IMEISV, also set IMEI
Copy IMEISV to IMEI when IMEISV changes. The additional SV digits will
get cut off then. This is needed for the subscriber on demand use case,
since we can get the IMEISV early (see [1]), but need to send the IMEI
to the Check IMEI procedure.

While adjusting the tests, I have noticed that there are code paths
where we ask the MS for the IMEISV first, and later ask the MS for the
IMEI, although we already have the IMEISV. This could be improved in a
future patch.

[1] Change-Id I256224194c3b8caf2b58a88d11dccd32c569201f

Related: OS#2542
Change-Id: I02e7b66848bf7dddb31b105e2ae981432817ae1e
2019-05-15 10:57:43 +02:00
Oliver Smith d103705f01 vlr: fix IMEI length
Set the length of vlr_subscr->imei to
	GSM23003_IMEI_NUM_DIGITS_NO_CHK (14)
instead of
	GSM23003_IMEISV_NUM_DIGITS (16).

Note that there is also GSM23003_IMEI_NUM_DIGITS (15), which includes
an additional checksum digit. This digit is not intended for digital
transmission, so we don't need to store it. Also by not storing it, we
can simply copy the IMEI-part from the IMEISV to the IMEI without
worrying about the checksum (will be done in a follow up patch).

A good overview of the IMEI/IMEISV structure is here:
https://en.wikipedia.org/wiki/International_Mobile_Equipment_Identity#Structure_of_the_IMEI_and_IMEISV_(IMEI_software_version)

Related: OS#2542
Change-Id: Iaf2569c099874b55acbd748b776394726cc5ce54
2019-05-15 08:53:22 +00: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
roles.

Compared to inter-MSC Handover, mere inter-BSC has the obvious simplifications:
- all of MSC-A, MSC-I and MSC-T roles will be served by the same osmo-msc
  instance,
- messages between MSC-A and MSC-{I,T} don't need to be routed via E-interface
  (GSUP),
- no call routing between MSC-A and -I via MNCC necessary.

This is the largest code bomb I have submitted, ever. Out of principle, I
apologize to everyone trying to read this as a whole. Unfortunately, I see no
sense in trying to split this patch into smaller bits. It would be a huge
amount of work to introduce these changes in separate chunks, especially if
each should in turn be useful and pass all test suites. So, unfortunately, we
are stuck with this code bomb.

The following are some details and rationale for this rather huge refactoring:

* separate MSC subscriber management from ran_conn

struct ran_conn is reduced from the pivotal subscriber management entity it has
been so far to a mere storage for an SCCP connection ID and an MSC subscriber
reference.

The new pivotal subscriber management entity is struct msc_a -- struct msub
lists the msc_a, msc_i, msc_t roles, the vast majority of code paths however
use msc_a, since MSC-A is where all the interesting stuff happens.

Before handover, msc_i is an FSM implementation that encodes to the local
ran_conn. After inter-MSC Handover, msc_i is a compatible but different FSM
implementation that instead forwards via/from GSUP. Same goes for the msc_a
struct: if osmo-msc is the MSC-I "RAN proxy" for a remote MSC-A role, the
msc_a->fi is an FSM implementation that merely forwards via/from GSUP.

* New SCCP implementation for RAN access

To be able to forward BSSAP and RANAP messages via the GSUP interface, the
individual message layers need to be cleanly separated. The IuCS implementation
used until now (iu_client from libosmo-ranap) did not provide this level of
separation, and needed a complete rewrite. It was trivial to implement this in
such a way that both BSSAP and RANAP can be handled by the same SCCP code,
hence the new SCCP-RAN layer also replaces BSSAP handling.

sccp_ran.h: struct sccp_ran_inst provides an abstract handler for incoming RAN
connections. A set of callback functions provides implementation specific
details.

* RAN Abstraction (BSSAP vs. RANAP)

The common SCCP implementation did set the theme for the remaining refactoring:
make all other MSC code paths entirely RAN-implementation-agnostic.

ran_infra.c provides data structures that list RAN implementation specifics,
from logging to RAN de-/encoding to SCCP callbacks and timers. A ran_infra
pointer hence allows complete abstraction of RAN implementations:

- managing connected RAN peers (BSC, RNC) in ran_peer.c,
- classifying and de-/encoding RAN PDUs,
- recording connected LACs and cell IDs and sending out Paging requests to
  matching RAN peers.

* RAN RESET now also for RANAP

ran_peer.c absorbs the reset_fsm from a_reset.c; in consequence, RANAP also
supports proper RESET semantics now. Hence osmo-hnbgw now also needs to provide
proper RESET handling, which it so far duly ignores. (TODO)

* RAN de-/encoding abstraction

The RAN abstraction mentioned above serves not only to separate RANAP and BSSAP
implementations transparently, but also to be able to optionally handle RAN on
distinct levels. Before Handover, all RAN messages are handled by the MSC-A
role.  However, after an inter-MSC Handover, a standalone MSC-I will need to
decode RAN PDUs, at least in order to manage Assignment of RTP streams between
BSS/RNC and MNCC call forwarding.

ran_msg.h provides a common API with abstraction for:

- receiving events from RAN, i.e. passing RAN decode from the BSC/RNC and
  MS/UE: struct ran_dec_msg represents RAN messages decoded from either BSSMAP
  or RANAP;
- sending RAN events: ran_enc_msg is the counterpart to compose RAN messages
  that should be encoded to either BSSMAP or RANAP and passed down to the
  BSC/RNC and MS/UE.

The RAN-specific implementations are completely contained by ran_msg_a.c and
ran_msg_iu.c.

In particular, Assignment and Ciphering have so far been distinct code paths
for BSSAP and RANAP, with switch(via_ran){...} statements all over the place.
Using RAN_DEC_* and RAN_ENC_* abstractions, these are now completely unified.

Note that SGs does not qualify for RAN abstraction: the SGs interface always
remains with the MSC-A role, and SGs messages follow quite distinct semantics
from the fairly similar GERAN and UTRAN.

* MGW and RTP stream management

So far, managing MGW endpoints via MGCP was tightly glued in-between
GSM-04.08-CC on the one and MNCC on the other side. Prepare for switching RTP
streams between different RAN peers by moving to object-oriented
implementations: implement struct call_leg and struct rtp_stream with distinct
FSMs each. For MGW communication, use the osmo_mgcpc_ep API that has originated
from osmo-bsc and recently moved to libosmo-mgcp-client for this purpose.
Instead of implementing a sequence of events with code duplication for the RAN
and CN sides, the idea is to manage each RTP stream separately by firing and
receiving events as soon as codecs and RTP ports are negotiated, and letting
the individual FSMs take care of the MGW management "asynchronously". The
caller provides event IDs and an FSM instance that should be notified of RTP
stream setup progress. Hence it becomes possible to reconnect RTP streams from
one GSM-04.08-CC to another (inter-BSC Handover) or between CC and MNCC RTP
peers (inter-MSC Handover) without duplicating the MGCP code for each
transition.

The number of FSM implementations used for MGCP handling may seem a bit of an
overkill. But in fact, the number of perspectives on RTP forwarding are far
from trivial:
- an MGW endpoint is an entity with N connections, and MGCP "sessions" for
  configuring them by talking to the MGW;
- an RTP stream is a remote peer connected to one of the endpoint's
  connections, which is asynchronously notified of codec and RTP port choices;
- a call leg is the higher level view on either an MT or MO side of a voice
  call, a combination of two RTP streams to forward between two remote peers.

  BSC                 MGW                PBX
                CI          CI
                [MGW-endpoint]
  [--rtp_stream--]          [--rtp_stream--]
  [----------------call_leg----------------]

* Use counts

Introduce using the new osmo_use_count API added to libosmocore for this
purpose. Each use token has a distinct name in the logging, which can be a
globally constant name or ad-hoc, like the local __func__ string constant.  Use
in the new struct msc_a, as well as change vlr_subscr to the new osmo_use_count
API.

* FSM Timeouts

Introduce using the new osmo_tdef API, which provides a common VTY
implementation for all timer numbers, and FSM state transitions with the
correct timeout. Originated in osmo-bsc, recently moved to libosmocore.

Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore)
         Ib9af67b100c4583342a2103669732dab2e577b04 (libosmocore)
	 Id617265337f09dfb6ddfe111ef5e578cd3dc9f63 (libosmocore)
	 Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5 (libosmo-sccp)
	 I26be5c4b06a680f25f19797407ab56a5a4880ddc (osmo-mgw)
	 Ida0e59f9a1f2dd18efea0a51680a67b69f141efa (osmo-mgw)
	 I9a3effd38e72841529df6c135c077116981dea36 (osmo-mgw)
Change-Id: I27e4988e0371808b512c757d2b52ada1615067bd
2019-05-08 17:02:32 +02:00
Neels Hofmeyr 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
Harald Welte 390d140b56 a_iface: Fix hexdumping of N-DATA.req
For some reason the existing code was using msgb_hexdump_l2() while the
L2 header is not used by the BSSAP transmit code.  Let's fix this.

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

Change-Id: I6159ea72cc8e0650eda6c49544acd65e9c15e817
2019-02-18 13:52:05 +01:00
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
Oliver Smith 7d05309e3a VLR: send CHECK-IMEI to EIR/HLR
When check-imei-req is enabled in the VTY config, do not accept IMEIs
sent by the ME directly anymore. Send the IMEI to the EIR/HLR and wait
for its ACK or NACK.

OsmoHLR also accepts all IMEIs at this point, but this allows to
optionally store the IMEI in the HLR DB.

Depends: Ib240474b0c3c603ba840cf26babb38a44dfc9364 (osmo-hlr)
Related: OS#3733
Change-Id: Ife868ed71c36cdd02638072abebf61fc949080a7
2019-01-16 10:42:56 +00: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:

  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
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
expectations.

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 ==
false.

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.

Also:

- 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
manually.

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
Neels Hofmeyr 3117b701c8 A5/n Ciph: request Classmark Update if missing
When the VLR requests a Ciphering Mode with vlr_ops.set_ciph_mode(), and if we
need a ciph algo flag from a Classmark information that is not yet known
(usually CM 2 during LU), send a BSSMAP Classmark Request to get it.

To manage the intermission of the Classmark Request, add
- msc_classmark_request_then_cipher_mode_cmd(),
- state SUBSCR_CONN_S_WAIT_CLASSMARK_UPDATE,
- event SUBSCR_CONN_E_CLASSMARK_UPDATE.

From state AUTH_CIPH, switch to state WAIT_CLASSMARK_UPDATE. Once the BSSMAP
Classmark Response, is received, switch back to SUBSCR_CONN_S_AUTH_CIPH and
re-initiate Ciphering Mode.

To be able to re-enter the Ciphering Mode algo decision, factor it out into
msc_geran_set_cipher_mode().

Rationale:

In the following commit, essentially we stopped supporting A5/3 ciphering:

commit 71330720b6
"MSC: Intersect configured A5 algorithms with MS-supported ones"
Change-Id: Id124923ee52a357cb7d3e04d33f585214774f3a3

A5/3 was no longer supported because from that commit on, we strictly checked
the MS-supported ciphers, but we did not have Classmark 2 available during
Location Updating.

This patch changes that: when Classmark 2 is missing, actively request it by a
BSSMAP Classmark Request; continue Ciphering only after the Response. Always
request missing Classmark, even if a lesser cipher were configured available.

If the Classmark Update response fails to come in, cause an attach failure.
Instead, we could attempt to use a lesser cipher that is also enabled. That is
left as a future feature, should that become relevant. I think it's unlikely.

Technically, we could now end up requesting a Classmark Updating both during LU
(vlr_lu_fsm) and CM Service/Paging Response (proc_arq_fsm), but in practice the
only time we lack a Classmark is: during Location Updating with A5/3 enabled.
A5/1 support is indicated in CM1 which is always available, and A5/3 support is
indicated in CM2, which is always available during CM Service Request as well
as Paging Response. So this patch has practical relevance only for Location
Updating. For networks that permit only A5/3, this patch fixes Location
Updating. For networks that support A5/3 and A5/1, so far we always used A5/1
during LU, and after this patch we request CM2 and likely use A5/3 instead.

In msc_vlr_test_gsm_ciph, verify that requesting Classmark 2 for A5/3 works
during LU. Also verify that the lack of a Classmark Response results in attach
failure.

In msc_vlr_test_gsm_ciph, a hacky unit test fakes a situation where a CM2 is
missing during proc_arq_fsm and proves that that code path works, even though
the practical relevance is currently zero. It would only become interesting if
ciphering algorithms A5/4 and higher became relevant, because support of those
would be indicated in Classmark 3, which would always require a Classmark
Request.

Related: OS#3043
Depends: I4a2e1d3923e33912579c4180aa1ff8e8f5abb7e7 (libosmocore)
Change-Id: I73c7cb6a86624695bd9c0f59abb72e2fdc655131
2018-09-17 02:08:07 +02:00
Neels Hofmeyr d28ea6c8c3 msc_vlr_tests: cosmetically tweak perm algo printing
In the msc_vlr_tests, instead of printing the algo IDs, rather print the
corresponding A5/n name, for clarity.

Change-Id: Ic00f1e54490650bcb40170647b8ffd52ede23fd3
2018-09-17 01:19:12 +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.

Rationale:

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
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
gsm48_pdisc_msgtype_name().

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
MT.

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
release.

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
Refactor:

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.

Details:

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
  itself.

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
release.

(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
value.

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 a7fd88ce1b msc_vlr_tests: add test_a5_3_not_supported
See also change-id I72a1dbb30e0a39dbf4b81c7e378d5607b62e10d3 in
osmo-ttcn3-hacks.git, which adds a similar test to the MSC_Tests.ttcn suite.

Writing this test helped me fix the issue faster, why not keep it now that it's
there.

Related: OS#2947
Change-Id: Iba56556207cf6e79e6531b0e7dd3eaec28fb5eaa
2018-03-10 23:21:34 +01: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 7795a19ced vlr: fix GSM AKA in a UMTS AKA capable environment
Switch by vsub->sec_ctx to use the proper Kc for ciphering.

Even on an R99 capable MS with a UMTS AKA capable USIM, the MS may still choose
to only perform GSM AKA, as long as the bearer is GERAN. The VLR already stores
whether the MS replied with a GSM AKA SRES or a UMTS AKA RES in vsub->sec_ctx.
So far, though, we were always using the UMTS AKA Kc just because the USIM and
core net are capable of it, ignoring the choice the MS might have made in the
Authentication Response.

In msc_vlr_test_gsm_ciph, fix the test expectations to the correct GSM AKA Kc
keys, showing that all of LU, CM Service Request and Paging Response now
support MS choosing GSM AKA in a UMTS capable environment.

Related: OS#2793
Change-Id: I42ce51ae979f42d173a45ae69273071c426bf97c
2018-03-10 20:58:24 +00:00