March 2024 - gerrit-log - lists.osmocom.org

[S] Change in osmo-ttcn3-hacks[master]: msc: f_expect_paging(): fix by_tmsi arg

by neels

Attention is currently required from: fixeria, pespin. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36455?usp=email ) Change subject: msc: f_expect_paging(): fix by_tmsi arg ...................................................................... Patch Set 1: (1 comment) File msc/BSC_ConnectionHandler.ttcn: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36455/comment/2124249d_bc8a… PS1, Line 1360: boolean by_tmsi := true > I don't even know why I'm doing code review if 99% of what I say seems to be irrelevant, bikeshed, e […] i appreciate the feedback and myself tend to give strict review, so i know what it's like. i am still of the humble opinion that this is not relevant enough to discuss. When I weigh the possible consequences against the time spent, here is way more time than consequence, so please let's quit this. -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36455?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I9434745b7faeb738caafed8080b9f7b1a6a8079a Gerrit-Change-Number: 36455 Gerrit-PatchSet: 1 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-CC: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Thu, 28 Mar 2024 03:21:13 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Comment-In-Reply-To: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-MessageType: comment

1 year, 4 months

1
0
0 0

[S] Change in osmo-ttcn3-hacks[master]: ran-emu: allow receiving Paging without a TMSI

by neels

Attention is currently required from: pespin. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36454?usp=email ) Change subject: ran-emu: allow receiving Paging without a TMSI ...................................................................... Patch Set 1: (1 comment) File library/RAN_Emulation.ttcnpp: https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36454/comment/92551cee_1c2a… PS1, Line 507: var template OCT4 tmsi := omit; > that would be a var "template (omit) OCT4" it works, why change it? -- To view, visit https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36454?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-ttcn3-hacks Gerrit-Branch: master Gerrit-Change-Id: I1bdf3488be0f8d4f0905665c4ba642f9468b9777 Gerrit-Change-Number: 36454 Gerrit-PatchSet: 1 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-CC: pespin <pespin(a)sysmocom.de> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Comment-Date: Thu, 28 Mar 2024 03:13:23 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: comment

1 year, 4 months

1
0
0 0

[S] Change in osmo-msc[master]: invalidate vsub->msc_conn_ref when msc_a is discarded

by neels

neels has submitted this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/36451?usp=email ) Change subject: invalidate vsub->msc_conn_ref when msc_a is discarded ...................................................................... invalidate vsub->msc_conn_ref when msc_a is discarded We have an msc_conn_ref pointer from vlr_subscr to an active msc_a instance. So far, we just keep it pointing at discarded memory. Instead, make sure it goes back to NULL when the msc_a instance deallocates. This way the VLR can reliably tell whether a given VLR entry still has an active connection or is just inactively caching the subscriber. Related: SYS#6860 OS#4721 Change-Id: Ic63d01d220b63453976fe06a7c6b606f97172c99 --- M src/libmsc/msc_a.c 1 file changed, 22 insertions(+), 0 deletions(-) Approvals: laforge: Looks good to me, approved Jenkins Builder: Verified fixeria: Looks good to me, but someone else must approve pespin: Looks good to me, but someone else must approve diff --git a/src/libmsc/msc_a.c b/src/libmsc/msc_a.c index 4fb30c4..70d9bf7 100644 --- a/src/libmsc/msc_a.c +++ b/src/libmsc/msc_a.c @@ -999,6 +999,7 @@ void msc_a_fsm_cleanup(struct osmo_fsm_inst *fi, enum osmo_fsm_term_cause cause) { struct msc_a *msc_a = msc_a_fi_priv(fi); + struct vlr_subscr *vsub = msc_a_vsub(msc_a); trans_conn_closed(msc_a); @@ -1006,6 +1007,10 @@ LOG_MSC_A(msc_a, LOGL_ERROR, "Deallocating active transactions failed\n"); LOG_MSC_A_CAT(msc_a, DREF, LOGL_DEBUG, "max total use count was %d\n", msc_a->max_total_use_count); + + /* Invalidate the active conn in VLR subscriber state, if any. */ + if (vsub && vsub->msc_conn_ref == msc_a) + vsub->msc_conn_ref = NULL; } const struct value_string msc_a_fsm_event_names[] = { -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/36451?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Change-Id: Ic63d01d220b63453976fe06a7c6b606f97172c99 Gerrit-Change-Number: 36451 Gerrit-PatchSet: 1 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: merged

1 year, 4 months

1
0
0 0

[M] Change in osmo-msc[master]: fix VLR evil twin on LU with unknown TMSI

by neels

neels has submitted this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/36452?usp=email ) Change subject: fix VLR evil twin on LU with unknown TMSI ...................................................................... fix VLR evil twin on LU with unknown TMSI When a subscriber first attaches by TMSI only, and later tells the IMSI via ID Response, it may turn out that this IMSI already exists in the VLR database. If this happens, the TMSI that the subscriber issued was not known in the existing VLR entry, indicating that the subscriber has in the meantime camped on a different core. Which means we can assume that there cannot be any active connections, and the old subscriber can be discarded, for the benefit of the new one. (We could also discard the new one, but it is more complex to reparent the ongoing FSMs for Compl L3 than to copy some dormant VLR state.) In vlr_subscr_set_imsi(), check for an existing IMSI entry in the VLR. If such exists, copy any pending Paging and auth tuple state to the new subscriber, and discard the old one from the VLR. In order to safely discard a vlr subscriber by force, add a new vlr_ops function: subscr_inval(), to tell the MSC that a vlr_subscr is no longer valid. Upcoming patch I583682d1a35a70b008d7bb2d89ba7c3109a60b21 better clears TMSI state from the VLR, making it more likely to hit the evil twin situation this patch fixes; hence this is, sort of, preparation. Related: SYS#6860 OS#4721 Change-Id: Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd --- M include/osmocom/msc/paging.h M include/osmocom/msc/vlr.h M src/libmsc/gsm_04_08.c M src/libmsc/paging.c M src/libvlr/vlr.c M tests/msc_vlr/msc_vlr_test_rest.err 6 files changed, 139 insertions(+), 2 deletions(-) Approvals: Jenkins Builder: Verified neels: Looks good to me, approved diff --git a/include/osmocom/msc/paging.h b/include/osmocom/msc/paging.h index 4de679d..f8ebf9e 100644 --- a/include/osmocom/msc/paging.h +++ b/include/osmocom/msc/paging.h @@ -40,6 +40,7 @@ struct paging_request *paging_request_start(struct vlr_subscr *vsub, enum paging_cause cause, paging_cb_t paging_cb, struct gsm_trans *trans, const char *label); +void paging_request_join_vsub(struct vlr_subscr *keep_vsub, struct vlr_subscr *discarding_vsub); void paging_request_remove(struct paging_request *pr); void paging_response(struct msc_a *msc_a); diff --git a/include/osmocom/msc/vlr.h b/include/osmocom/msc/vlr.h index 86a72f2..a7707fd 100644 --- a/include/osmocom/msc/vlr.h +++ b/include/osmocom/msc/vlr.h @@ -257,6 +257,8 @@ /* notify MSC/SGSN that the given subscriber has been associated * with this msc_conn_ref */ int (*subscr_assoc)(void *msc_conn_ref, struct vlr_subscr *vsub); + /* notify MSC that the given subscriber is no longer valid */ + void (*subscr_inval)(void *msc_conn_ref, struct vlr_subscr *vsub); }; /* An instance of the VLR codebase */ diff --git a/src/libmsc/gsm_04_08.c b/src/libmsc/gsm_04_08.c index 70faf95..17350fa 100644 --- a/src/libmsc/gsm_04_08.c +++ b/src/libmsc/gsm_04_08.c @@ -1572,6 +1572,24 @@ return 0; } +static void msc_vlr_subscr_inval(void *msc_conn_ref, struct vlr_subscr *vsub) +{ + /* Search vsub backwards to make sure msc_conn_ref is a valid msc_a instance. */ + struct msub *msub; + OSMO_ASSERT(vsub); + llist_for_each_entry(msub, &msub_list, entry) { + struct msc_a *msc_a; + if (msub->vsub != vsub) + continue; + + msc_a = msub_msc_a(msub); + if (msc_a) + msc_a_release_cn(msc_a); + + msub->vsub = NULL; + } +} + /* operations that we need to implement for libvlr */ const struct vlr_ops msc_vlr_ops = { .tx_auth_req = msc_vlr_tx_auth_req, @@ -1586,6 +1604,7 @@ .tx_mm_info = msc_vlr_tx_mm_info, .subscr_update = msc_vlr_subscr_update, .subscr_assoc = msc_vlr_subscr_assoc, + .subscr_inval = msc_vlr_subscr_inval, }; struct msgb *gsm48_create_mm_serv_rej(enum gsm48_reject_value value) diff --git a/src/libmsc/paging.c b/src/libmsc/paging.c index 9845f99..9b3dad5 100644 --- a/src/libmsc/paging.c +++ b/src/libmsc/paging.c @@ -120,6 +120,34 @@ return pr; } +/* Two subscribers (e.g. an old TMSI and a new TMSI) turn out to have the same identity, so in order to discard one of + * them, transfer any pending Paging requests to the vsub that will survive. */ +void paging_request_join_vsub(struct vlr_subscr *keep_vsub, struct vlr_subscr *discarding_vsub) +{ + struct paging_request *pr; + + if (!discarding_vsub->cs.is_paging) + return; + + /* transfer all Paging Response callbacks */ + while ((pr = llist_first_entry_or_null(&discarding_vsub->cs.requests, struct paging_request, entry))) { + llist_del(&pr->entry); + talloc_steal(keep_vsub, pr); + llist_add_tail(&pr->entry, &keep_vsub->cs.requests); + } + + /* make sure a Paging use count is present on keep_vsub, if needed */ + if (!keep_vsub->cs.is_paging && !llist_empty(&keep_vsub->cs.requests)) { + vlr_subscr_get(keep_vsub, VSUB_USE_PAGING); + keep_vsub->cs.is_paging = true; + } + + /* Already made sure at the top of this function that discarding_vsub->cs.is_paging == true */ + discarding_vsub->cs.is_paging = false; + osmo_timer_del(&discarding_vsub->cs.paging_response_timer); + vlr_subscr_put(discarding_vsub, VSUB_USE_PAGING); +} + void paging_request_remove(struct paging_request *pr) { struct gsm_trans *trans = pr->trans; diff --git a/src/libvlr/vlr.c b/src/libvlr/vlr.c index e2e02bf..cb5794f 100644 --- a/src/libvlr/vlr.c +++ b/src/libvlr/vlr.c @@ -36,6 +36,7 @@ #include <osmocom/msc/vlr.h> #include <osmocom/msc/debug.h> #include <osmocom/msc/gsup_client_mux.h> +#include <osmocom/msc/paging.h> #include <netinet/in.h> #include <arpa/inet.h> @@ -272,7 +273,8 @@ llist_for_each_entry(vsub, &vlr->subscribers, list) { if (vlr_subscr_matches_imsi(vsub, imsi)) { - vlr_subscr_get_src(vsub, use, file, line); + if (use) + vlr_subscr_get_src(vsub, use, file, line); return vsub; } } @@ -577,11 +579,63 @@ return vsub; } +static void dedup_vsub(struct vlr_subscr *exists, struct vlr_subscr *vsub) +{ + struct vlr_instance *vlr = exists->vlr; + int i; + int j; + LOGP(DVLR, LOGL_NOTICE, + "There is an existing subscriber for IMSI %s used by %s, replacing with new VLR subscr: %s used by %s\n", + exists->imsi, osmo_use_count_to_str_c(OTC_SELECT, &exists->use_count), + vlr_subscr_name(vsub), + osmo_use_count_to_str_c(OTC_SELECT, &vsub->use_count)); + + /* Take over some state from the previous vsub */ + paging_request_join_vsub(vsub, exists); + if (!vsub->msisdn[0]) + OSMO_STRLCPY_ARRAY(vsub->msisdn, exists->msisdn); + if (!vsub->name[0]) + OSMO_STRLCPY_ARRAY(vsub->name, exists->name); + /* Copy valid auth tuples we may already have, to reduce the need to ask for new ones from the HLR */ + for (i = 0; i < ARRAY_SIZE(exists->auth_tuples); i++) { + if (exists->auth_tuples[i].key_seq == VLR_KEY_SEQ_INVAL) + continue; + for (j = 0; j < ARRAY_SIZE(vsub->auth_tuples); j++) { + if (vsub->auth_tuples[j].key_seq != VLR_KEY_SEQ_INVAL) + continue; + vsub->auth_tuples[j] = exists->auth_tuples[i]; + } + } + + if (exists->msc_conn_ref) + LOGVSUBP(LOGL_ERROR, vsub, + "There is an existing VLR entry for this same subscriber with an active connection." + " That should not be possible. Discarding old subscriber entry %s.\n", + exists->imsi); + + if (vlr->ops.subscr_inval) + vlr->ops.subscr_inval(exists->msc_conn_ref, exists); + vlr_subscr_free(exists); +} + void vlr_subscr_set_imsi(struct vlr_subscr *vsub, const char *imsi) { + struct vlr_subscr *exists; if (!vsub) return; + /* If the same IMSI is already set, nothing changes. */ + if (!strcmp(vsub->imsi, imsi)) + return; + + /* We've just learned about this new IMSI, our primary key in the VLR. make sure to invalidate any prior VLR + * entries for this IMSI. */ + exists = vlr_subscr_find_by_imsi(vsub->vlr, imsi, NULL); + + if (exists) + dedup_vsub(exists, vsub); + + /* Set the IMSI on the new subscriber, here. */ if (OSMO_STRLCPY_ARRAY(vsub->imsi, imsi) >= sizeof(vsub->imsi)) { LOGP(DVLR, LOGL_NOTICE, "IMSI was truncated: full IMSI=%s, truncated IMSI=%s\n", imsi, vsub->imsi); diff --git a/tests/msc_vlr/msc_vlr_test_rest.err b/tests/msc_vlr/msc_vlr_test_rest.err index e649325..fae302f 100644 --- a/tests/msc_vlr/msc_vlr_test_rest.err +++ b/tests/msc_vlr/msc_vlr_test_rest.err @@ -467,7 +467,6 @@ DMM IDENTITY RESPONSE: IMSI-901700000004620 DVLR set IMSI on subscriber; IMSI=901700000004620 id=901700000004620 DVLR vlr_lu_fsm(TMSI-0x23422342:GERAN-A:LU){VLR_ULA_S_WAIT_IMSI}: Received Event VLR_ULA_E_ID_IMSI -DVLR set IMSI on subscriber; IMSI=901700000004620 id=901700000004620 DVLR vlr_lu_fsm(TMSI-0x23422342:GERAN-A:LU){VLR_ULA_S_WAIT_IMSI}: vlr_loc_upd_node1_pre() DVLR vlr_lu_fsm(TMSI-0x23422342:GERAN-A:LU){VLR_ULA_S_WAIT_IMSI}: vlr_loc_upd_node1() DVLR vlr_lu_fsm(TMSI-0x23422342:GERAN-A:LU){VLR_ULA_S_WAIT_IMSI}: vlr_loc_upd_post_auth() -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/36452?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Change-Id: Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd Gerrit-Change-Number: 36452 Gerrit-PatchSet: 3 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: merged

1 year, 4 months

1
0
0 0

[S] Change in osmo-msc[master]: never page for TMSI with 'no assign-tmsi'

by neels

neels has submitted this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/36453?usp=email ) ( 1 is the latest approved patch-set. No files were changed between the latest approved patch-set and the submitted one. )Change subject: never page for TMSI with 'no assign-tmsi' ...................................................................... never page for TMSI with 'no assign-tmsi' With 'no assign-tmsi', regard any TMSI as invalidated at the end of a Location Updating procedure. Hence, avoid paging by TMSI. When 'no assign-tmsi' is set, osmo-msc does not actively assign a new TMSI at the end of the Location Updating. However, it stores any TMSI identity that the MS sends in a Location Updating Request. So far, this caused osmo-msc to use the TMSI that the MS had sent in subsequent Paging, which goes unanswered by the MS. (After the long standing evil twin problem regarding TMSI MI has been fixed in recent Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd, there is no longer an evil twin risked by clearing out a TMSI.) Related: SYS#6860 OS#4721 Change-Id: I583682d1a35a70b008d7bb2d89ba7c3109a60b21 --- M src/libvlr/vlr_lu_fsm.c M tests/msc_vlr/msc_vlr_test_rest.err 2 files changed, 38 insertions(+), 11 deletions(-) Approvals: Jenkins Builder: Verified laforge: Looks good to me, approved pespin: Looks good to me, but someone else must approve fixeria: Looks good to me, but someone else must approve diff --git a/src/libvlr/vlr_lu_fsm.c b/src/libvlr/vlr_lu_fsm.c index 7500c86..5d8f78b 100644 --- a/src/libvlr/vlr_lu_fsm.c +++ b/src/libvlr/vlr_lu_fsm.c @@ -469,6 +469,8 @@ lu_compl_vlr_new_tmsi(fi); return; } + /* else, any previously used TMSI is now invalid. */ + vsub->tmsi = GSM_RESERVED_TMSI; /* Location Updating Accept */ vlr->ops.tx_lu_acc(lcvp->msc_conn_ref, GSM_RESERVED_TMSI); @@ -514,6 +516,8 @@ /* Wait for TMSI ack */ return; } + /* else, any previously used TMSI is now invalid. */ + vsub->tmsi = GSM_RESERVED_TMSI; /* No TMSI needed, accept now. */ vlr->ops.tx_lu_acc(lcvp->msc_conn_ref, GSM_RESERVED_TMSI); diff --git a/tests/msc_vlr/msc_vlr_test_rest.err b/tests/msc_vlr/msc_vlr_test_rest.err index fae302f..3a6442e 100644 --- a/tests/msc_vlr/msc_vlr_test_rest.err +++ b/tests/msc_vlr/msc_vlr_test_rest.err @@ -527,7 +527,7 @@ DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){LU_COMPL_VLR_S_INIT}: state_chg to LU_COMPL_VLR_S_WAIT_SUB_PRES DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: Received Event LU_COMPL_VLR_E_SUB_PRES_COMPL - sending LU Accept for IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU -DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342 + attached: now used by 3 (active-conn,vlr_gsup_rx,attached) +DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + attached: now used by 3 (active-conn,vlr_gsup_rx,attached) DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: state_chg to LU_COMPL_VLR_S_DONE DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_LU_COMPL_SUCCESS DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){LU_COMPL_VLR_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: upd_hlr_vlr_fsm(TMSI-0x23422342:GERAN-A:LU)) @@ -540,15 +540,15 @@ DMSC msc_a(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){MSC_A_ST_AUTHENTICATED}: Received Event MSC_A_EV_UNUSED DMSC msc_a(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){MSC_A_ST_AUTHENTICATED}: state_chg to MSC_A_ST_RELEASING DBSSAP msc_a(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){MSC_A_ST_RELEASING}: Releasing: msc_a use is 0 (-) -DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342 + msc_a_fsm_releasing_onenter: now used by 4 (active-conn,vlr_gsup_rx,attached,msc_a_fsm_releasing_onenter) -DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342 + vlr_subscr_cancel_attach_fsm: now used by 5 (active-conn,vlr_gsup_rx,attached,msc_a_fsm_releasing_onenter,vlr_subscr_cancel_attach_fsm) -DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342 - vlr_subscr_cancel_attach_fsm: now used by 4 (active-conn,vlr_gsup_rx,attached,msc_a_fsm_releasing_onenter) +DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + msc_a_fsm_releasing_onenter: now used by 4 (active-conn,vlr_gsup_rx,attached,msc_a_fsm_releasing_onenter) +DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_subscr_cancel_attach_fsm: now used by 5 (active-conn,vlr_gsup_rx,attached,msc_a_fsm_releasing_onenter,vlr_subscr_cancel_attach_fsm) +DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_subscr_cancel_attach_fsm: now used by 4 (active-conn,vlr_gsup_rx,attached,msc_a_fsm_releasing_onenter) DREF msc_a(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){MSC_A_ST_RELEASING}: + wait-Clear-Complete: now used by 1 (wait-Clear-Complete) DMSC msc_a(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){MSC_A_ST_RELEASING}: RAN encode: CLEAR_COMMAND on GERAN-A DMSC dummy_msc_i(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){0}: Received Event MSC_I_EV_FROM_A_FORWARD_ACCESS_SIGNALLING_REQUEST -DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342 - msc_a_fsm_releasing_onenter: now used by 3 (active-conn,vlr_gsup_rx,attached) +DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - msc_a_fsm_releasing_onenter: now used by 3 (active-conn,vlr_gsup_rx,attached) DVLR upd_hlr_vlr_fsm(TMSI-0x23422342:GERAN-A:LU){UPD_HLR_VLR_S_DONE}: Deallocated, including all deferred deallocations -DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342 - vlr_gsup_rx: now used by 2 (active-conn,attached) +DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_gsup_rx: now used by 2 (active-conn,attached) <-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: vlr_gsupc_read_cb() returns 0 bssap_clear_sent == 1 - LU was successful, and the conn has already been closed @@ -566,19 +566,19 @@ DMSC msc_a(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){MSC_A_ST_RELEASED}: Removing from parent msub_fsm DREF msc_a(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){MSC_A_ST_RELEASED}: max total use count was 3 DMSC msub_fsm{active}: Received Event MSUB_EV_ROLE_TERMINATED -DMSC msub(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342) MSC-A terminated -DMSC msub(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342) 1 MSC-I still active +DMSC msub(IMSI-901700000004620:MSISDN-46071) MSC-A terminated +DMSC msub(IMSI-901700000004620:MSISDN-46071) 1 MSC-I still active DMSC msub_fsm{active}: state_chg to terminating DMSC msub_fsm{terminating}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_REGULAR, caused by: msc_a(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU)) DMSC dummy_msc_i(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){0}: Terminating in cascade, depth 3 (cause = OSMO_FSM_TERM_PARENT, caused by: msc_a(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU)) DMSC dummy_msc_i(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){0}: Removing from parent msub_fsm DMSC dummy_msc_i(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){0}: Deferring: will deallocate with msc_a(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU) -DMSC msub(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342) Free -DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342 - active-conn: now used by 1 (attached) +DMSC msub(IMSI-901700000004620:MSISDN-46071) Free +DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - active-conn: now used by 1 (attached) DMSC msub_fsm{terminating}: Deferring: will deallocate with msc_a(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU) DMSC msc_a(IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342:GERAN-A:LU){MSC_A_ST_RELEASED}: Deallocated, including all deferred deallocations - msub gone llist_count(&msub_list) == 0 -DVLR freeing VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x23422342 (max total use count was 5) +DVLR freeing VLR subscr IMSI-901700000004620:MSISDN-46071 (max total use count was 5) ===== test_lu_unknown_tmsi: SUCCESS -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/36453?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Change-Id: I583682d1a35a70b008d7bb2d89ba7c3109a60b21 Gerrit-Change-Number: 36453 Gerrit-PatchSet: 3 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: merged

1 year, 4 months

1
0
0 0

[M] Change in osmo-msc[master]: fix VLR evil twin on LU with unknown TMSI

by neels

Attention is currently required from: fixeria, laforge, pespin. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/36452?usp=email ) Change subject: fix VLR evil twin on LU with unknown TMSI ...................................................................... Patch Set 3: Code-Review+2 -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/36452?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Change-Id: Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd Gerrit-Change-Number: 36452 Gerrit-PatchSet: 3 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Thu, 28 Mar 2024 03:10:24 +0000 Gerrit-HasComments: No Gerrit-Has-Labels: Yes Gerrit-MessageType: comment

1 year, 4 months

1
0
0 0

[M] Change in osmo-msc[master]: fix VLR evil twin on LU with unknown TMSI

by neels

Attention is currently required from: fixeria, laforge, pespin. neels has posted comments on this change. ( https://gerrit.osmocom.org/c/osmo-msc/+/36452?usp=email ) Change subject: fix VLR evil twin on LU with unknown TMSI ...................................................................... Patch Set 2: (1 comment) File src/libvlr/vlr.c: https://gerrit.osmocom.org/c/osmo-msc/+/36452/comment/a1cbfb2c_e038db31 PS1, Line 597: struct vlr_instance *vlr = exists->vlr; > ack […] Done -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/36452?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Change-Id: Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd Gerrit-Change-Number: 36452 Gerrit-PatchSet: 2 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Comment-Date: Thu, 28 Mar 2024 03:07:28 +0000 Gerrit-HasComments: Yes Gerrit-Has-Labels: No Comment-In-Reply-To: neels <nhofmeyr(a)sysmocom.de> Comment-In-Reply-To: pespin <pespin(a)sysmocom.de> Gerrit-MessageType: comment

1 year, 4 months

1
0
0 0

[M] Change in osmo-msc[master]: fix VLR evil twin on LU with unknown TMSI

by neels

Attention is currently required from: fixeria, laforge, neels, pespin. Hello Jenkins Builder, fixeria, laforge, pespin, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-msc/+/36452?usp=email to look at the new patch set (#3). Change subject: fix VLR evil twin on LU with unknown TMSI ...................................................................... fix VLR evil twin on LU with unknown TMSI When a subscriber first attaches by TMSI only, and later tells the IMSI via ID Response, it may turn out that this IMSI already exists in the VLR database. If this happens, the TMSI that the subscriber issued was not known in the existing VLR entry, indicating that the subscriber has in the meantime camped on a different core. Which means we can assume that there cannot be any active connections, and the old subscriber can be discarded, for the benefit of the new one. (We could also discard the new one, but it is more complex to reparent the ongoing FSMs for Compl L3 than to copy some dormant VLR state.) In vlr_subscr_set_imsi(), check for an existing IMSI entry in the VLR. If such exists, copy any pending Paging and auth tuple state to the new subscriber, and discard the old one from the VLR. In order to safely discard a vlr subscriber by force, add a new vlr_ops function: subscr_inval(), to tell the MSC that a vlr_subscr is no longer valid. Upcoming patch I583682d1a35a70b008d7bb2d89ba7c3109a60b21 better clears TMSI state from the VLR, making it more likely to hit the evil twin situation this patch fixes; hence this is, sort of, preparation. Related: SYS#6860 OS#4721 Change-Id: Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd --- M include/osmocom/msc/paging.h M include/osmocom/msc/vlr.h M src/libmsc/gsm_04_08.c M src/libmsc/paging.c M src/libvlr/vlr.c M tests/msc_vlr/msc_vlr_test_rest.err 6 files changed, 139 insertions(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-msc refs/changes/52/36452/3 -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/36452?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Change-Id: Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd Gerrit-Change-Number: 36452 Gerrit-PatchSet: 3 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-MessageType: newpatchset

1 year, 4 months

1
0
0 0

[S] Change in osmo-msc[master]: never page for TMSI with 'no assign-tmsi'

by neels

Attention is currently required from: neels. Hello Jenkins Builder, fixeria, laforge, pespin, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-msc/+/36453?usp=email to look at the new patch set (#2). The following approvals got outdated and were removed: Verified+1 by Jenkins Builder The change is no longer submittable: Verified is unsatisfied now. Change subject: never page for TMSI with 'no assign-tmsi' ...................................................................... never page for TMSI with 'no assign-tmsi' With 'no assign-tmsi', regard any TMSI as invalidated at the end of a Location Updating procedure. Hence, avoid paging by TMSI. When 'no assign-tmsi' is set, osmo-msc does not actively assign a new TMSI at the end of the Location Updating. However, it stores any TMSI identity that the MS sends in a Location Updating Request. So far, this caused osmo-msc to use the TMSI that the MS had sent in subsequent Paging, which goes unanswered by the MS. (After the long standing evil twin problem regarding TMSI MI has been fixed in recent Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd, there is no longer an evil twin risked by clearing out a TMSI.) Related: SYS#6860 OS#4721 Change-Id: I583682d1a35a70b008d7bb2d89ba7c3109a60b21 --- M src/libvlr/vlr_lu_fsm.c M tests/msc_vlr/msc_vlr_test_rest.err 2 files changed, 38 insertions(+), 11 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-msc refs/changes/53/36453/2 -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/36453?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Change-Id: I583682d1a35a70b008d7bb2d89ba7c3109a60b21 Gerrit-Change-Number: 36453 Gerrit-PatchSet: 2 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de> Gerrit-MessageType: newpatchset

1 year, 4 months

1
0
0 0

[M] Change in osmo-msc[master]: fix VLR evil twin on LU with unknown TMSI

by neels

Attention is currently required from: fixeria, laforge, neels, pespin. Hello Jenkins Builder, fixeria, laforge, pespin, I'd like you to reexamine a change. Please visit https://gerrit.osmocom.org/c/osmo-msc/+/36452?usp=email to look at the new patch set (#2). The following approvals got outdated and were removed: Code-Review+1 by fixeria, Code-Review+1 by laforge, Code-Review+1 by pespin, Verified+1 by Jenkins Builder Change subject: fix VLR evil twin on LU with unknown TMSI ...................................................................... fix VLR evil twin on LU with unknown TMSI When a subscriber first attaches by TMSI only, and later tells the IMSI via ID Response, it may turn out that this IMSI already exists in the VLR database. If this happens, the TMSI that the subscriber issued was not known in the existing VLR entry, indicating that the subscriber has in the meantime camped on a different core. Which means we can assume that there cannot be any active connections, and the old subscriber can be discarded, for the benefit of the new one. (We could also discard the new one, but it is more complex to reparent the ongoing FSMs for Compl L3 than to copy some dormant VLR state.) In vlr_subscr_set_imsi(), check for an existing IMSI entry in the VLR. If such exists, copy any pending Paging and auth tuple state to the new subscriber, and discard the old one from the VLR. In order to safely discard a vlr subscriber by force, add a new vlr_ops function: subscr_inval(), to tell the MSC that a vlr_subscr is no longer valid. Upcoming patch I583682d1a35a70b008d7bb2d89ba7c3109a60b21 better clears TMSI state from the VLR, making it more likely to hit the evil twin situation this patch fixes; hence this is, sort of, preparation. Related: SYS#6860 OS#4721 Change-Id: Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd --- M include/osmocom/msc/paging.h M include/osmocom/msc/vlr.h M src/libmsc/gsm_04_08.c M src/libmsc/paging.c M src/libvlr/vlr.c M tests/msc_vlr/msc_vlr_test_rest.err 6 files changed, 138 insertions(+), 2 deletions(-) git pull ssh://gerrit.osmocom.org:29418/osmo-msc refs/changes/52/36452/2 -- To view, visit https://gerrit.osmocom.org/c/osmo-msc/+/36452?usp=email To unsubscribe, or for help writing mail filters, visit https://gerrit.osmocom.org/settings Gerrit-Project: osmo-msc Gerrit-Branch: master Gerrit-Change-Id: Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd Gerrit-Change-Number: 36452 Gerrit-PatchSet: 2 Gerrit-Owner: neels <nhofmeyr(a)sysmocom.de> Gerrit-Reviewer: Jenkins Builder Gerrit-Reviewer: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-Reviewer: laforge <laforge(a)osmocom.org> Gerrit-Reviewer: pespin <pespin(a)sysmocom.de> Gerrit-Attention: neels <nhofmeyr(a)sysmocom.de> Gerrit-Attention: laforge <laforge(a)osmocom.org> Gerrit-Attention: pespin <pespin(a)sysmocom.de> Gerrit-Attention: fixeria <vyanitskiy(a)sysmocom.de> Gerrit-MessageType: newpatchset

1 year, 4 months

1
0
0 0

2025

2024

2023

2022

gerrit-log March 2024