aboutsummaryrefslogtreecommitdiffstats
path: root/include
AgeCommit message (Collapse)AuthorFilesLines
2019-02-04Add SGs InterfaceHarald Welte11-2/+294
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-02-01libmsc/gsm_04_11.c: introduce and use gsm411_assign_sm_rp_mr()Vadim Yanitskiy1-2/+0
Initially, it was assumed that if there is no active RAN connection, we can just start counting from 0x00, as there are no other SMS related transactions, and transaction itself is allocated using talloc_zero(). Until now it was looking good, but... As soon as we establish RAN connection with subscriber, we already have a transaction with SM-RP-MR 0x00, but conn->next_rp_ref also remains 0x00 - it isn't being increased! It means that we can face a SM-RP-MR conflict (or collision) if another MT SMS would arrive to the MSC (from SMSC over GSUP) when this transaction is still active, i.e. the first SMS is still being sent, because conn->next_rp_ref++ would return 0x00 again. Moreover, there might be already a MO SMS transaction, and using the conn->next_rp_ref counter wouldn't prevent us from having duplicate SM-RP-MR value. Let's get rid of this per-connection counter, and introduce a function instead, that would iterate over existing transactions and look for an unused SM-RP-MR value. This change makes the following test cases pass: - TC_gsup_mt_sms_rp_mr, - TC_gsup_mo_mt_sms_rp_mr. Discovered by: Neels Hofmeyr Related Change-Id: (TTCN) I3a52d44f4abde9b6b471b9108c1cee905884c9bc Related Change-Id: (TTCN) I17cbbaa64d9bce770f985588e93cd3eecd732120 Change-Id: Ife6d954c46b7d8348a4221ab677d0355eb3ee7ac
2019-02-01transaction: change arguments of trans_find_by_sm_rp_mr()Vadim Yanitskiy1-1/+2
The need to pass a pointer to RAN connection in order to find a transaction limits possible use cases of trans_find_by_sm_rp_mr(), e.g. when we need to find a transaction, but RAN connection is not established yet. Moreover, the pointer to RAN connection was only used to obtain pointers to gsm_network and vlr_subscr, so we can just pass them directly. Change-Id: I093f36d63e671e50e54fc6236e97a777cc6da77b
2019-01-16MNCC: use explicit struct type in gsm_callMax1-1/+1
There's no need to use 'void *' because we have forward declaration for 'struct gsm_network' in the very same header. Change-Id: I5078ffcf2706adaca1b5df107f8b6a44062ca28c
2019-01-16VLR: send CHECK-IMEI to EIR/HLROliver Smith1-0/+2
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-12refactor log ctx for vlr_subscr and ran_connNeels Hofmeyr1-2/+4
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-12add LOG_RAN_CONN() to use the conn->fi->id for contextNeels Hofmeyr2-8/+8
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-11libmsc/gsm_04_11.c: accept MT SMS messages over GSUPVadim Yanitskiy2-0/+10
Change-Id: I57357982ca0e51f6722c24a4aa1d0fb3e6caef88 Depends-on: (core) Ibe325c64ae2d6c626b232533bb4cbc65fc2b5d71 Depends-on: (OsmoHLR) I0589ff27933e9bca2bcf93b8259004935778db8f Related Change-Id: (TTCN) I63a25c8366cce0852df6b628365151661a22a25f Related: OS#3587
2019-01-09VLR: vlr_subscr_{,msisdn_or_}name: const vsub argOliver Smith1-2/+2
Make the vsub argument of both vlr_subscr_msisdn_or_name() and vlr_subscr_name() a const. The LOGVSUBP() macro uses vlr_subscr_name() and will not generate a warning anymore when used with a const vsub. Change-Id: If609269191f4df6186d823a2eee14012846328e2
2019-01-04use osmo_rat_type from libosmocoreNeels Hofmeyr2-13/+4
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-04abort assignment on Assignment FailureNeels Hofmeyr1-0/+1
If Assignment fails in the BSC, trigger an EV_TEARDOWN_ERROR in the mgcp_ctx FSM instance, so that the call gets torn down immediately. Before this, the non-call would idle around without anything happening. Related: OS#3236 Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore) Change-Id: I358cfbaf0f44f25148e8b9bafcb9257b1952b35a
2019-01-04move trans->assignment_done to cc.assignment_startedNeels Hofmeyr1-3/+1
The flag is set to true when an assignment has been started, and it is only relevant for a CC transaction. So fix naming and place in cc struct. Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and I0ba216b737909e92080a722db26e3577726c63cb/ Change-Id: I8dacf46141ba0b664e85b0867ade330c97d8495f
2019-01-04remove code dup: add msc_mgcp_try_call_assignment()Neels Hofmeyr1-0/+1
Various places in the code check a flag whether assignment was started and launch it. To fix incoming-call-during-ongoing-call, I will tweak that logic. To be able to do that only in one place, remove code dup. Cosmetic preparation for I1f8746e7babfcd3028a4d2c0ba260c608c686c76 and I0ba216b737909e92080a722db26e3577726c63cb/ Depends: I11b182a03f5ecb6df7cd8f260757d3626c8e945d (libosmocore: LOGPFSMSL) Change-Id: I11c0b7dc3f1a747028629b48e522bb3b864884ba
2019-01-04Constify transaction helpers parametersMax1-5/+5
Change-Id: If002a1ff6ba4218cc16592946798340fcb1852ae
2019-01-04fix vlr ops.subscr_assoc re-associationNeels Hofmeyr1-1/+1
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 Yanitskiy3-0/+16
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-30libmsc/VTY: introduce kill-switch for routing SMS over GSUPVadim Yanitskiy1-0/+8
As a rudiment of OsmoNiTB, OsmoMSC is still involved in SMS processing, storage (in SQLite DB), and routing (via SMPP). In real networks this is done by the external entity called SMSC (SMS Centre), while the MSC is doing re-encapsulation of GSM 04.11 SM-TL (Transport Layer) payload (i.e. TPDU) between SM-RL (Relay Layer) and MAP. Since OsmoMSC itself is not a 'Network in The Box' anymore, it makes sense to replicate the 'traditional' behaviour of MSC. The problem is that this behaviour cannot co-exist with the current implementation, so the key idea is to rip out the local SMS storage and routing from OsmoMSC, and (re)implement it in a separate process (OsmoSMSC?). As a temporary solution, this change introduces a 'kill-switch' VTY option that enables routing of SMS messages over GSUP towards ESME (through VLR and HLR), but breaks the local storage and routing. This is why it's disabled by default. As soon as we move the SMS processing and storage away from OsmoMSC, this behaviour would be enabled by default, and the VTY option would be hidden and deprecated. At the moment, this option basically does nothing, and will take an effect in the follow-up changes. Change-Id: Ie57685ed2ce1e4c978e775b68fdffe58de44882b Related: OS#3587
2018-12-21use vty->type instead of local variableStefan Sperling1-2/+0
We can check if we're parsing the config file by checking whether vty->type equals VTY_FILE. This avoids the use of an extra local variable to track the parsing state. Change-Id: I85161575e025f7c389832427a434bd8e2d6ecc75 Fixes: 1051c4208834c22d344dd92d25addfd8e5d95993 Related: OS#3355
2018-12-19Remove redundancy in LAC processingMax1-2/+0
Always use LAC which is part of Cell Global ID otherwise we might end up in a situation where separately stored LAC differs. Both are described in 3GPP TS 23.008 $2.4 as temporary subscriber data to be stored in VLR. Both are defined in 3GPP TS 23.003. The LAC is part of LAI which is part of CGI so there should be no case when those values differ for a given subscriber. Change-Id: I993ebc3e14f25e83124b6d3f8461a4b18f971f8e
2018-12-18VLR: drop unused struct membersMax1-3/+0
Change-Id: I322072653b41cf250aa2c1e346e00bae884feb84
2018-12-13require 'ipa-name' option to be set via config fileStefan Sperling1-0/+2
The 'ipa-name' option can now only be set via the configuration file because changing the IPA name at run-time conflicts with active GSUP connections and routes configured in the HLR. The osmo-msc program must be restarted if its IPA name needs to change. Change-Id: I6cff91793e646e0396e8f1bc87d0f52709e5f12a Related: OS#3355
2018-12-11Revert "move ASS-COMPL MGCP handling out of a_iface_bssap.c"Neels Hofmeyr2-9/+1
Two reasons: - the caller of msc_mgcp_ass_complete() from Iu, iucs_rx_rab_assign(), failed to be adjusted, breaking IuCS, as an --enable-iu --enable-werror build shows. Unfortunately our gerrit verification doesn't --enable-werror for osmo-msc. - the condition of requiring ST_MDCX_RAN is faulty, breaking GSM CS. This reverts commit 212c0c9bdaf1166e3bcbab85f3ab31dc17162f5b. Change-Id: I8348675c2f7c8856ea1682d05ee54160d4cfeb96
2018-12-11make gsup ipa name configurable in osmo-msc.cfgStefan Sperling2-1/+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-10move ASS-COMPL MGCP handling out of a_iface_bssap.cNeels Hofmeyr2-1/+9
BSSMAP Assignment Complete: sort MGCP handling upon Assignment Complete to the proper locations. a_iface_bssap.c is not the right place to invoke the MGCP related procedures. - in a_iface_bssap.c only decode the IEs. - call ran_conn_assign_compl() and pass decoded values. - drop msc_assign_compl(), it was dead code; instead: - add ran_conn_assign_compl() - pass on all MGCP related info to msc_mgcp_ass_complete() - move all MGCP ctx related handling from a_iface_bssap.c to msc_mgcp.c. I'm dropping some comments to save some time, because if I adjust them IMHO they would still anyway restate the obvious. ran_conn_assign_compl() is now quite a thin shim, but it makes sense to have it: - This is the place that should tear down the ran_conn in case assignment failed, left for a future patch. - In the light of upcoming inter-MSC handover, ran_conn_assign_compl() will be the place where the Assignment Complete message might be relayed to a remote MSC. Change-Id: I8137215c443239bddf3e69b5715839a365b73b6c
2018-12-05add VTY commands: mncc internal / external (== -M)Neels Hofmeyr2-0/+2
So far the only way to use external MNCC is to pass the -M cmdline arg: osmo-msc -M /path/to/socket However, the osmo-msc.service file for systemd is installed by 'make install', and hence it is quite impractical to depend on such a config item to be required in the service file: - It defies any scheme an operator may have in place to compose the osmo-msc.cfg file -- this option doesn't go in the .cfg file but needs separate action to add to the installed service file. - After a make install or package upgrades / re-installations, this option will be plain overwritten silently, or lead to the need for resolving file conflicts. The initial spark for this came from configuring the 35c3 GSM from cfg templates. Change-Id: I2ec59d5eba407f83295528b51b93678d446b9cee
2018-11-30move gsm_cbfn to gsm_subscriber.h, the only userNeels Hofmeyr2-6/+4
(with two less line feeds) Change-Id: I375e5b021e643f6b1986ea35ebaf3a6d60e189f5
2018-11-30drop cruft from gsm_subscriber.hNeels Hofmeyr1-23/+0
Change-Id: If6e2252486fe8d932f229a70ce5a4b6f22f6fc52
2018-11-30GSM_EXTENSION_LENGTH -> VLR_MSISDN_LENGTHNeels Hofmeyr2-7/+6
gsm_subscriber.h contains some legacy cruft, part of which is that the VLR's max MSISDN length should rather be defined in vlr.h. Same for GSM_NAME_LENGTH -> VLR_NAME_LENGTH. Adjust some sms_queue stuff that anyway includes vlr.h already. Drop gsm_subscriber.h from vlr.h. Add other (more concise) includes that thus become necessary, since the include chain vlr.h->gsm_subscriber.h->gsm_data.h is no longer in place. Change-Id: Iab5c507ec04fc2884187cf946f6ae2240e4a31f8
2018-11-30move gsm_auth_tuple to vlr.h as vlr_auth_tupleNeels Hofmeyr2-10/+11
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-30cosmetic: drop some unused opaque struct defsNeels Hofmeyr2-4/+0
Change-Id: I4d461dd39d0abdc4f2327445671459340ca1c946
2018-11-30combine several small .h in msc_common.hNeels Hofmeyr6-25/+13
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-30move ran_conn declarations to new ran_conn.hNeels Hofmeyr9-243/+250
With the dawn of inter-BSC,MSC handover, adopting the MSC-A,-I,-T roles from 3GPP TS 49.008, the RAN connection shall soon be a neatly separated corner of osmo-msc, so gravitate ran_conn decarations to files of matching name. Also, the current chaos of API defined in files with mismatching/meaningless names drives me crazy. Change-Id: Ice31e6c43e46678538c65261f150c67e1d0845e5
2018-11-30rename some RAN conn related stuff to ran_conn_*Neels Hofmeyr1-26/+24
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 Hofmeyr16-123/+116
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-30drop msc_compl_l3() return valueNeels Hofmeyr1-7/+2
msc_compl_l3() always returns MSC_CONN_ACCEPT, because the conn FSM handles (or should handle) all reject cases. The accept/reject return value is a legacy from libbsc internally passing a conn over to libmsc, in osmo-nitb. Drop enum msc_compl_l3_rc. Change msc_compl_l3_rc() to return void. Change all callers to always act like for acceptance, as they always did anyway. Drop some local variables now no longer needed. Adjust the comment to msc_compl_l3(). Drop a bunch of #if-0'd code from msc_compl_l3(). Change-Id: I759d15f4e820d5fc16397ed7210ce92308e52a09
2018-11-30rename gsm_encr to geran_encr, it is only applicable on GERANNeels Hofmeyr2-2/+2
On UTRAN, Security Mode is used instead of Ciphering Command, which does not feature an A5 algorithm id. Change-Id: Idc7ca9da1aa13ae16f5db2cb1024676cbc770820
2018-11-30drop unused gsm0408_allow_everyone() declarationNeels Hofmeyr1-1/+0
Change-Id: Id56ea492594edc38d1f9d31d94a1679c0cb61fa0
2018-11-30drop unused SUBSCR_CONN_E_INVALIDNeels Hofmeyr1-2/+0
The idea to catch uninitialized vars was completely moot. We pass events by constants anyway. Change-Id: I6f3c964ee04fec9a96f385199fb3141ac8d672d4
2018-11-30drop unused openbscdefines.hNeels Hofmeyr2-35/+0
Change-Id: If35cd49baa4d0a3b38f31736e1696f481babba9c
2018-11-30drop unused gsm_network->handover.activeNeels Hofmeyr1-3/+0
gsm_network contains an int handover.active which is always zero. Drop it. There is real handover code coming up soon, one part of this is to avoid confusion. The internal MNCC code queried it to decide whether to MNCC_BRIDGE or proxy RTP (MNCC_FRAME_RECV). Since RTP is being handled by osmo-mgw since forever, drop that entire condition from mncc_builtin. Change-Id: Ie16e718266882588b38297121364ca0b7fdfe948
2018-11-30drop unused gsm_subscr_conn->mncc_rtp_bridgeNeels Hofmeyr1-3/+0
Change-Id: I322dc18cfe2cc573744261df837e719b5cf224ba
2018-11-29libmsc/gsm_04_11.c: refactor MT SMS message handlingVadim Yanitskiy1-3/+3
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-29libmsc/transaction: introduce trans_find_by_sm_rp_mr()Ivan Kluchnikov1-0/+5
According to GSM TS 04.11, section 8.2.3, the RP Message Reference is a mandatory field for all messages on the SM-RL (SM Relay Layer), that is used to link an RP-ACK or RP-ERROR message to the associated (preceding) RP-DATA or RP-SMMA message transfer attempt. This change extends the transaction state structure with SM-RP-MR, and introduces a new function for matching transactions within a given connection by this reference. Change-Id: Ice47c37ecef4416e65ecee8931d946c915316791
2018-11-23osmo_msc: remove unused parameter from msc_dtap()Philipp Maier1-2/+1
The parameter link_id in the function msc_dtap() is unused. Lets remove it. Change-Id: I7ba67b0cb514c91bc87a7b396ed3962b7a68e7da
2018-11-21msc/gsm_04_11.h: use forward-declaration for _gsm411_sms_trans_free()Vadim Yanitskiy1-1/+0
Change-Id: I87f96abd2b2d446751d8f95c9164c5eb6a58e66c
2018-11-21msc/gsm_04_11.h: drop unused sms_next_rp_msg_ref()Vadim Yanitskiy1-2/+0
Change-Id: I53b27629177b3342c4f5b34c80d52cbb6dc8476b
2018-11-02Add counters for BSSMAP cipher mode messagesMax1-0/+4
Count COMPLETE and REJECT messages. Besides general troubleshooting that's also useful for TTCN-3 tests to check that OsmoMSC processed those messages as expected. Change-Id: I5822b2b38b64f1a691b26c926a8e2bece21dc624 Related: OS#3187
2018-10-24gsm_04_08_cc: Add global guard timer for MNCCPhilipp Maier2-0/+4
The external MNCC handler may hang indefinitely in cases where the remote end of the MNCC ceases to work properly. Add a global guard timer to make sure the call reaches ACTIVE state. Change-Id: I7375d1e17cd746aac4eadfe1e587e82cf1630d3d Related: OS#3599
2018-09-18fix Classmark Update without VLR subscriberNeels Hofmeyr1-0/+4
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
2018-09-17A5/n Ciph: request Classmark Update if missingNeels Hofmeyr3-0/+15
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 71330720b6efdda2fcfd3e9c0cb45f89e32e5670 "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
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-27 11:22:02 +0000