aboutsummaryrefslogtreecommitdiffstats
path: root/src/libmsc/msc_a.c
AgeCommit message (Collapse)AuthorFilesLines
2021-06-24improve logging on encryption, for Ciphering and HOneels/a54Neels Hofmeyr1-2/+6
log the algorithm and all keys instead of just Kc. Change-Id: If7871dedda2b1fb115e6f00da1379ff2e3d68a10
2021-06-24support A5/4 in Cipher Mode CommandNeels Hofmeyr1-1/+9
Related: SYS#5324 Change-Id: I780a739b9bfbefd4f58be051794fe1a491823e67
2021-06-06msc_tx_common_id(): fix potential NULL pointer dereferenceVadim Yanitskiy1-0/+2
Reported by GCC 11.1.0. msc_a_vsub() may return NULL. Change-Id: Iebdd6399e819a03258398e6b7b453bda37e45a20
2021-06-04Use new osmo stat items/ctr APIsPau Espin Pedrol1-9/+3
Generated using several semantinc patches with spatch. Change-Id: I3ee853539949a763a309856bf2e7196415b23741
2021-04-29Fill Last Used E-UTRAN PLMN Id when in CSFBPau Espin Pedrol1-0/+5
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
2020-07-28Clear Command: set cause value to "Call Control"Neels Hofmeyr1-0/+3
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
2020-06-24propagate Compl L3 Info Cell ID to the VLR subscriber recordNeels Hofmeyr1-0/+6
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
2020-06-24add comments to clarify some complete l3 detailsNeels Hofmeyr1-0/+2
Change-Id: I6e289900d38d97c346d615b71d36656254e6f2b5
2020-06-22msc_a: add callref as call id to ASSIGNMENT REQ.Philipp Maier1-0/+2
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
2020-06-19use new osmo_mobile_identity API everywhereNeels Hofmeyr1-2/+2
Depends: Ic3f969e739654c1e8c387aedeeba5cce07fe2307 (libosmocore) Change-Id: Idfc8e576e10756aeaacf5569f6178068313eb7ea
2019-11-28msc_a CC: add some basic sanity testsNeels Hofmeyr1-0/+10
Change-Id: I9d7d7d4073282abc6c02a6a297c807dc70c5154c
2019-11-28fail on invalid RTP address from MGWNeels Hofmeyr1-0/+6
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
2019-11-19Fix some typosMartin Hauke1-2/+2
Fix typos and common misspellings in code comments and log messages. Change-Id: Ie66b89065f2100c1d2125ce5a6c9b1d58df7c8ad
2019-11-01CC: add error handling for CRCX responsesNeels Hofmeyr1-3/+3
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
2019-10-21log which DTAP messages are sent to RANNeels Hofmeyr1-2/+5
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-09-18fix error on BSSMAP Cipher Mode Complete L3 msg IENeels Hofmeyr1-0/+12
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
2019-09-03msc_a fsm: ignore state chg to same stateNeels Hofmeyr1-2/+8
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
2019-09-02msc_a.c, CC trans: change a comment to a debug logNeels Hofmeyr1-1/+1
Change-Id: I5a3cc6219080910119b0c9ff11fc2b9eb96a06e5
2019-08-29fix segfault: don't send CC REL on NULL msc_aNeels Hofmeyr1-0/+9
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
2019-08-19msc_a: switch RAN type back to SGs when a CSFB-Call is clearedPhilipp Maier1-0/+5
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
2019-06-16libmsc/msc_a.c: fix: remove dummy allstate_action of msc_a_fsmVadim Yanitskiy1-13/+0
Since [1] has been merged to libosmocore, it was discovered that the 'msc_a' FSM has a dummy 'allstate_action' handler assigned, but 'allstate_event_mask' is 0x00 at the same time. It basically doesn't make any sense, and moreover does cause warnings and build failures. [1] https://git.osmocom.org/libosmocore/commit/?id=b3f94eb39e19366c3458643ee329a73155d46ff8 [1] https://gerrit.osmocom.org/#/c/libosmocore/+/14361/ Change-Id: Ieb81b7a07ced1c40ba70d2adb0df68160ee62118
2019-05-21Request Osmux CID and forward it in Assign Req and Assign ComplPau Espin Pedrol1-2/+28
Related: OS#2551 Depends: osmo-mgw.git I73b4c62baf39050da81d65553cbea07bc51163de Change-Id: I5b14e34481e890669c9ee02dba81eba84293cebb
2019-05-13libmsc/msc_a.c: fix possible NULL-pointer dereferencesVadim Yanitskiy1-7/+25
Change-Id: Id5c95fbf318a2e51e7ffee2e08ceab3042b26cc9 Fixes: CID#198411, CID#198414
2019-05-12silence error messages about HANDOVER_END not permittedNeels Hofmeyr1-0/+12
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
2019-05-10call_leg: remove unused event MSC_EV_CALL_LEG_RTP_RELEASEDNeels Hofmeyr1-21/+2
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
2019-05-10make msc_a_vsub() and others NULL-safeNeels Hofmeyr1-0/+6
Fixes: coverity CID 198451 Change-Id: Icd146ae512236a09cad080ed3eb85944e8f5cee4
2019-05-08large refactoring: support inter-BSC and inter-MSC HandoverNeels Hofmeyr1-0/+1651
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
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-08 19:42:35 +0000