Cellular Network Infrastructure » Core Network (CN) » OsmoMSC

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.

The configuration for the FSM and this state is here:

https://git.osmocom.org/osmo-msc/tree/src/libvlr/vlr_lu_fsm.c?id=47cf84d8d7ab76cba5cc9da7305ef34ea5cbd1ea#n1401

One could add VLR_ULA_E_ID_IMEISV there, but I am not sure if this is the proper fix.

What are the settings for check imei?

The vlr_lu_fsm.c was has a code path where we explicitly ask for an IMEI[SV] and wait for an answer.
This error message above happens when the MS sends an IMEI[SV] I guess of its own accord, I assume before we expect it.
When the IMEI[SV] identity comes in, we do always store it in the vlr_subscr, see vlr_subscr_rx_id_resp().
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?

Optional: add the event to state VLR_ULA_S_WAIT_HLR_UPD so that there is no error message:

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

What are the settings for check imei?

Attaching the config files of both MSC and HLR. Looks like we're using default configuration.

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.

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

fixeria, neels: before too much time passes after the camp: did you guys get a pcap? :)

we've actually already merged https://gerrit.osmocom.org/c/osmo-msc/+/15315

Maybe maybe I can find a pcap on the other laptop...

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)

The questions open for me here:

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?
I'm asking you, osmith, because you know everything about the IMEISV checks against the HLR.

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

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

./msc_vlr_test_no_authen -v 1

neels wrote:

The vlr_lu_fsm.c was has a code path where we explicitly ask for an IMEI[SV] and wait for an answer.
This error message above happens when the MS sends an IMEI[SV] I guess of its own accord, I assume before we expect it.
When the IMEI[SV] identity comes in, we do always store it in the vlr_subscr, see vlr_subscr_rx_id_resp().
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?

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.

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?
I'm asking you, osmith, because you know everything about the IMEISV checks against the HLR.

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.

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.