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