fixeria has submitted this change. ( https://gerrit.osmocom.org/c/osmo-ttcn3-hacks/+/36460?usp=email )
Change subject: msc: expand TC_lu_tmsi_noauth_notmsi ......................................................................
msc: expand TC_lu_tmsi_noauth_notmsi
From running this test repeatedly, I noticed that osmo-msc's new patch to avoid storing a TMSI may also trigger more evil twin situations in the VLR as described in OS#4721.
Always run this test twice, to probe for the evil twin problem.
This test will pass from osmo-msc patch Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd on.
Depends: osmo-msc Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd Related: SYS#6860 OS#4721 Change-Id: I5e596597add7d585efd27c850067b8d7ba34ecc0 --- M msc/MSC_Tests.ttcn 1 file changed, 44 insertions(+), 0 deletions(-)
Approvals: neels: Looks good to me, approved pespin: Looks good to me, but someone else must approve Jenkins Builder: Verified
diff --git a/msc/MSC_Tests.ttcn b/msc/MSC_Tests.ttcn index 2923a62..09004e8 100644 --- a/msc/MSC_Tests.ttcn +++ b/msc/MSC_Tests.ttcn @@ -7316,6 +7316,17 @@ f_ran_register_imsi(g_pars.imsi, omit); f_vty_transceive(MSCVTY, "subscriber imsi " & hex2str(g_pars.imsi) & " paging"); f_expect_paging_tmsi(omit); + + /* Respond to paging, to clean up internal paging state for this subscriber, so we can get a clean second run + * out of this test code. Don't use the TMSI in the paging response. */ + f_cl3_or_initial_ue(valueof(ts_PAG_RESP(ts_MI_IMSI_LV(pars.imsi)))); + f_mm_common(); + /* The paging was by VTY, so nothing happens, just a release. */ + f_expect_clear(); + + /* Clean up ttcn state for the second test run to work out. */ + f_unregister_gsup_imsi(hex2str(pars.imsi)); + f_ran_unregister_imsi(pars.imsi); } testcase TC_lu_tmsi_noauth_notmsi() runs on MTC_CT { var BSC_ConnHdlrPars pars; @@ -7328,6 +7339,19 @@ pars.mm_info := false; vc_conn := f_start_handler_with_pars(refers(f_tc_lu_tmsi_noauth_notmsi), pars); vc_conn.done; + + /* Now run the same test *again*, to test against an evil twin VLR entry: + * A vlr_subscr with the correct IMSI is now present in the VLR. + * We again ask for a LU with the 0x0bad TMSI. The VLR will initially create another vlr_subsrc(TMSI=0x0bad). + * When it learns the IMSI via ID Request, it needs to realize that this IMSI is already present on the first + * vsub, and sort out the VLR record so that only one entry for this IMSI exists. + */ + pars := f_init_pars(101); + pars.net.expect_tmsi := false; + pars.tmsi := '0badbad0'O; + pars.mm_info := false; + vc_conn := f_start_handler_with_pars(refers(f_tc_lu_tmsi_noauth_notmsi), pars); + vc_conn.done; }
control {