RANAP Security Command can include an encryption IE. If it includes
it the RNC can still ignore it (e.g. unsupported encryption) and
return the Security Command Complete with an choosen encryption IE:
"no encryption".
Validate the encryption element and ensure the encryption is included in
the encryption mask.
Closes: OS#4144
Change-Id: Icfc135c8b8ae862defe7114db492af600c26407f
Allow the user fine-grained control over which UMTS encryption
algorithms are permitted, rather than always permitting UEA1 and UEA2
or neither.
This brings the handling of UEA in line with the handling of A5 for
GERAN.
Change-Id: I91f9e50f9c1439aa19528f887b83ae9de628fcfd
Closes: OS#4144
Depends: osmo-iuh.git I6d2d033b0427bdc84fee61e0f3cb7b29935214bf
The existing code allowed the user to configure UMTS encryption in the
vty, but we never actually passed this information down to RANAP. As a
result, the RAN had no chance of ever enabling encryption on the air
interface.
Change-Id: Ieaaa6b23b7337b7edb902fad8031e195e0c5e9d2
Related: OS#4144
This commit is largely based on work by
Max <msuraev@sysmocom.de>
Adds LCLS parameters for A-interface transactions
This commit also adds a vty option to facilitate globally
disabling LCLS for all calls on this MSC.
Add a global call reference (GCR) to MNCC and therefore
bump the MNCC version to version 8. (This commit has to be
merged at the same time as the corresponing commit in the
osmo-sip-connector for mncc-external use.)
Depends: osmo-sip-connector Id40d7e0fed9356f801b3627c118150055e7232b1
Change-Id: I705c860e51637b4537cad65a330ecbaaca96dd5b
As seen in a running osmo-msc:
"vlr_access_req_fsm.c:153
msc_a(IMSI-....:MSISDN-...:TMSI-0x...:GERAN-A-8:CM_SERVICE_REQ){MSC_A_ST_RELEASING}:
Event MSC_A_EV_CN_CLOSE not permitted"
Also seen in several unit tests, which need update.
The action event handler for that state is actually already
expecting/handling the event by ignoring it, so we should allow it.
Change-Id: I4d30cffab693529aab3ba736419dec116a4dd7ef
Since recently, osmo-bsc behaves strictly as per specs, meaning it will
only send the "Cell selection indicator after release of all TCH and SDCCH IE"
in RR Channel Release iff:
* "Last Used E-UTRAN PLMN Id" was received in the CommonID sent MSC->BSC
* "Last Used E-UTRAN PLMN Id" was received insider "old BSS to new BSS Information"
in the HandoverRequest sent MSC->BSC.
On the other hand, CSFB_Indicator from ClearCommand MSC->BSC is nw
ignored and not taken into account.
Hence, let's update osmo-msc to also behave correctly by sending the
Last Used E-UTRAN PLMN ID at CommonID tx time to avoid regressions in
CSFB support when running against newer osmo-bsc.
Let's keep sending the CSFB Indicator in ClearCommand as we used too, in
order to keep compatibility with older BSCs (as per spec).
Related: SYS#5337
Change-Id: Ic5f175b179973d0a50d94f00e15f5a3e332605fc
So far, by failing to initialize the cause value, we always send a Clear
Command cause == 0, which actually means "Radio Interface Message Failure".
This is seen in all my logged network traces of osmo-msc lab testing.
"Call Control" seems to be the only cause value that remotely fits a normal
release procedure, even if it was not voice call related, see 3GPP TS 48.008
3.2.1.21.
Related: OS#4664
Change-Id: I1347ed72ae7d7ea73a557b866e764819c5ef8c42
As soon as the subscriber is authenticated, update the VLR entry with the
MSC-A's full CGI, including the Cell Id received from the Complete Layer 3
Information.
Thus the Cell Id will be shown by vty 'show subscriber cache' and 'show
connection'.
This is tested by osmo-ttcn3-hacks Ie410714a96353f74a52a104c56fa0a08683e0004.
Related: OS#4627
Change-Id: Iee1781985fb25b21ce27526c6a3768bf70d4dc9a
The BSSMAP message ASSIGNMENT REQUEST may contain an optional CALL
IDENTIFIER IE. While this IE is optional some BSC implementions may
require it.
Change-Id: I4288f47e4a6d61ec672f431723f6e72c7c6b0799
Related: OS#4582
When the CRCX OK returns an invalid RTP address, abort the call; fixes
MSC_Tests.TC_invalid_mgcp_crash.
The original crash happened when adding this error handling without this commit
I08c03946605aa12e0a5ce8b3c773704ef5327a7a ("fsm: use deferred deallocation" for
osmo-mgw I7df2e9202b04e7ca7366bb0a8ec53cf3bb14faf3 "fix use-after-free: require
new fsm deferred dealloc, check for term"). With this error handling added,
even though avoiding a crash, the test does not pass yet, because instead of
rejecting the call, it currently composes an Assignment Command without a
Transport Layer Address. Fix that.
Change-Id: I00c3b5ff74c05bcc2b7c39375c33419916a57193
Fix three 'FIXME: ERROR HANDLING' occurences in the code that reacts upon the
MGW providing (or failing to provide) an RTP port for the RAN side. From an
earlier stage of the code, the cleanup for this situation was extremely
complex, and hence the choice was to simply wait for the call to time out and
fail. But since we have implemented safe deallocation of nested FSMs in
libosmocore, the situation has become rather trivial: simply free the CC
transactions, and all the rest will immediately release, and terminate
correctly without crashing.
A ttcn3 test for this is MSC_Tests:TC_invalid_mgcp_crash, which actually also
needs the change to osmo_sockaddr_str_is_nonzero() in preceding patch
I53ddb19a70fda3deb906464e1b89c12d9b4c7cbd, so that a seemingly valid MGCP
message ends up causing a failure in the on_success() branch of
mgcp_client_endpoint_fsm.c.
Change-Id: I8313bed1d782100bebeac7d8fc040557c4cb653e
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
When an MS returns the IMEISV in the BSSMAP Cipher Mode Complete message in
the Layer 3 Message Contents IE, do not re-invoke the decode_cb() a second
time, but instead point to it from the ran_msg.cipher_mode_complete struct.
When the MSC-A decodes the Ciphering Mode Complete message, it always wants to
also decode the enclosed DTAP from the Layer 3 Message Contents IE. However,
when the MSC-I preliminarily decodes messages, it often just wants to identify
specific messages without fully acting on them, let alone dispatching RAN_UP_L2
events more than once. So leave it up to the supplied decode_cb passed to
ran_dec_l2() implementations to decide whether to decode the DTAP.
In msc_a.c hence evaluate the DTAP by passing a msgb to msc_a_up_l3(), which
will evaluate the RR Ciphering Mode Complete message found in the BSSMAP Cipher
Mode Complete's Layer 3 Message Contents IE.
Particularly, the previous choice of calling the decode_cb a second time for
the enclosed DTAP caused a header/length parsing error: the second decode_cb
call tried to mimick DTAP by overwriting the l3h pointer and truncating the
length of the msgb, but subsequently ran_a_decode_l2() would again derive the
l3h from the l2h, obliterating the intended re-interpretation as DTAP, and
hence the previous truncation caused error messages on each and every Cipher
Mode Complete message, like:
DBSSAP ERROR libmsc/ran_msg_a.c:764 msc_a(IMSI-26242340300XXXX:MSISDN-XXXX:TMSI-0xA73E055A:GERAN-A-77923:LU)[0x5563947521e0]{MSC_A_ST_AUTH_CIPH}: RAN decode: BSSMAP: BSSMAP data truncated, discarding message
This error was seen a lot at CCCamp2019.
Modifying the msgb was a bad idea to begin with, the approach taken in this
patch is much cleaner.
Note that apparently many phones include the IMEISV in the Cipher Mode Complete
message even though the BSSMAP Cipher Mode Command did not include the Cipher
Response Mode IE. So, even though we did not specifically ask for the Cipher
Mode Complete to include any identity, many MS default to including the IMEISV
of their own accord. Reproduce: attach to osmo-msc with ciphering enabled using
a Samsung Galaxy S4mini.
Related: OS#4168
Change-Id: Icd8dad18d6dda24d075dd8da72c3d6db1302090d
We sometimes see errors like
libmsc/msc_a.c:361 msc_a(...){MSC_A_ST_RELEASING}: transition to state MSC_A_ST_RELEASING not permitted!
i.e. changing state to the state msc_a is already in.
Ignore re-entering the same state for most state changes. However, there is one
state change in msc_a where re-entering the MSC_A_ST_VALIDATE_L3 is necessary
to start the timeout.
Hence add msc_a_state_chg_always() and use that for re-entering
MSC_A_ST_VALIDATE_L3. Change msc_a_state_chg() to skip no-op state changes.
This should silence all no-op state change error messages for msc_a.
Related: OS#4169
Change-Id: I0c74c10b5fa7bbdd6ae3674926cc0393edf15a35
Apparently, if a conn disappears during an ongoing call, the CC code tried to
send a CC REL on a NULL msc_a during cleanup, which lead to a crash
(cccamp2019). Guard against that.
Crash:
#0 msc_a_tx_dtap_to_i (msc_a=0x0, dtap=0x55a4bf2fa0f0) at ../../../../src/osmo-msc/src/libmsc/msc_a.c:1565
#1 0x000055a4be1bb03c in trans_tx_gsm48 (trans=0x55a4bf2d52a0, trans=0x55a4bf2d52a0, trans=0x55a4bf2d52a0, msg=<optimized out>)
at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:82
#2 gsm48_cc_tx_release (trans=trans@entry=0x55a4bf2d52a0, arg=arg@entry=0x7ffdd731a0e0) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:1101
#3 0x000055a4be1bee65 in _gsm48_cc_trans_free (trans=trans@entry=0x55a4bf2d52a0) at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:278
#4 0x000055a4be1ab654 in trans_free (trans=trans@entry=0x55a4bf2d52a0) at ../../../../src/osmo-msc/src/libmsc/transaction.c:170
#5 0x000055a4be1bd091 in mncc_tx_to_gsm_cc (net=<optimized out>, msg=msg@entry=0x55a4bf2d3b68)
at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:1971
#6 0x000055a4be1bf1e5 in mncc_tx_to_cc (net=<optimized out>, arg=arg@entry=0x55a4bf2d3b68)
at ../../../../src/osmo-msc/src/libmsc/gsm_04_08_cc.c:2049
#7 0x000055a4be18ed63 in mncc_sock_read (bfd=0x55a4bf2563b8, bfd=0x55a4bf2563b8) at ../../../../src/osmo-msc/src/libmsc/mncc_sock.c:121
#8 mncc_sock_cb (bfd=0x55a4bf2563b8, flags=1) at ../../../../src/osmo-msc/src/libmsc/mncc_sock.c:189
#9 0x00007fcfad607ce1 in osmo_fd_disp_fds (_eset=0x7ffdd731a9a0, _wset=0x7ffdd731a920, _rset=0x7ffdd731a8a0)
at ../../../src/libosmocore/src/select.c:223
#10 osmo_select_main (polling=<optimized out>) at ../../../src/libosmocore/src/select.c:263
#11 0x000055a4be17dd56 in main (argc=3, argv=<optimized out>) at ../../../../src/osmo-msc/src/osmo-msc/msc_main.c:723
Change-Id: Ia1bb0410ad0618c182a5f6da06af342b6d483eff
When a CSFB call is over the MS changes back to LTE after the call is
cleared. However, at the moment the MSC does not change the
cs.attached_via_ran flag. This may cause problems with the next call. Lets
make sure that if there is an SGs association present, the ran type is
set back to SGs when the call is cleared.
Related: SYS#4624
Change-Id: I104adecb0645b81b90ee230c57bf8b463c9e7045
The MSC_A_EV_HANDOVER_END exists as parent term event for the msc_ho_fsm, but
it is not actually required as functional event, since all cleanup is handled
in msc_ho_fsm_cleanup().
That's why I never bothered to add the event to msc_a_fsm, but of course that
means we get an error message after each (successful and unsuccessful)
handover, that the MSC_A_EV_HANDOVER_END is not permitted.
Allow the event and ignore it to silence the error message.
Explain in a comment.
Change-Id: Ie8dc0c0a631b7da43111f329562007766a21b134
The event is actually never dispatched and useless, because when an RTP stream
releases, the call_leg terminates directly anyway (which wasn't apparent when
starting to design the call_leg FSM yet).
Change-Id: I6b2fc1225c960fa2f7c46adf241520217a07821c
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
Alexander Couzens
Harald Welte
Keith Whyte
Pau Espin
Vadim Yanitskiy
Philipp Maier
Martin Hauke