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

1 files changed, 2 insertions, 0 deletions

diff --git a/include/osmocom/msc/vlr.h b/include/osmocom/msc/vlr.h
index 86a72f203..a7707fd01 100644
--- a/include/osmocom/msc/vlr.h
+++ b/include/osmocom/msc/vlr.h
@@ -257,6 +257,8 @@ struct vlr_ops {
 	/* 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 */