aboutsummaryrefslogtreecommitdiffstats
path: root/src/libmsc/gsm_04_08.c
AgeCommit message (Collapse)AuthorFilesLines
2022-05-04fix crash on CM Serv Rej: fix use count mismatchNeels Hofmeyr1-5/+18
With comments, clarify the code paths where a CM Service use count has not yet been placed on the conn (just send CM Service Reject) and where the use count is placed (decrement count on CM Service Reject). Place the CM Service use count slightly earlier: - it is then correctly present when checking the mobile identity in cm_serv_reuse_conn(), avoiding the crash reported in OS#5532. - there is only one place incrementing the use count instead of two. Related: OS#5532 Change-Id: I6c735b79b67108bcaadada3f01c7046e262f939b
2021-11-27libmsc/gsm_04_08: refactor require ciphering into an own functionAlexander Couzens1-4/+4
Make it more readable. Change-Id: I9e407f65b282e645feabe714f7f4c3e44fae21e9
2021-11-17utran: use new UTRAN encryption enumAlexander Couzens1-4/+5
Depends: libosmocore.git I4b9baff2c2fbd0e339fc769cc69cce58d3a72cdf Change-Id: If6978d7ed1a78facc2591cfc30fda2721629bffa
2021-11-05Make UTRAN encryption algorithms configurableHarald Welte1-4/+4
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
2021-07-29implement CM Re-Establish for voice callsNeels Hofmeyr1-2/+115
Related: SYS#5130 Change-Id: I6fa37d6ca9fcb1637742b40e37b68d67664c9b60
2021-06-04Use new osmo stat items/ctr APIsPau Espin Pedrol1-4/+4
Generated using several semantinc patches with spatch. Change-Id: I3ee853539949a763a309856bf2e7196415b23741
2021-04-29Fill Last Used E-UTRAN PLMN Id when in CSFBPau Espin Pedrol1-1/+8
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-09-25gsm_04_08: check return code of osmo_mobile_identity_decode_from_l3()Philipp Maier1-1/+6
The function gsm48_rx_cm_reest_req() is the only one where the return code of osmo_mobile_identity_decode_from_l3() is not checked, lets check it here too. Change-Id: I37981205870b094b3a40a20197461208daa62698 Fixes: CID#211037
2020-08-24fix crash for unknown MI during Paging ResponseNeels Hofmeyr1-1/+6
Related: OS#4724 Related: I40496bbccbbd9c496cfa57df49e26f124a2b1554 (osmo-ttcn3-hacks) Change-Id: Ia2c8fa745cfab17ed7114d433f625ddc02ae7b11
2020-06-24add comments to clarify some complete l3 detailsNeels Hofmeyr1-1/+7
Change-Id: I6e289900d38d97c346d615b71d36656254e6f2b5
2020-06-19use new osmo_mobile_identity API everywhereNeels Hofmeyr1-130/+113
Depends: Ic3f969e739654c1e8c387aedeeba5cce07fe2307 (libosmocore) Change-Id: Idfc8e576e10756aeaacf5569f6178068313eb7ea
2020-01-27libmsc/gsm_04_08: use DRR in gsm48_rx_rr_pag_resp(), not DMMVadim Yanitskiy1-3/+3
Change-Id: I006c2b4c684dc6b96e98dbb82063a0aa37e33c66
2020-01-27libmsc/gsm_04_08: make use of msc_a in gsm48_rx_rr_app_info()Vadim Yanitskiy1-2/+3
Change-Id: I2a0991c9bbf86b7eb248d74334f9472c56a3c964
2020-01-05libmsc/gsm_04_08.c: fix: verify MI before calling vlr_subscr_rx_id_resp()Vadim Yanitskiy1-0/+36
During the last congress, we have noticed that OsmoMSC crashes on receipt of malformed MM Identity Response messages: BSSAP Message Type: Direct Transfer (0x01) Data Link Connection Identifier 00.. .... = Control Channel: not further specified (0x0) ..00 0... = Spare: 0x0 .... .000 = SAPI: RR/MM/CC (0x0) Length: 11 GSM A-I/F DTAP - Identity Response Protocol Discriminator: Mobility Management messages (5) .... 0101 = Protocol discriminator: Mobility Management messages (0x5) 0000 .... = Skip Indicator: No indication of selected PLMN (0) 01.. .... = Sequence number: 1 ..01 1001 = DTAP Mobility Management Message Type: Identity Response (0x19) Mobile Identity - Format Unknown Length: 8 .... 1... = Odd/even indication: Odd number of identity digits .... .111 = Mobile Identity Type: Unknown (7) <-- This makes OsmoMSC crash [Expert Info (Warning/Protocol): Unknown format 7] [Unknown format 7] [Severity level: Warning] [Group: Protocol] The value '111'B is not a valid Mobile Identity type, and shall be considered as reserved according to 3GPP TS 24.008, section 10.5.1.4. Later on it was discovered that '000'B also crashes OsmoMSC in the same way. The crash itself is provoked by OSMO_ASSERT(0) in vlr_subscr_rx_id_resp(). Let's keep that assert in there, and make sure that: - on receipt of MM Identity Response, Mobile Identity type matches the one in MM Identity Request; - on receipt of RR Ciphering Mode Complete, Mobile Identity contains IMEI(SV) if present. Change-Id: Ica4c90b8eb4d90325313c6eb400fa4a6bc5df825 TTCN-3 test case: I62f23355eb91df2edf9dc837c928cb86b530b743 Fixes: OS#4340
2019-11-19Fix some typosMartin Hauke1-2/+2
Fix typos and common misspellings in code comments and log messages. Change-Id: Ie66b89065f2100c1d2125ce5a6c9b1d58df7c8ad
2019-09-02log, cosmetic: add "RR" to "Ciphering Mode Complete"Neels Hofmeyr1-1/+1
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-08-13add 'encryption uea 1 2' cfg / fix ttcn3 iu testsNeels Hofmeyr1-3/+3
Recently, the ability to run UTRAN without encryption was added, but the config for it was tied to the A5 GERAN encryption configuration. This affected osmo-msc's default behavior of Iu, breaking osmo-msc ttcn3 Iu tests: the ttcn3 test suite sets A5 to 0 (no encryption) but still expects Iu to enable air encryption. Fix this "regression". Add a separate vty config option for UEA encryption, even if it does not provide full granularity to select individual UEA algorithms yet. As a result, Iu default behavior remains to enable encryption regardless of the A5 config. UTRAN encryption can be disabled by the new cfg option "encryption uea 0" alone. Even though the new vty command already allows passing various combinations of the UEA algorithm numbers, only '0' and '1 2' are accepted as valid combinations, to reflect current osmo-msc capabilities. Revert most changes to the msc_vlr test suite in commit "do not force encryption on UTRAN" (I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7): use new net->iu_encryption instead of net->a5_encryption_mask. Adjust/add to test_nodes.vty transcript tests. Related: OS#4144 Change-Id: Ie138f2fcb105533f7bc06a6d2e6deccf6faccc5b
2019-08-05do not force encryption on UTRANNeels Hofmeyr1-3/+3
Remove the conditions that always enable encryption on UTRAN. We so far lack an explicit configuration for UTRAN encryption, and this patch does not add any either. Instead, whether UTRAN encryption is enabled is simply triggered on whether GERAN has A5 encryption enabled (A5/n with n > 0). Though GERAN and UTRAN encryption are not technically related at all, this makes UTRAN behave like GERAN for now, until we implement a proper separate configuration for UTRAN encryption. Adjust the msc_vlr_test_* configuration by setting the net->a5_encryption_mask such that the expected output remains unchanged. A subsequent patch (I54227f1f08c38c0bf69b9c48924669c4829b04b9) will add more tests, particularly cases of UTRAN without encryption. Adjust manual and vty doc. Related: OS#2783 Change-Id: I04ecd7a3b1cc603b2e3feb630e8c7c93fc36ccd7
2019-07-16fix spelling detected by lintianThorsten Alteholz1-3/+3
Change-Id: I01e54b5cf111677079a8ad57645d3ceb7834702a
2019-06-15libmsc/gsm_04_08.c: clean up unused leftover includesVadim Yanitskiy1-13/+0
During the recent refactoring, some code parts has been moved out of 'gsm_04_08.c', but the related header files were forgotten. Change-Id: I61e728069a1e79bf72c01ef9d9fc5fb171d3892e
2019-05-12libmsc/gsm_04_08.c: clarify IMEI rejection in gsm48_rx_mm_serv_req()Vadim Yanitskiy1-1/+2
Change-Id: I65277aee1f52a8b4fd4b970e992482bbadd94d39
2019-05-12libmsc/gsm_04_08.c: refactor CM Service Request parsingVadim Yanitskiy1-19/+38
In gsm48_rx_mm_serv_req() we need to make sure that a given message buffer is large enough to contain both 'gsm48_hdr' and 'gsm48_service_request' structures. Comparing msg->data_len with size of pointer if wrong because: - we actually need to compare with size of struct(s), - we need msgb_l3len(), not length of the whole buffer. Moreover, since we have to use the pointer arithmetics in order to keep backwards compatibility with Phase1 phones, we also need to check the length of both Classmark2 and MI IEs. Change-Id: I6e7454d7a6f63fd5a0e12fb90d8c58688da0951e
2019-05-12libmsc/gsm_04_08.c: fix: print proper length valueVadim Yanitskiy1-2/+2
Since in parse_umts_auth_resp() we are checking the length of GSM48_IE_AUTH_RES_EXT TLV, we need to print its length, but not the length of the whole L3. Change-Id: I2bfebce6d017be834bfe7628ffa2b341eb82c11c
2019-05-08rename bscconfig.h to config.h, cleanupNeels Hofmeyr1-1/+1
Get rid of the legacy name bscconfig.h from osmo-nitb times. Remove the #include from some of the files that aren't actually using it. Instead of '#include "../../config.h"', use plain '#include "config.h"' because we're anyway passing $top_srcdir as -I during compilation. Change-Id: Id4f683be1f36f0630c83da54e02868aae847aeec
2019-05-08large refactoring: support inter-BSC and inter-MSC HandoverNeels Hofmeyr1-931/+423
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-04-12vlr_subscr: use osmo_use_countNeels Hofmeyr1-6/+7
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore) Change-Id: Ib06d030e8464abe415ff597d462ed40eeddef475
2019-03-19libvlr: Allow 2G auth tuples to be re-used without going through AUTHSylvain Munaut1-0/+5
If the key_seq we get in the first messages matches the last_tuple, then both we and the MS already know the key to use and we don't need the AUTH REQUEST/RESPONSE cycle. Security wise ... not so good, and so IMHO the 'auth required' option in the MSC should always be set. But this allows to turn on ciphering on a channel without doing any MM transaction, and so the MS doesn't turn on the T3240 timer which allows to have a ciphered silent-call channel that won't timeout. Change-Id: Ief840a2ae7a0ffd2bf0bf726f209a79e3f787646 Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2019-02-04Add SGs InterfaceHarald Welte1-5/+14
Add an SGs interface (3GPP TS 29.118) to osmo-msc in order to support SMS tunneling and Circuit Switched Fallback (CSFB) Change-Id: I73359925fc1ca72b33a1466e6ac41307f2f0b11d Related: OS#3615
2019-01-12gsm_04_08: Fix nullpointer derefPhilipp Maier1-2/+5
The pointers conn, conn->vsub and conn->vsub->last_tuple are checked, but before the check those pointers are already dereferenced during assignment. This defeats the purpose of the check. Lets dereference those pointers after the check. Fixes: CID#190404 Change-Id: Ice4992606f3799eac13154ec0b9f53e46d2e178e
2019-01-12err log: fully log MS supported A5 algos on mismatchNeels Hofmeyr1-2/+38
Change-Id: Icb18e0f0bb420de066e7eb8fc683f192ba2a7368
2019-01-12mm_rx_id_resp(): use osmo_mi_name()Neels Hofmeyr1-6/+4
Change-Id: I6bb053def223ed698351ad9f52c1e36293df5d59
2019-01-12refactor log ctx for vlr_subscr and ran_connNeels Hofmeyr1-29/+16
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-12rx CM Service Req: reject double use soonerNeels Hofmeyr1-7/+8
When a CM Service Req is being rejected, we should do so before changing the state of the current conn. Concerning multiple CM Service Requests: in fact we should store multiple requests, but first fix the status quo of rejecting multiple requests. Change-Id: I39209ee6662694aa054a2fc0d21eae76fb33e2f1
2019-01-12add LOG_RAN_CONN() to use the conn->fi->id for contextNeels Hofmeyr1-34/+31
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-12use osmo_lu_type_name() from libosmocoreNeels Hofmeyr1-12/+3
Change-Id: Ib562bb5fb272c0c3ae0849f32b28faa2c26f9bb7
2019-01-11libmsc/gsm_04_11.c: accept MT SMS messages over GSUPVadim Yanitskiy1-0/+5
Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2019-01-04use osmo_rat_type from libosmocoreNeels Hofmeyr1-9/+9
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-04fix vlr ops.subscr_assoc re-associationNeels Hofmeyr1-2/+13
In rare cases, a conn is already associated with a subscriber. So far, we abort()ed on that, bringing the entire osmo-msc down. Rather log an error and keep the service running. In vlr.ops.subscr_assoc, add success/failure return value, and abort the LU/PARQ on error. I haven't figured out in detail yet why/how a subscriber would re-launch a LU/PARQ on a conn that is already associated, so far it is merely clear that we do not want to crash the MSC if that happens. A log is in OS#3742. Related: OS#3742, OS#3743 Change-Id: Ic0d54644bc735700220b1ef3a4384c217d57d20f
2018-12-30libmsc/gsm_04_11.c: forward MO SMS messages over GSUPVadim Yanitskiy1-0/+8
Change-Id: I7d651fde3d608d02f275a74043dc42262aabb1b8 Depends-on: (core) Ic37f3b2114b8095cfce22977e67133b9103942e3 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I7abc95b8e416f7308d54e11be11c08586d18e6c5 Related Change-Id: (TTCN) Id14bbd8bd51558cdacefea0fe042769cd69ed5c8 Related: OS#3587
2018-12-11provide software version information to gsup peerStefan Sperling1-0/+1
Provide software version information to the GSUP peer. The version now shows up in logs like this: Software_Version='osmo-msc-1.2.0.120-1263b' Change-Id: I2eba32569349facdbb1fda201067c62cc804ccf4 Depends: I317d6c59f77e92fbb2b875a83dc0ec2fa5cb6006 Related: OS#3355
2018-12-11make gsup ipa name configurable in osmo-msc.cfgStefan Sperling1-2/+8
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-10drop gsm48 RR ciph mode compl from permitted initial messagesNeels Hofmeyr1-1/+2
It is a message that is initially permitted, but it is in fact not handled in the L3 code but already before, upon receiving BSS_MAP_MSG_CIPHER_MODE_COMPLETE. Change-Id: I0079f07271ca76bd457d0e700f3a736eb9066b47
2018-11-30move gsm_auth_tuple to vlr.h as vlr_auth_tupleNeels Hofmeyr1-3/+3
Along goes GSM_KEYSEQ_INVAL as VLR_*. It's where it logically belongs, and is almost the only reason why vlr.h includes gsm_data.h. The remaining reason, GSM_EXTENSION_LENGTH, will be moved by upcoming patch. Change-Id: I122feae7ee3cbc59e941daef35a954bce29fec76
2018-11-30combine several small .h in msc_common.hNeels Hofmeyr1-1/+0
For hysterical raisins, there are some header files that contain few declarations, and where the name doesn't reflect the content. Combine them to new msc_common.h: - common.h - common_cs.h - osmo_msc.h Change-Id: I9e3a587342f8d398fb27354a2f2475f8797cdb28
2018-11-30rename some RAN conn related stuff to ran_conn_*Neels Hofmeyr1-7/+7
Following previous rename of gsm_subscriber_connection: Some functions and #defines are still called like "msc_conn" or just "msc_", while they are clearly about a RAN conn. To avoid confusion with the future separate concepts of MSC roles and a RAN connection, rename all those to match the common "ran_conn" prefix. Change-Id: Ia17a0a35f11911e00e19cafb5d7828d729a69640
2018-11-30rename gsm_subscriber_connection to ran_connNeels Hofmeyr1-71/+71
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-30rename gsm_encr to geran_encr, it is only applicable on GERANNeels Hofmeyr1-5/+5
On UTRAN, Security Mode is used instead of Ciphering Command, which does not feature an A5 algorithm id. Change-Id: Idc7ca9da1aa13ae16f5db2cb1024676cbc770820
2018-11-30populate gsm_subscriber_connection->encr during CiphNeels Hofmeyr1-0/+7
The gsm_subscriber_connection->encr is never used. Use it. When sending the Ciphering Mode Command, populate the encryption key. When receivint the Ciphering Mode Complete, populate the chosen alg_id. Out of paranoia, store the enc key only if the size is large enough. Hence the vty_dump_one_conn() now reports the actually chosen A5 algorithm ID used. For 3G connections, though, this will still remain 0 in the VTY, since there is no explicit A5 algorithm negotiated on UTRAN. (Security Mode Command and Security Mode Complete instead of the GERAN Ciphering.) (Note, 'struct gsm_encr encr' will be renamed to 'struct geran_encr geran_encr' in Idc7ca9da1aa13ae16f5db2cb1024676cbc770820) Change-Id: Ice2c470c360612249f97301944c6fdf9443c7dce
2018-10-21gsm0407_is_duplicate(): Handle error ret of gsm0407_pdisc_ctr_bin()Harald Welte1-1/+2
Change-Id: If9525694bcbc5c6c0e622e899dd634dc11ed61c4 Fixes: Coverity CID#182702
2018-09-18fix Classmark Update without VLR subscriberNeels Hofmeyr1-0/+21
This recent patch moves Classmark storage to the VLR subscriber, and introduced a segfault when a Classmark Update is received during IMSI detach: commit 986fe7ed18580775bed91399a1f02eae60bda251 change-id I27081bf6e9e017923b2d02607f7ea06beddad82a Mon Sep 17 01:12:13 2018 +0200 "store classmark in vlr_subscr, not conn" It assumed that we would never accept any Classmark Update messages unless we also have a valid subscriber for it. Well, that is proven wrong by the ttcn3-msc-test TC_imsi_detach_by_imsi(), which brings osmo-msc to its knees. Fix: in case of no valid vlr_subscr being present, store Classmark in the conn temporarily, and copy any received Classmark to VLR subscriber as soon as it gets associated with the conn (if at all). Change-Id: Ib2a2ae6bf86e8f29fc6751a8b5cdb7187cd70290
generated by cgit v1.2.3 (git 2.25.1) at 2024-06-29 09:45:33 +0000