https://osmocom.org/https://osmocom.org/favicon.ico?16647414092018-02-22T00:40:52ZOpen Source Mobile CommunicationsOsmoMSC - Bug #2980: in bssmap_rx_l3_compl(), we decode the L3-complete MCC-MNC but never verify their actual valuehttps://osmocom.org/issues/2980?journal_id=77362018-02-22T00:40:52Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>related, the VLR accepts any LAI (MCC-MNC-LAC), see vlr_lu_fsm.c:</p>
<pre>
/* Determine if given location area is served by this VLR */
static bool lai_in_this_vlr(struct vlr_instance *vlr,
const struct osmo_location_area_id *lai)
{
/* TODO: VLR needs to keep a locally configued list of LAIs */
return true;
}
</pre> OsmoMSC - Bug #2980: in bssmap_rx_l3_compl(), we decode the L3-complete MCC-MNC but never verify their actual valuehttps://osmocom.org/issues/2980?journal_id=77372018-02-22T00:46:17Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>vlr_proc_acc_req() stores a LAI in struct proc_arq_priv but it is never used.</p> OsmoMSC - Bug #2980: in bssmap_rx_l3_compl(), we decode the L3-complete MCC-MNC but never verify their actual valuehttps://osmocom.org/issues/2980?journal_id=78972018-02-27T08:25:21Zlaforge
<ul></ul><p>We shouldn't allow arbitrary non matching MCC/MNC. Please add a ttcn3 test for it whose failure wil be a reminder</p> OsmoMSC - Bug #2980: in bssmap_rx_l3_compl(), we decode the L3-complete MCC-MNC but never verify their actual valuehttps://osmocom.org/issues/2980?journal_id=79452018-03-01T23:07:24Zlaforge
<ul><li><strong>Assignee</strong> set to <i>stsp</i></li></ul> OsmoMSC - Bug #2980: in bssmap_rx_l3_compl(), we decode the L3-complete MCC-MNC but never verify their actual valuehttps://osmocom.org/issues/2980?journal_id=82482018-03-15T15:49:26Zstsp
<ul></ul><p>I have written a small test case:</p>
<pre>
private const Cell_Identity unknown_cid := { '678'H, 'f90'H, 1, 0 };
/* Paging by CGI with unknown MCC/MNC: Verify nothing is paged. */
testcase TC_paging_imsi_nochan_cgi_unknown_cid() runs on test_CT {
var template BSSMAP_FIELD_CellIdentificationList cid_list;
cid_list := { cIl_CGI := { ts_BSSMAP_CI_CGI(unknown_cid.mcc, unknown_cid.mnc, unknown_cid.lac, unknown_cid.ci) } };
f_pageing_helper('001010000000006'H, cid_list, c_BtsId_none);
f_shutdown_helper();
}
</pre>
<p>However, I cannot verify it because my ttcn3 setup no longer works. It keeps failing with<br /><pre>Dynamic test case error: Port IPA_CTRL has neither connections nor mappings. Message cannot be sent on it.</pre><br />The same problem started happening on jenkins in ttcn3-hacks build #109: <a class="external" href="https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/109/consoleText">https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/109/consoleText</a></p>
<p>I might eventually need support to figure this out to make progress on this issue.<br />I have been trying to figure out the problem but haven't gotten anywhere.</p> OsmoMSC - Bug #2980: in bssmap_rx_l3_compl(), we decode the L3-complete MCC-MNC but never verify their actual valuehttps://osmocom.org/issues/2980?journal_id=82492018-03-15T15:53:47Zstsp
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul> OsmoMSC - Bug #2980: in bssmap_rx_l3_compl(), we decode the L3-complete MCC-MNC but never verify their actual valuehttps://osmocom.org/issues/2980?journal_id=83802018-03-20T14:56:19Zstsp
<ul></ul><p>Regression test proposed in <a class="external" href="https://gerrit.osmocom.org/#/c/7403/">https://gerrit.osmocom.org/#/c/7403/</a></p> OsmoMSC - Bug #2980: in bssmap_rx_l3_compl(), we decode the L3-complete MCC-MNC but never verify their actual valuehttps://osmocom.org/issues/2980?journal_id=84322018-03-22T11:45:51Zstsp
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li></ul><p>Above change has been merged. Looks like we're all good now.</p> OsmoMSC - Bug #2980: in bssmap_rx_l3_compl(), we decode the L3-complete MCC-MNC but never verify their actual valuehttps://osmocom.org/issues/2980?journal_id=84412018-03-22T13:20:05Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>New</i></li></ul><p>Sorry, but this issue is not about paging and not about ttcn3, it is about l3_compl and the VLR,<br />i.e. when a subscriber comes in with a LU, CM Service Request or a paging <strong>response</strong>, that we look at what PLMN it is sending along.<br />I'm not actually entirely sure of the meaning of the PLMN sent in those l3 compl messages:<br />if it's just the SIM card's home PLMN we may not need to validate it at all.<br />The VLR has a comment that we need a local list of LAIs managed by the VLR...<br />This issue is thus about clarifying those questions and actually implementing things in our code base if needed.<br />Reopening.</p> OsmoMSC - Bug #2980: in bssmap_rx_l3_compl(), we decode the L3-complete MCC-MNC but never verify their actual valuehttps://osmocom.org/issues/2980?journal_id=88352018-04-12T09:46:19Zstsp
<ul></ul><p>For Location Update Requests, the value is obtained from the SIM:</p>
<p>(GSM 04.08)</p>
<blockquote>
<p>9.2.15.1 Location area identification<br />The location area identification stored in the SIM is used.</p>
</blockquote>
<p>CM Service Requests do not contain a PLMN.<br />The LAI is derived from the subscriber connection in libmsc/gsm_04_08.c:gsm48_rx_mm_serv_req().</p>
<p>Paging responses do not contain a PLMN either.<br />The LAI is derived from the subscriber connection in libmsc/gsm_04_08.c:gsm48_rx_mm_pag_resp().</p>
<p>Does this information help?</p> OsmoMSC - Bug #2980: in bssmap_rx_l3_compl(), we decode the L3-complete MCC-MNC but never verify their actual valuehttps://osmocom.org/issues/2980?journal_id=88362018-04-12T09:49:20Zstsp
<ul></ul><p>Additionally, vlr_proc_acc_req() receives a LAI but does nothing with it.</p> OsmoMSC - Bug #2980: in bssmap_rx_l3_compl(), we decode the L3-complete MCC-MNC but never verify their actual valuehttps://osmocom.org/issues/2980?journal_id=88382018-04-12T13:04:32Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li></ul><p>I notice that this patch of yours <a class="external" href="https://gerrit.osmocom.org/#/c/7281/">https://gerrit.osmocom.org/#/c/7281/</a> actually fixes the part in bssmap_rx_l3_compl() to match the cell identifier to the network's PLMN. That's certainly interesting to note here.</p>
<p>The open question is whether we want to validate that the SIM card's PLMN matches the current network.<br />I assume "disallow mismatching PLMN" vs. "allow this list of PLMN" vs. "allow all PLMN".<br />Adding this feature is certainly not urgent. A nice thing to do would be to log the mismatch, but then again we also log the IMSI all the time...</p>
<p>Slightly confusing here is that I've created the issue to talk about two completely separate aspects,</p>
<ul>
<li>one is the cell identity of the BSC/RNC during L3 complete,</li>
<li>and the other is the SIM card's PLMN to be validated in the VLR.</li>
</ul>
<p>Remaining now is the SIM<->VLR part.<br />So, do we have a SIM <-> Network PLMN mismatch test in ttcn3 yet?</p> OsmoMSC - Bug #2980: in bssmap_rx_l3_compl(), we decode the L3-complete MCC-MNC but never verify their actual valuehttps://osmocom.org/issues/2980?journal_id=88532018-04-12T15:15:48Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>Feedback</i> to <i>Rejected</i></li></ul><p>To avoid cross-discussing separate issues, I've created the following issues to replace this one:<br /><a class="issue tracker-1 status-3 priority-1 priority-lowest closed" title="Bug: BSSMAP: reject Level 3 Complete from cells with invalid LAI (Resolved)" href="https://osmocom.org/issues/3162">#3162</a> <a class="issue tracker-1 status-1 priority-1 priority-lowest" title="Bug: RANAP: reject Level 3 Complete from cells with invalid LAI (New)" href="https://osmocom.org/issues/3163">#3163</a> <a class="issue tracker-1 status-4 priority-1 priority-lowest" title="Bug: invalid LAI in level 3 complete: unify BSSMAP and RANAP verification (Feedback)" href="https://osmocom.org/issues/3164">#3164</a> <a class="issue tracker-2 status-1 priority-1 priority-lowest" title="Feature: Verify LU Request's LAI (New)" href="https://osmocom.org/issues/3165">#3165</a></p>