aboutsummaryrefslogtreecommitdiffstats
path: root/src/libvlr
AgeCommit message (Collapse)AuthorFilesLines
2020-07-26vlr_auth_fsm: Fix compilation with gcc-10Harald Welte1-1/+1
See also: https://alioth-lists.debian.net/pipermail/debian-mobcom-maintainers/Week-of-Mon-20200413/000650.html Change-Id: If3fdbfa20dec02ba57c582700dff12ebbb7d9439
2020-01-06vlr.c: fix condition to check MSISDN presenceNeels Hofmeyr1-1/+1
msisdn_enc is a buffer, its address is always != 0 Change-Id: Ib2294d2cd339c36df599d7d134f979a572ac308a
2020-01-06vlr_gsup_rx: fix uninitialized rcNeels Hofmeyr1-1/+1
Change-Id: Id7776a473b8356d1d136d78736698f20accc7a36
2019-12-12gsup: indicate CN-Domain in SendAuthInfo RequestsNeels Hofmeyr1-0/+1
In order for osmo-hlr to be able to 100% guarantee distinct INDs for CS and PS, set CN-Domain = CS in all SendAuthInfo Requests. In Milenage auth, it is highly desirable that osmo-hlr guarantees use of distinct INDs for CS and PS domains. If an MSC and SGSN attached at the same time use the same IND bucket to generate Milenage SQN, that collision would rapidly waste SQNs and load osmo-hlr with requesting new auth tuples on each CS/PS Complete-Layer3. So far, osmo-msc did not indicate the CN domain in the GSUP SendAuthInfo Request, which was neither required nor evaluated. The CN-Domain is only sent for the UpdateLocation Request that usually follows later. Related: OS#4318 Change-Id: I22f44068268e62801cadbf6542efaf153423cd65
2019-11-19Fix some typosMartin Hauke5-15/+15
Fix typos and common misspellings in code comments and log messages. Change-Id: Ie66b89065f2100c1d2125ce5a6c9b1d58df7c8ad
2019-10-17vlr_auth_fsm: on SAI use the GSUP provided GMM cause codeAlexander Couzens1-7/+8
The HLR might respond with a specific GMM cause code. E.g. roaming not allowed which needs to be passed down the layers. Change-Id: I9af515dc52834b7c57c42fc3a76ee2c682734e2a
2019-10-17make vlr_gmm_cause_to_mm_cause publicAlexander Couzens1-3/+3
To be used by vlr_auth_fsm Change-Id: I9e13e756f359a9b9e6a2056ab37adf0af14afec1
2019-09-26catch GSUP auth result without auth_fsmNeels Hofmeyr1-0/+6
When a vlr_subscr receives an Send Auth Info result, properly check whether the subscriber has an auth_fsm. Before, a missing auth_fsm would crash osmo-msc with: vlr.c:762 Trying to dispatch event 1 to non-existent FSM instance! Related: OS#4191 Change-Id: I1995d8f68cfde1140968fb9a97bd054de950de2e
2019-09-16vlr: gmm_cause_to_fsm_and_mm_cause() drop fsm_cause_p argumentAlexander Couzens1-16/+6
It's always set to OSMO_TERM_ERROR. Move the assignment to the caller. In prepartion to use gmm_cause_to_fsm_and_mm_cause() in vlr_auth_fsm. Change-Id: Ie4720ad40ef7bcfc528d8d63bfc606c9c0545fb2
2019-09-03vlr: don't log about "gratuitous ID RESPONSE"Neels Hofmeyr1-2/+0
If an ID Response comes in during a non-LU L3 Complete (Paging or CM Service Request), no event needs to be dispatched. So far vlr_subscr_rx_id_resp() logged a NOTICE "gratuitous ID RESPONSE?!?" if no lu_fsm is present. An ID Response can come in particularly as payload with a BSSMAP Cipher Mode Complete message, even though osmo-msc didn't explicitly ask for it. It is not an error to get a Cipher Mode Complete containing an ID Response during Paging or CM Service Request, so remove the confusing log message. Related: OS#4168 (only loosely related) Change-Id: I8a5b8735eb41cd0976c7ab32cdd55440d3ef70ac
2019-08-29vlr_lu_fsm: ignore ID_IMEISV during VLR_ULA_S_WAIT_HLR_UPDNeels Hofmeyr1-1/+7
Change-Id: I2ea4f46efa013671d93892cb07bf830393289150
2019-08-18libvlr/vlr.c: cosmetic: move message_type assignmentVadim Yanitskiy1-2/+2
Change-Id: Ice7f98597b54f03069375fac56fb162f2669e7f0
2019-08-08vlr_lu_fsm: fix missing event for IMEISVNeels Hofmeyr1-0/+1
Event VLR_ULA_E_ID_IMEISV is listed as permitted in VLR_ULA_S_WAIT_LU_COMPL, but is missing from the switch() on the incoming event. So, sending an IMEISV identity during the WAIT_LU_COMPL state would crash osmo-msc. When receiving an IMEISV, vlr_subscr_set_imeisv() in turn calls vlr_subscr_set_imei(), so as far as the lu_fsm is concerned, receiving an IMEISV is identical to receiving an IMEI, and it can continue to send a Check IMEI request to the HLR. Thus simply add VLR_ULA_E_ID_IMEISV to the VLR_ULA_E_ID_IMEI switch case. Change-Id: I11106cb108a4b1406ff9a8b8ff5761440a274dad
2019-07-24vlr_lu_fsm.c: don't send LU reject twiceOliver Smith1-13/+4
Don't call tx_lu_rej() in the "vlr_lu_compl" FSM. It is always getting called in the parent "lu" FSM and is therefore redundant: _vlr_lu_compl_fsm_done(fi, VLR_FSM_RESULT_FAILURE, cause) -> osmo_fsm_inst_state_chg(fi, LU_COMPL_VLR_S_DONE, 0, 0) -> vlr_lu_compl_fsm_dispatch_result() -> lu_fsm_wait_lu_compl()/lu_fsm_wait_lu_compl_standalone() -> lu_fsm_failure() -> lfp->vlr->ops.tx_lu_rej() I have noticed the bug with the TTCN3 tests. This patch fixes TC_lu_imsi_auth_tmsi_check_imei_{nack,err} after stricter checking in [1] and also TC_iu_mo_crcx_ran_reject. [1] I836f76242463789c4c003feec757714827f2a31b (osmo-ttcn3-hacks) Change-Id: I127b27937613ea0ff29d67991c0414fca6d441d9
2019-06-19libvlr/vlr.c: do not expire subscribers if periodic LU is disabledVadim Yanitskiy1-0/+7
When periodic Location Update is disabled (T3212 = 0), it was noticed that OsmoMSC does expire subscribers quite soon - after 60 seconds (VLR_SUBSCRIBER_LU_EXPIRATION_INTERVAL) since the last LU. In order to avoid that, we need to check T3212 timer value in vlr_subscr_expire_lu(), and if it's equal to 0, do not expire anybody until the explicit IMSI Detach. Change-Id: I2ead2241a3394dbdd5417f4554190df3fd698af2
2019-06-17libvlr: fix sgsn tmsi creation, replace constant with defineEric Wild1-3/+3
reported by _dev_zero in #osmocom Change-Id: Ib5679ab5d06b6ef735725b4a68eeb1e9cbcc11ba Depends-On: libosmocore I52b9f6b5f3e96d85a390ba2af21d7814df8aaeec
2019-05-27sgs_iface: detect and react to VLR/HLR failurePhilipp Maier2-20/+33
The HLR (which is connected via the GSUP interface) may fail and disconnect. On the next location update the VLR will try to talk to the HLR and fail. This failure event is not communicated towards the SGs related code and the SGs-association will remain in the LA-PRESENT state forever. Lets add code to report the problem to the SGs code and trigger a RESET an the SGs interface. - Add a flag to report an HLR problem back to the SGs code - Fix the FSM that controls the reset - Make sure the all SGs associations are reset when the failure occurs. Change-Id: Icc7df92879728bc98c85fc1d5d8b4c6246501b12 Related: OS#3859
2019-05-15vlr: optionally send IMEI early to HLROliver Smith3-5/+57
When 'check-imei-rqd 1 early' is set in the config, send the IMEI to the HLR before doing the location update with the HLR. The OsmoHLR documentation referenced in the code will be added in osmo-hlr.git's Change-Id I2dd4a56f7b8be8b5d0e6fc32e04459e5e278d0a9. Related: OS#2542 Change-Id: I88283cad23793b475445d814ff49db534cb41244
2019-05-15vlr: when setting IMEISV, also set IMEIOliver Smith1-0/+3
Copy IMEISV to IMEI when IMEISV changes. The additional SV digits will get cut off then. This is needed for the subscriber on demand use case, since we can get the IMEISV early (see [1]), but need to send the IMEI to the Check IMEI procedure. While adjusting the tests, I have noticed that there are code paths where we ask the MS for the IMEISV first, and later ask the MS for the IMEI, although we already have the IMEISV. This could be improved in a future patch. [1] Change-Id I256224194c3b8caf2b58a88d11dccd32c569201f Related: OS#2542 Change-Id: I02e7b66848bf7dddb31b105e2ae981432817ae1e
2019-05-14vlr_lu_fsm.c: assert for invalid eventsOliver Smith1-12/+6
In state machine callback functions, instead of logging an error when an invalid event arrives, do OSMO_ASSERT(0). Change-Id: If5363ae37b414a0ac195e5f89664c75cbad0bb21
2019-05-08large refactoring: support inter-BSC and inter-MSC HandoverNeels Hofmeyr5-174/+108
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-05-06fix various missing line endings in loggingNeels Hofmeyr2-2/+2
Change-Id: I013eb0eeb5673c06034465020e5dc5230f45ddf5
2019-04-17vlr_sgs_fsm: make sure vsub is marked used when LA is presentPhilipp Maier1-1/+7
When the LU is accepted and the subscriber (vsub) is not claimed as "in use" in the ref counting system. - Make sure vlr_subscr_get() is called when the LU is accepted. Change-Id: Iba90be095569cc5212c61ab8e8a9bfd4ae51fd44 Related OS#3934
2019-04-12vlr_subscr: use osmo_use_countNeels Hofmeyr4-80/+94
Depends: Ife31e6798b4e728a23913179e346552a7dd338c0 (libosmocore) Change-Id: Ib06d030e8464abe415ff597d462ed40eeddef475
2019-04-07vlr_sgs: start lu expiration timer on sgs eps detachPhilipp Maier1-0/+14
When the subscriber is detached from SGs services (but not from 2g services). Then the subscriber essentially becomes a regular 2g subscriber, which means thet the lu expiration timer needs to be started. Change-Id: If95c63706dc1c5a537f7cd1b6481252427cbf234 Related: OS#3614
2019-04-07vlr_sgs: fix SGs IMSI detech from non EPS servicesPhilipp Maier1-0/+12
When the subscriber is detached from non EPS services while the SGs-association is not SGs-NULL, it needs to be removed from the VLR database. Change-Id: I575cf6036ad39468f590b2d57a06cd3512a4c31c Related: OS#3614
2019-03-24vlr_subscr_name(): use OSMO_STRBUFNeels Hofmeyr1-9/+5
We now have a nicer way to compose strings in a buffer than this. (Cosmetic preparation for inter-MSC handover patch.) Change-Id: I7813068032475deb3850af05f7ba5a6f652e7fa2
2019-03-19libvlr: Allow 2G auth tuples to be re-used without going through AUTHSylvain Munaut4-2/+33
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 Welte6-6/+816
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-16VLR: send CHECK-IMEI to EIR/HLROliver Smith3-1/+63
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 Hofmeyr2-11/+27
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-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-09vlr_core.h: remove duplicate declarationsOliver Smith1-2/+0
Remove vlr_subscr_name() and vlr_subscr_alloc() declarations from vlr_core.h, as they are already defined in osmocom/msc/vlr.h and vlr.h gets included on top of vlr_core.h. Change-Id: I5c029be490577b513395dc3f2c2698f365157e73
2019-01-04vlr: auth_fsm: make sure vsub->auth_fsm = NULL when it terminatesNeels Hofmeyr1-3/+7
Probably fixes this segfault: at ../../../../src/osmo-msc/src/libvlr/vlr_lu_fsm.c:957 file=file@entry=0x5611d8f10c28 "../../../../src/osmo-msc/src/libvlr/vlr_lu_fsm.c", line=line@entry=1467) at ../../../src/libosmocore/src/fsm.c:580 parent_event_failure=parent_event_failure@entry=6, parent_event_data=parent_event_data@entry=0x0, vlr=0x5611d98862b0, msc_conn_ref=msc_conn_ref@entry=0x5611d9aa8150, type=VLR_LU_TYPE_REGULAR, tmsi=4294967295, imsi=0x7ffd756c1cf0 "262423403004874", old_lai=0x7ffd756c1ce0, new_lai=0x7ffd756c1ce8, authentication_required=true, ciphering_required=true, is_r99=false, is_utran=false, assign_tmsi=true) at ../../../../src/osmo-msc/src/libvlr/vlr_lu_fsm.c:1467 at ../../../../src/osmo-msc/src/libmsc/gsm_04_08.c:443 The segfault is indirectly caused by 1fbf45c291f7e1f09ef2e862abfeca6a23efdc03, 'enrich context for vlr_subscr_name and ran_conn fi name', which sets auth_fsm context, on a non-NULL auth_fsm that has been deallocated. Change-Id: I3c528eed295be2ee673ea295804372f388a0dccd
2019-01-04fix vlr ops.subscr_assoc re-associationNeels Hofmeyr2-7/+12
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-19Remove redundancy in LAC processingMax1-1/+1
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-17comment: vlr: put the 'balancing' comment closer to the put()Neels Hofmeyr1-1/+1
Change-Id: Ic42768b22d63d182455c8d860961c44159973d0c
2018-12-17vlr_lu_fsm: drop unused out_state INIT -> WAIT_IMEINeels Hofmeyr1-2/+1
There is no state transition from INIT to WAIT_IMEI, only to WAIT_SUB_PRES. If there were code to skip WAIT_SUB_PRES, the allowed state transitions would have to be the same as for WAIT_SUB_PRES, i.e. also WAIT_IMEI_TMSI and WAIT_TMSI_CNF. For now just opt for the status quo. Change-Id: I18ef9e8c96b52401d98f49dc410f13681231b533
2018-12-17tweak comment to indicate sub_pres_vlr fsm as dead codeNeels Hofmeyr1-1/+3
sub_pres_vlr_fsm_start() only ever has an effect if ms_not_reachable_flag == true. But there simply is no code that sets this flag. So sub_pres_vlr_fsm_start() is currently dead code. Also, examining the FSM, if it should ever be set to true, this would halt the LU/CM Service/Paging response, since the FSM would merely change its state without dispatching asynchronous messages. No chance of finishing. Short of dropping the code entirely, first just mark it. The point being that this models some FSM definition from 3GPP specs, and we have a couple other "if (0)" branches in the VLR... Change-Id: I198d442e9ed288f37c7d4e5ec87b82dc53114e99
2018-12-11make gsup ipa name configurable in osmo-msc.cfgStefan Sperling1-5/+6
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-11LU: do not always invoke sub_pres_vlr_fsm_start()Neels Hofmeyr1-1/+6
sub_pres_vlr_fsm_start() starts the FSM, invokes the START event, and then this FSM invariably always directly terminates when vsub->ms_not_reachable_flag == false. So if it is false, there is not much use in instantiating a whole FSM instance that just terminates again, we might as well directly issue the parent-term-event and save some logging space. The same condition is already in place in the vlr_proc_acc_fsm.c in _proc_arq_vlr_node2_post_vlr() for CM Service Request and Paging Response. Now also skip this for LU. Change-Id: Id2303a795dfd381f76e94ff8ff2f495926ca8ba0
2018-12-11detach cancelled subscribers from VLRStefan Sperling1-0/+2
When a subscriber is cancelled, fake an IMSI detach to ensure that the subscriber gets removed from the VLR. I am not entirely sure if this change is correct but it does make TTCN3 test MSC_Tests.TC_gsup_cancel pass. Change-Id: I5918106e4a94ba2e6c61bcd7b90d3bf0565513cc Related: OS#2886
2018-11-30move gsm_auth_tuple to vlr.h as vlr_auth_tupleNeels Hofmeyr2-11/+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-30rename gsm_subscriber_connection to ran_connNeels Hofmeyr1-1/+1
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-16vlr: drop unused is_ps parameter in vlr_subscr_req_lu()Philipp Maier3-3/+3
the function vlr_subscr_req_lu() has a parameter is_ps, which is set to vsub->vlr->cfg.is_ps by the only caller in vlr_lu_fsm.c. Inside the function one can see that vsub->vlr->cfg.is_ps is used directly to decide between PS or CS LU, we could also use is_ps there. Presumably the parameter is_ps had been abandonned in an early development stage and was not removed, so lets drop the parameter. Change-Id: Id239721773b90099d122b232dae1ba457be9d255
2018-10-30lu_fsm: result cb: use proper cause type (warning/coverity)Neels Hofmeyr1-2/+2
enum gsm48_gmm_cause is the wrong enum to pass to lu_fsm_failure(). Use enum gsm48_reject_value instead. Change-Id: If661f72056decb28c0ee82ad2449630a24d4f31c
2018-09-30GSUP client: send CN domain IE on LU requestNeels Hofmeyr1-0/+1
Give the HLR a chance to send us updated subscriber data by indicating the CN domain to be Circuit Switched, only during a LU Request GSUP message. Adjust msc_vlr_tests to expect the added GSUP CN domain IE to indicate CS, i.e. append '280102'. Related: OS#3601 Change-Id: I0c2d33fbfdb4728e480679120d06b7f3a2ccfd76
2018-08-05Remove local libgsupclient; Use libosmo-gsup-client from osmo-hlrHarald Welte2-8/+9
osmo-hlr has recently (as of Change-Id Iad227bb477d64da30dd6bfbbe1bd0c0a55be9474) a working shared library implementation of libosmo-gsup-client. We can remove the local implementation in osmo-msc and use the system-installed shared library instead. Change-Id: I6f542945403cf2e3ddac419186b09ec0e2d43b69
2018-07-29libvlr/vlr.c: forward unhandled GSUP messages towards MSCVadim Yanitskiy1-4/+3
Some internal sub-systems, such as SS/USSD or SMS implementation, may also need to use GSUP connection with HLR. Previously, it was only available within the libvlr code, and nowhere else. Let's introduce the generic GSUP message router, which will receive messages unhandled by VLR itself, and route them to a handler depending on the message type. Change-Id: Ib8146ce5788c8f249dcaa39d61bd0388574bf892
2018-07-26vlr_access_req_fsm.c: use osmo_strlcpy and avoid compiler errorNeels Hofmeyr1-2/+1
gcc 8.1.0: ../../../../src/osmo-msc/src/libvlr/vlr_access_req_fsm.c:679:3: error: ‘strncpy’ output may be truncated copying 15 bytes from a string of length 31 [-Werror=stringop-truncation] strncpy(par->imsi, mi_string, sizeof(par->imsi)-1); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Mobile Identity is a union of various kinds, but the IMSI is at most 15 digits, so truncation is "intended". I hope other layers validate the correct length of an IMSI MI. Change-Id: I0a17a188fc91e42e252ae4bf1d6cd0bf0e5eb077
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-19 09:17:51 +0000