Project

General

Profile

Bug #3164

invalid LAI in level 3 complete: unify BSSMAP and RANAP verification

Added by neels over 1 year ago. Updated 4 months ago.

Status:
Feedback
Priority:
Low
Assignee:
Category:
-
Target version:
-
Start date:
04/12/2018
Due date:
% Done:

0%

Resolution:

Description

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.)


Related issues

Related to OsmoMSC - Bug #3162: BSSMAP: reject Level 3 Complete from cells with invalid LAIResolved04/12/2018

Related to OsmoMSC - Bug #3163: RANAP: reject Level 3 Complete from cells with invalid LAINew04/12/2018

Related to OsmoMSC - Feature #3165: Verify LU Request's LAINew04/12/2018

History

#1 Updated by neels over 1 year ago

  • Related to Bug #3162: BSSMAP: reject Level 3 Complete from cells with invalid LAI added

#2 Updated by neels over 1 year ago

  • Related to Bug #3163: RANAP: reject Level 3 Complete from cells with invalid LAI added

#3 Updated by neels over 1 year ago

#4 Updated by neels over 1 year 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.

#5 Updated by laforge 5 months ago

  • Status changed from New to Feedback
  • Assignee changed from stsp to neels

still valid?

#6 Updated by neels 4 months 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)