https://osmocom.org/https://osmocom.org/favicon.ico?16647414092019-08-22T13:31:13ZOpen Source Mobile CommunicationsOsmoMSC - Bug #4167: Event VLR_ULA_E_ID_IMEISV not permittedhttps://osmocom.org/issues/4167?journal_id=156722019-08-22T13:31:13Zosmith
<ul></ul><p>This means that the vlr_lu_fsm is currently in the VLR_ULA_S_WAIT_HLR_UPD state, and it is not allowed to dispatch an VLR_ULA_E_ID_IMEISV event in this state.</p>
<p>The configuration for the FSM and this state is here:</p>
<p><a class="external" href="https://git.osmocom.org/osmo-msc/tree/src/libvlr/vlr_lu_fsm.c?id=47cf84d8d7ab76cba5cc9da7305ef34ea5cbd1ea#n1401">https://git.osmocom.org/osmo-msc/tree/src/libvlr/vlr_lu_fsm.c?id=47cf84d8d7ab76cba5cc9da7305ef34ea5cbd1ea#n1401</a></p>
<p>One could add VLR_ULA_E_ID_IMEISV there, but I am not sure if this is the proper fix.</p>
<p>What are the settings for check imei?</p> OsmoMSC - Bug #4167: Event VLR_ULA_E_ID_IMEISV not permittedhttps://osmocom.org/issues/4167?journal_id=156742019-08-22T13:50:36Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>The vlr_lu_fsm.c was has a code path where we explicitly ask for an IMEI[SV] and wait for an answer.<br />This error message above happens when the MS sends an IMEI[SV] I guess of its own accord, I assume before we expect it.<br />When the IMEI[SV] identity comes in, we do always store it in the vlr_subscr, see vlr_subscr_rx_id_resp().<br />What we need to check for this issue is: if the IMEI[SV] is already stored in the vlr_subscr, do we still send it to the HLR?</p>
<p>Optional: add the event to state VLR_ULA_S_WAIT_HLR_UPD so that there is no error message:<br /><pre>
--- a/src/libvlr/vlr_lu_fsm.c
+++ b/src/libvlr/vlr_lu_fsm.c
@@ -1234,6 +1234,10 @@ static void lu_fsm_wait_hlr_ul_res(struct osmo_fsm_inst *fi, uint32_t event,
}
}
break;
+ case VLR_ULA_E_ID_IMEI:
+ case VLR_ULA_E_ID_IMEISV:
+ /* Got the IMEI from ME, nothing to do right now though. */
+ break;
default:
OSMO_ASSERT(0);
break;
@@ -1400,7 +1404,9 @@ static const struct osmo_fsm_state vlr_lu_fsm_states[] = {
},
[VLR_ULA_S_WAIT_HLR_UPD] = {
.in_event_mask = S(VLR_ULA_E_HLR_LU_RES) |
- S(VLR_ULA_E_UPD_HLR_COMPL),
+ S(VLR_ULA_E_UPD_HLR_COMPL) |
+ S(VLR_ULA_E_ID_IMEI) |
+ S(VLR_ULA_E_ID_IMEISV),
.out_state_mask = S(VLR_ULA_S_WAIT_LU_COMPL) |
S(VLR_ULA_S_WAIT_LU_COMPL_STANDALONE) |
S(VLR_ULA_S_DONE),
</pre></p> OsmoMSC - Bug #4167: Event VLR_ULA_E_ID_IMEISV not permittedhttps://osmocom.org/issues/4167?journal_id=156752019-08-22T13:53:20Zfixeria
<ul><li><strong>File</strong> <a href="/attachments/3836">osmo-msc.cfg</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3836/osmo-msc.cfg">osmo-msc.cfg</a> added</li><li><strong>File</strong> <a href="/attachments/3837">osmo-hlr.cfg</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3837/osmo-hlr.cfg">osmo-hlr.cfg</a> added</li></ul><blockquote>
<p>What are the settings for check imei?</p>
</blockquote>
<p>Attaching the config files of both MSC and HLR. Looks like we're using default configuration.</p> OsmoMSC - Bug #4167: Event VLR_ULA_E_ID_IMEISV not permittedhttps://osmocom.org/issues/4167?journal_id=156812019-08-22T22:53:11Zneelsnhofmeyr@sysmocom.de
<ul></ul><p>this actually happens if the Ciphering Mode Complete contains the IMEISV; so we didn't ask for an IMEISV in a separate ID Request, just told the Ciphering Command to include an IMEISV in its response. So we're not explicitly waiting for an IMEISV ID event, it's just a side effect of the Ciphering.</p> OsmoMSC - Bug #4167: Event VLR_ULA_E_ID_IMEISV not permittedhttps://osmocom.org/issues/4167?journal_id=156822019-08-23T06:13:51Zosmith
<ul></ul><p>Would it be possible to get a pcap? Then I could add a TTCN3 test that reproduces this behavior, and adjust the OsmoMSC code like <a class="user active" href="https://osmocom.org/users/91">neels</a> described above. Without a pcap, the test could also be added, but it would me more of a guess what the MS is doing instead of being based on real data.</p> OsmoMSC - Bug #4167: Event VLR_ULA_E_ID_IMEISV not permittedhttps://osmocom.org/issues/4167?journal_id=157132019-08-27T06:37:40Zosmith
<ul></ul><p><a class="user active" href="https://osmocom.org/users/67">fixeria</a>, <a class="user active" href="https://osmocom.org/users/91">neels</a>: before too much time passes after the camp: did you guys get a pcap? :)</p> OsmoMSC - Bug #4167: Event VLR_ULA_E_ID_IMEISV not permittedhttps://osmocom.org/issues/4167?journal_id=157952019-09-03T15:21:50Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Feedback</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>70</i></li></ul><p>we've actually already merged <a class="external" href="https://gerrit.osmocom.org/c/osmo-msc/+/15315">https://gerrit.osmocom.org/c/osmo-msc/+/15315</a></p>
<p>Maybe maybe I can find a pcap on the other laptop...</p>
<p>What the MS is doing is sending an Identity Response (IMEISV) in-between having sent the GSUP LU Request and having received back the GSUP Update Location Result from the HLR. I'm not entirely sure why that would happen... (if we can't figure it out we should know at the latest in december at congress)</p>
<p>The questions open for me here:</p>
<p>If the subscriber-create-on-demand stuff is enabled (check-imei-rqd?), then would everything still work out correctly even if the IMEISV is received at this weird point in time? Would it skip some later ID Request action automagically? Does this question even make sense?<br />I'm asking you, <a class="user active" href="https://osmocom.org/users/301771">osmith</a>, because you know everything about the IMEISV checks against the HLR.</p>
<p>I've quickly modeled an msc_vlr_test to place an ID Response at the time described, but that doesn't make much sense without any handling of the IMEISV. Maybe you can find a more appropriate test case or adopt that into ttcn3...?</p>
<pre>
--- a/tests/msc_vlr/msc_vlr_test_no_authen.c
+++ b/tests/msc_vlr/msc_vlr_test_no_authen.c
@@ -51,6 +51,9 @@ static void test_no_authen()
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
+ btw("MS sends (unexpected) Identity Response");
+ ms_sends_msg("0559084a32244332244302");
+
btw("HLR also sends GSUP _UPDATE_LOCATION_RESULT");
expect_bssap_clear();
gsup_rx("06010809710000004026f0" HLR_TO_VLR, NULL);
</pre>
<pre>
./msc_vlr_test_no_authen -v 1
</pre> OsmoMSC - Bug #4167: Event VLR_ULA_E_ID_IMEISV not permittedhttps://osmocom.org/issues/4167?journal_id=157972019-09-04T07:37:27Zosmith
<ul></ul><p>neels wrote:</p>
<blockquote>
<p>The vlr_lu_fsm.c was has a code path where we explicitly ask for an IMEI[SV] and wait for an answer.<br />This error message above happens when the MS sends an IMEI[SV] I guess of its own accord, I assume before we expect it.<br />When the IMEI[SV] identity comes in, we do always store it in the vlr_subscr, see vlr_subscr_rx_id_resp().<br />What we need to check for this issue is: if the IMEI[SV] is already stored in the vlr_subscr, do we still send it to the HLR?</p>
</blockquote>
<p>Yes, we still send it. If the IMEI[SV] gets received unexpectedly, the value gets updated in the VLR (and not sent immediately to the HLR). When we do want to send it to the HLR at a later point ("check-imei-rqd early": before LU, "check-imei-rqd 1": during LU), we just use the latest value saved in the VLR.</p>
<blockquote>
<p>If the subscriber-create-on-demand stuff is enabled (check-imei-rqd?), then would everything still work out correctly even if the IMEISV is received at this weird point in time? Would it skip some later ID Request action automagically? Does this question even make sense?<br />I'm asking you, osmith, because you know everything about the IMEISV checks against the HLR.</p>
</blockquote>
<p>My understanding is, that we should not run into problems here. It should simply send the last IMEI that is stored in the VLR, and possibly it might even ask the phone again for the IMEI[SV] and wait until it is received again. But to be sure, I can make a TTCN-3 test. There are already a few check-imei-rqd related MSC tests, so this should be rather easy.</p> OsmoMSC - Bug #4167: Event VLR_ULA_E_ID_IMEISV not permittedhttps://osmocom.org/issues/4167?journal_id=158662019-09-04T20:13:55Zneelsnhofmeyr@sysmocom.de
<ul><li><strong>File</strong> <a href="/attachments/3849">imeisv_not_permitted_short.pcapng</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/3849/imeisv_not_permitted_short.pcapng">imeisv_not_permitted_short.pcapng</a> added</li></ul><p>found a pcap, tried to filter and shorten to only get one subscriber's packets. It's complete with gsmtap_log, so you should be able to search for "not permitted" in (gsmtap_log enabled) wireshark and get the full picture.</p>