tree 8cab8b7a6ac0e08746af4847278eb56388400dec
parent 72ef7d8bb07bc4e938a242bfdd9d0e45f77fc917
author Neels Hofmeyr <nhofmeyr@sysmocom.de> 1711410604 +0100
committer Neels Hofmeyr <nhofmeyr@sysmocom.de> 1711595218 +0100

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