invalid LAI in level 3 complete: unify BSSMAP and RANAP verification
So far we determine validity of the PLMN (compared against the global MNC's config) in bssmap_rx_l3_compl() for the A-interface.
<insert status quo of the Iu interface here, see #3163>
However, in the VLR, we have code stubs to accept or deny a given LAI, which always returns acceptance at the moment: lai_in_this_vlr() in vlr_lu_fsm.c.
- Move the PLMN (LAI) check into the VLR, to serve both A and Iu interface L3 Complete requests.
So, instead of verifying in BSSMAP and RANAP rx functions separately, just pass the received LAI onto vlr_lu_fsm.c and compare it centrally there.
As a future perspective, policy on which LAIs are permitted can then be added in the VLR for both these RAN types.
(This issue is created as a split of #2980, to clarify the confusion we created there.)
#4 Updated by neels over 2 years ago
Wait, I might be confusing things here, again. vlr_lu_fsm.c is of course only concerned with Location Updating, not the other Level 3 Complete (Paging Response and CM Service Request).
We also have the vlr_access_req_fsm.c, concerned with the non-LU L3 Complete, which also contains a LAI, which should also be validated.
I guess part of this task is to clarify which PLMN means what exactly and should be handled where.
#6 Updated by neels about 1 year ago
The most central place where all L3 Complete pass through would now be in msc_a_up_l3() in msc_a.c.
However, that function is not the right place to decode LAI from the various L3-Complete messages.
gsm0408_rcv_mm() is still responsible for LU and CM Service Requests, while gsm0408_rcv_rr() is still responsible for Paging Response.
In other words, this issue has not been affected by the refactoring and should still be open.
Probably best to first put up tests to probe the current behavior,
and then add one central function in the VLR that both the vlr_lu_fsm and vlr_access_req_fsm use to validate the received LAI.