9 Commits (2aaff7513ba76b6ddacdeced36e37d249c84c5d5)

Author	SHA1	Message	Date
Alexander Couzens	2aaff7513b	Validate the choosen UTRAN encryption algorithm ... 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	1 year ago
Harald Welte	505a94a610	Make UTRAN encryption algorithms configurable ... 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	1 year ago
Harald Welte	274b70f1a8	Fix enabling of UMTS UEA encryption ... 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	1 year ago
Neels Hofmeyr	b697274daa	refactor: move RESET Osmux TLV parsing to ran_msg_a.c ... ran_peer.c is not the proper place to parse messages, because it should be RAN agnostic. All parsing and encoding belongs in ran_msg_a.c and ran_msg_iu.c. Move the Osmux TLV parsing into the is_reset_msg op: add supports_osmux out-parameter (and add a logging fi pointer). To be able to modify msg->l3h, also make the msgb arg non-const. In ranap_is_reset_msg(), always return non-support for Osmux. In bssmap_is_reset_msg(), return 0 if no TLVs were parsed, 1/-1 if an Osmux TLV was present/not present. Update the osmux support flag directly where the ConnectionLess message is received, so that there is only one place responsible for that. Related: OS#4595 Change-Id: I1ad4a3f9356216dd4bf8c48fba29fd23438810a7	3 years ago
Pau Espin	3694631c1a	ran_msg_iu.c: Avoid redefining osmo-iuh global variables ... From ASAn on gcc 10.1.0: +================================================================= +==269368==ERROR: AddressSanitizer: odr-violation (0x559114a5b880): + [1] size=4 'asn1_xer_print' /git/osmo-msc/src/libmsc/ran_msg_iu.c:50:5 + [2] size=4 'asn1_xer_print' /git/osmo-iuh/src/iu_client.c:85:5 +These globals were registered at these points: + [1]: + #0 0x7f6208d3869a in __asan_register_globals /build/gcc/src/gcc/libsanitizer/asan/asan_globals.cpp:341 + #1 0x55911456d221 in _sub_I_00099_1 (/build/new/tmpdir/osmo-msc/tests/msc_vlr/msc_vlr_test_hlr_timeout+0x48d221) + #2 0x5591145e8e9c in __libc_csu_init (/build/new/tmpdir/osmo-msc/tests/msc_vlr/msc_vlr_test_hlr_timeout+0x508e9c) + + [2]: + #0 0x7f6208d3869a in __asan_register_globals /build/gcc/src/gcc/libsanitizer/asan/asan_globals.cpp:341 + #1 0x7f6207d8db91 in _sub_I_00099_1 (/build/new/out/lib/libosmo-ranap.so.3+0x47db91) + #2 0x7f62096eb0f1 in call_init.part.0 (/lib64/ld-linux-x86-64.so.2+0x110f1) + +==269368==HINT: if you don't care about these errors you may set ASAN_OPTIONS=detect_odr_violation=0 +SUMMARY: AddressSanitizer: odr-violation: global 'asn1_xer_print' at /git/osmo-msc/src/libmsc/ran_msg_iu.c:50:5 +==269368==ABORTING Related: OS#4556 Change-Id: I702e9748eaaf2279c3764ba67f80f00ae9f2526f	3 years ago
Neels Hofmeyr	fe5ae8ef5b	log: RANAP encode: use RANAP message names instead of BSSAP ... Change-Id: Ib0e0630d775a28958ea86802f70cbeec07087f91	3 years ago
Vadim Yanitskiy	1c50044efb	libmsc/ran_msg_iu.c: fix: properly handle SAPI IE of RANAP_DirectTransfer ... The RANAP DirectTransfer message may contain an optional SAPI IE. Thanks to our TTCN-3 tests (and Wireshark!), it was discovered that this IE is ignored, so even if the MO SMS related messages arrive on SAPI 3 (as per GSM TS 04.11, section 2.3) OsmoMSC sends MT messages on SAPI 0. In ran_iu_decode_l3() we need to check if the SAPI IE is present, and tag the NAS PDU message buffer with a proper DLCI value. This change makes the failing SMS related test cases pass. Change-Id: I728b55b04e87fc23be6d4f8735e8cad82b6f640e	4 years ago
Harald Welte	4dd150afa3	Iu: Send SMS over SAPI-3 ... After neels/ho was merged, SMS over IuCS/RANAP was failing in both MO and MT direction. The reason was that all mobile-terminated SMS-CP layer messages were sent in RANAP with SAPI-0 instaed of SAPI-1. Change-Id: I98e6eddb52d5c61c4e2d34bdfcd43cf460296ad7 Closes: OS#3993	4 years ago
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	4 years ago