2017-01-25 14:04:16 +00:00
|
|
|
/* Osmocom MSC+VLR end-to-end tests */
|
|
|
|
|
|
|
|
|
|
/* (C) 2017 by sysmocom s.f.m.c. GmbH <info@sysmocom.de>
|
|
|
|
|
*
|
|
|
|
|
* All Rights Reserved
|
|
|
|
|
*
|
|
|
|
|
* Author: Neels Hofmeyr <nhofmeyr@sysmocom.de>
|
|
|
|
|
*
|
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
|
* it under the terms of the GNU Affero General Public License as published by
|
|
|
|
|
* the Free Software Foundation; either version 3 of the License, or
|
|
|
|
|
* (at your option) any later version.
|
|
|
|
|
*
|
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
|
* GNU Affero General Public License for more details.
|
|
|
|
|
*
|
|
|
|
|
* You should have received a copy of the GNU Affero General Public License
|
|
|
|
|
* along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
|
*
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include "msc_vlr_tests.h"
|
2018-12-03 10:00:04 +00:00
|
|
|
#include "stubs.h"
|
2017-01-25 14:04:16 +00:00
|
|
|
|
2018-03-02 00:05:38 +00:00
|
|
|
static void test_ms_timeout_lu_auth_resp()
|
2017-01-25 14:04:16 +00:00
|
|
|
{
|
2018-03-01 23:40:58 +00:00
|
|
|
comment_start();
|
2017-01-25 14:04:16 +00:00
|
|
|
|
|
|
|
|
net->authentication_required = true;
|
|
|
|
|
|
|
|
|
|
fake_time_start();
|
|
|
|
|
|
|
|
|
|
btw("Location Update request causes a GSUP Send Auth Info request to HLR");
|
|
|
|
|
lu_result_sent = RES_NONE;
|
|
|
|
|
gsup_expect_tx("08010809710000004026f0");
|
|
|
|
|
ms_sends_msg("050802008168000130089910070000006402");
|
|
|
|
|
OSMO_ASSERT(gsup_tx_confirmed);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
|
|
|
|
|
btw("from HLR, rx _SEND_AUTH_INFO_RESULT; VLR sends Auth Req to MS");
|
|
|
|
|
auth_request_sent = false;
|
|
|
|
|
auth_request_expect_rand = "585df1ae287f6e273dce07090d61320b";
|
|
|
|
|
auth_request_expect_autn = NULL;
|
|
|
|
|
/* Based on a Ki of 000102030405060708090a0b0c0d0e0f */
|
|
|
|
|
gsup_rx("0a"
|
|
|
|
|
/* imsi */
|
|
|
|
|
"0108" "09710000004026f0"
|
|
|
|
|
/* auth vectors... */
|
|
|
|
|
/* TL TL rand */
|
|
|
|
|
"0322" "2010" "585df1ae287f6e273dce07090d61320b"
|
|
|
|
|
/* TL sres TL kc */
|
|
|
|
|
"2104" "2d8b2c3e" "2208" "61855fb81fc2a800"
|
|
|
|
|
,NULL);
|
|
|
|
|
VERBOSE_ASSERT(auth_request_sent, == true, "%d");
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
|
|
|
|
|
BTW("MS fails to send an Authentication Response");
|
|
|
|
|
|
|
|
|
|
btw("At first, we're still waiting");
|
|
|
|
|
fake_time_passes(0, 423);
|
|
|
|
|
EXPECT_CONN_COUNT(1);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
fake_time_passes(1, 235);
|
|
|
|
|
EXPECT_CONN_COUNT(1);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
fake_time_passes(1, 235);
|
|
|
|
|
EXPECT_CONN_COUNT(1);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
fake_time_passes(1, 235);
|
|
|
|
|
EXPECT_CONN_COUNT(1);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
fake_time_passes(1, 235);
|
|
|
|
|
EXPECT_CONN_COUNT(1);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
2017-04-09 10:32:51 +00:00
|
|
|
expect_bssap_clear();
|
2017-01-25 14:04:16 +00:00
|
|
|
fake_time_passes(1, 235);
|
rename gsm_subscriber_connection to ran_conn
In preparation for inter-BSC and inter-MSC handover, we need to separate the
subscriber management logic from the actual RAN connections. What better time
to finally rename gsm_subscriber_connection.
* Name choice:
In 2G, this is a connection to the BSS, but even though 3GPP TS commonly talk
of "BSS-A" and "BSS-B" when explaining handover, it's not good to call it
"bss_conn": in 3G a BSS is called RNS, IIUC.
The overall term for 2G (GERAN) and 3G (UTRAN) is RAN: Radio Access Network.
* Rationale:
A subscriber in the MSC so far has only one RAN connection, but e.g. for
inter-BSC handover, a second one needs to be created to handover to. Most of
the items in the former gsm_subscriber_connection are actually related to the
RAN, with only a few MM and RTP related items. So, as a first step, just rename
it to ran_conn, to cosmetically prepare for moving the not strictly RAN related
items away later.
Also:
- Rename some functions from msc_subscr_conn_* to ran_conn_*
- Rename "Subscr_Conn" FSM instance name to "RAN_conn"
- Rename SUBSCR_CONN_* to RAN_CONN_*
Change-Id: Ic595f7a558d3553c067f77dc67543ab59659707a
2018-11-29 21:37:51 +00:00
|
|
|
btw("RAN_CONN_TIMEOUT has passed, conn is gone.");
|
2017-04-09 10:32:51 +00:00
|
|
|
VERBOSE_ASSERT(bssap_clear_sent, == true, "%d");
|
2018-04-01 18:55:54 +00:00
|
|
|
bss_sends_clear_complete();
|
2017-01-25 14:04:16 +00:00
|
|
|
EXPECT_CONN_COUNT(0);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_REJECT, "%d");
|
|
|
|
|
|
2018-03-01 23:40:58 +00:00
|
|
|
comment_end();
|
2017-01-25 14:04:16 +00:00
|
|
|
}
|
|
|
|
|
|
2018-03-02 00:05:38 +00:00
|
|
|
static void test_ms_timeout_cm_auth_resp()
|
2017-01-25 14:04:16 +00:00
|
|
|
{
|
2018-03-01 23:40:58 +00:00
|
|
|
comment_start();
|
2017-01-25 14:04:16 +00:00
|
|
|
|
|
|
|
|
net->authentication_required = true;
|
|
|
|
|
|
|
|
|
|
fake_time_start();
|
|
|
|
|
|
|
|
|
|
btw("Location Update request causes a GSUP Send Auth Info request to HLR");
|
|
|
|
|
lu_result_sent = RES_NONE;
|
|
|
|
|
gsup_expect_tx("08010809710000004026f0");
|
|
|
|
|
ms_sends_msg("050802008168000130089910070000006402");
|
|
|
|
|
OSMO_ASSERT(gsup_tx_confirmed);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
|
|
|
|
|
btw("from HLR, rx _SEND_AUTH_INFO_RESULT; VLR sends Auth Req to MS");
|
|
|
|
|
auth_request_sent = false;
|
|
|
|
|
auth_request_expect_rand = "585df1ae287f6e273dce07090d61320b";
|
|
|
|
|
auth_request_expect_autn = NULL;
|
|
|
|
|
/* Based on a Ki of 000102030405060708090a0b0c0d0e0f */
|
|
|
|
|
gsup_rx("0a"
|
|
|
|
|
/* imsi */
|
|
|
|
|
"0108" "09710000004026f0"
|
|
|
|
|
/* 5 auth vectors... */
|
|
|
|
|
/* TL TL rand */
|
|
|
|
|
"0322" "2010" "585df1ae287f6e273dce07090d61320b"
|
|
|
|
|
/* TL sres TL kc */
|
|
|
|
|
"2104" "2d8b2c3e" "2208" "61855fb81fc2a800"
|
|
|
|
|
"0322" "2010" "12aca96fb4ffdea5c985cbafa9b6e18b"
|
|
|
|
|
"2104" "20bde240" "2208" "07fa7502e07e1c00"
|
|
|
|
|
"0322" "2010" "e7c03ba7cf0e2fde82b2dc4d63077d42"
|
|
|
|
|
"2104" "a29514ae" "2208" "e2b234f807886400"
|
|
|
|
|
"0322" "2010" "fa8f20b781b5881329d4fea26b1a3c51"
|
|
|
|
|
"2104" "5afc8d72" "2208" "2392f14f709ae000"
|
|
|
|
|
"0322" "2010" "0fd4cc8dbe8715d1f439e304edfd68dc"
|
|
|
|
|
"2104" "bc8d1c5b" "2208" "da7cdd6bfe2d7000",
|
|
|
|
|
NULL);
|
|
|
|
|
VERBOSE_ASSERT(auth_request_sent, == true, "%d");
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
|
|
|
|
|
btw("MS sends Authen Response, VLR accepts and sends GSUP LU Req to HLR");
|
2018-09-28 00:41:39 +00:00
|
|
|
gsup_expect_tx("04010809710000004026f0280102");
|
2017-01-25 14:04:16 +00:00
|
|
|
ms_sends_msg("05542d8b2c3e");
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
|
|
|
|
|
btw("HLR sends _INSERT_DATA_REQUEST, VLR responds with _INSERT_DATA_RESULT");
|
|
|
|
|
gsup_rx("10010809710000004026f00804036470f1",
|
|
|
|
|
"12010809710000004026f0");
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
|
|
|
|
|
btw("HLR also sends GSUP _UPDATE_LOCATION_RESULT");
|
2017-04-09 10:32:51 +00:00
|
|
|
expect_bssap_clear();
|
2017-01-25 14:04:16 +00:00
|
|
|
gsup_rx("06010809710000004026f0", NULL);
|
2017-04-09 10:32:51 +00:00
|
|
|
VERBOSE_ASSERT(bssap_clear_sent, == true, "%d");
|
2017-01-25 14:04:16 +00:00
|
|
|
|
|
|
|
|
btw("LU was successful, and the conn has already been closed");
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_ACCEPT, "%d");
|
2018-04-01 18:55:54 +00:00
|
|
|
bss_sends_clear_complete();
|
2017-01-25 14:04:16 +00:00
|
|
|
EXPECT_CONN_COUNT(0);
|
|
|
|
|
|
|
|
|
|
BTW("after a while, a new conn sends a CM Service Request. VLR responds with Auth Req, 2nd auth vector");
|
|
|
|
|
auth_request_sent = false;
|
|
|
|
|
auth_request_expect_rand = "12aca96fb4ffdea5c985cbafa9b6e18b";
|
|
|
|
|
cm_service_result_sent = RES_NONE;
|
|
|
|
|
ms_sends_msg("05247803305886089910070000006402");
|
|
|
|
|
OSMO_ASSERT(g_conn);
|
2018-03-31 16:45:59 +00:00
|
|
|
OSMO_ASSERT(g_conn->fi);
|
2017-01-25 14:04:16 +00:00
|
|
|
OSMO_ASSERT(g_conn->vsub);
|
|
|
|
|
VERBOSE_ASSERT(cm_service_result_sent, == RES_NONE, "%d");
|
|
|
|
|
VERBOSE_ASSERT(auth_request_sent, == true, "%d");
|
|
|
|
|
|
|
|
|
|
BTW("MS fails to send an Authentication Response");
|
|
|
|
|
|
|
|
|
|
btw("At first, we're still waiting");
|
|
|
|
|
fake_time_passes(0, 423);
|
|
|
|
|
EXPECT_CONN_COUNT(1);
|
|
|
|
|
VERBOSE_ASSERT(cm_service_result_sent, == RES_NONE, "%d");
|
|
|
|
|
fake_time_passes(1, 235);
|
|
|
|
|
EXPECT_CONN_COUNT(1);
|
|
|
|
|
VERBOSE_ASSERT(cm_service_result_sent, == RES_NONE, "%d");
|
|
|
|
|
fake_time_passes(1, 235);
|
|
|
|
|
EXPECT_CONN_COUNT(1);
|
|
|
|
|
VERBOSE_ASSERT(cm_service_result_sent, == RES_NONE, "%d");
|
|
|
|
|
fake_time_passes(1, 235);
|
|
|
|
|
EXPECT_CONN_COUNT(1);
|
|
|
|
|
VERBOSE_ASSERT(cm_service_result_sent, == RES_NONE, "%d");
|
|
|
|
|
fake_time_passes(1, 235);
|
|
|
|
|
EXPECT_CONN_COUNT(1);
|
|
|
|
|
VERBOSE_ASSERT(cm_service_result_sent, == RES_NONE, "%d");
|
2017-04-09 10:32:51 +00:00
|
|
|
expect_bssap_clear();
|
2017-01-25 14:04:16 +00:00
|
|
|
fake_time_passes(1, 235);
|
rename gsm_subscriber_connection to ran_conn
In preparation for inter-BSC and inter-MSC handover, we need to separate the
subscriber management logic from the actual RAN connections. What better time
to finally rename gsm_subscriber_connection.
* Name choice:
In 2G, this is a connection to the BSS, but even though 3GPP TS commonly talk
of "BSS-A" and "BSS-B" when explaining handover, it's not good to call it
"bss_conn": in 3G a BSS is called RNS, IIUC.
The overall term for 2G (GERAN) and 3G (UTRAN) is RAN: Radio Access Network.
* Rationale:
A subscriber in the MSC so far has only one RAN connection, but e.g. for
inter-BSC handover, a second one needs to be created to handover to. Most of
the items in the former gsm_subscriber_connection are actually related to the
RAN, with only a few MM and RTP related items. So, as a first step, just rename
it to ran_conn, to cosmetically prepare for moving the not strictly RAN related
items away later.
Also:
- Rename some functions from msc_subscr_conn_* to ran_conn_*
- Rename "Subscr_Conn" FSM instance name to "RAN_conn"
- Rename SUBSCR_CONN_* to RAN_CONN_*
Change-Id: Ic595f7a558d3553c067f77dc67543ab59659707a
2018-11-29 21:37:51 +00:00
|
|
|
btw("RAN_CONN_TIMEOUT has passed, conn is gone.");
|
2017-04-09 10:32:51 +00:00
|
|
|
VERBOSE_ASSERT(bssap_clear_sent, == true, "%d");
|
2018-04-01 18:55:54 +00:00
|
|
|
bss_sends_clear_complete();
|
2017-01-25 14:04:16 +00:00
|
|
|
EXPECT_CONN_COUNT(0);
|
|
|
|
|
VERBOSE_ASSERT(cm_service_result_sent, == RES_REJECT, "%d");
|
|
|
|
|
|
|
|
|
|
clear_vlr();
|
2018-03-01 23:40:58 +00:00
|
|
|
comment_end();
|
2017-01-25 14:04:16 +00:00
|
|
|
}
|
|
|
|
|
|
2018-03-02 00:05:38 +00:00
|
|
|
static void test_ms_timeout_paging()
|
fix paging: add timeout to discard unsuccessful paging
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
2017-12-15 02:02:27 +00:00
|
|
|
{
|
|
|
|
|
struct vlr_subscr *vsub;
|
2018-03-01 23:40:58 +00:00
|
|
|
const char *imsi = "901700000004620";
|
fix paging: add timeout to discard unsuccessful paging
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
2017-12-15 02:02:27 +00:00
|
|
|
|
2018-12-25 23:40:18 +00:00
|
|
|
rx_from_ran = OSMO_RAT_GERAN_A;
|
fix paging: add timeout to discard unsuccessful paging
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
2017-12-15 02:02:27 +00:00
|
|
|
|
2018-03-01 23:40:58 +00:00
|
|
|
comment_start();
|
fix paging: add timeout to discard unsuccessful paging
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
2017-12-15 02:02:27 +00:00
|
|
|
|
|
|
|
|
fake_time_start();
|
|
|
|
|
|
|
|
|
|
btw("Location Update request causes a GSUP LU request to HLR");
|
|
|
|
|
lu_result_sent = RES_NONE;
|
2018-09-28 00:41:39 +00:00
|
|
|
gsup_expect_tx("04010809710000004026f0280102");
|
fix paging: add timeout to discard unsuccessful paging
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
2017-12-15 02:02:27 +00:00
|
|
|
ms_sends_msg("050802008168000130089910070000006402");
|
|
|
|
|
OSMO_ASSERT(gsup_tx_confirmed);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
|
|
|
|
|
btw("HLR sends _INSERT_DATA_REQUEST, VLR responds with _INSERT_DATA_RESULT");
|
|
|
|
|
gsup_rx("10010809710000004026f00804036470f1",
|
|
|
|
|
"12010809710000004026f0");
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
|
|
|
|
|
btw("HLR also sends GSUP _UPDATE_LOCATION_RESULT");
|
|
|
|
|
expect_bssap_clear();
|
|
|
|
|
gsup_rx("06010809710000004026f0", NULL);
|
|
|
|
|
|
|
|
|
|
btw("LU was successful, and the conn has already been closed");
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_ACCEPT, "%d");
|
|
|
|
|
VERBOSE_ASSERT(bssap_clear_sent, == true, "%d");
|
2018-04-01 18:55:54 +00:00
|
|
|
bss_sends_clear_complete();
|
fix paging: add timeout to discard unsuccessful paging
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
2017-12-15 02:02:27 +00:00
|
|
|
EXPECT_CONN_COUNT(0);
|
|
|
|
|
|
|
|
|
|
BTW("an SMS is sent, MS is paged");
|
|
|
|
|
paging_expect_imsi(imsi);
|
|
|
|
|
paging_sent = false;
|
|
|
|
|
vsub = vlr_subscr_find_by_imsi(net->vlr, imsi);
|
|
|
|
|
OSMO_ASSERT(vsub);
|
|
|
|
|
VERBOSE_ASSERT(llist_count(&vsub->cs.requests), == 0, "%d");
|
|
|
|
|
|
|
|
|
|
send_sms(vsub, vsub,
|
|
|
|
|
"Privacy in residential applications is a desirable"
|
|
|
|
|
" marketing option.");
|
|
|
|
|
|
|
|
|
|
VERBOSE_ASSERT(llist_count(&vsub->cs.requests), == 1, "%d");
|
|
|
|
|
vlr_subscr_put(vsub);
|
|
|
|
|
vsub = NULL;
|
|
|
|
|
VERBOSE_ASSERT(paging_sent, == true, "%d");
|
|
|
|
|
VERBOSE_ASSERT(paging_stopped, == false, "%d");
|
|
|
|
|
|
|
|
|
|
btw("time passes and no paging result is received");
|
|
|
|
|
|
|
|
|
|
fake_time_passes(MSC_PAGING_RESPONSE_TIMER_DEFAULT - 1, 0);
|
|
|
|
|
|
|
|
|
|
btw("the paging timeout has not yet expired");
|
|
|
|
|
VERBOSE_ASSERT(paging_stopped, == false, "%d");
|
|
|
|
|
vsub = vlr_subscr_find_by_imsi(net->vlr, imsi);
|
|
|
|
|
OSMO_ASSERT(vsub);
|
|
|
|
|
VERBOSE_ASSERT(vsub->cs.is_paging, == true, "%d");
|
|
|
|
|
btw("another request is added to the list but does not cause another paging");
|
|
|
|
|
paging_sent = false;
|
|
|
|
|
paging_expect_imsi(NULL);
|
|
|
|
|
send_sms(vsub, vsub,
|
|
|
|
|
"One paging ought to be enough for anyone.");
|
|
|
|
|
VERBOSE_ASSERT(llist_count(&vsub->cs.requests), == 2, "%d");
|
|
|
|
|
vlr_subscr_put(vsub);
|
|
|
|
|
vsub = NULL;
|
|
|
|
|
VERBOSE_ASSERT(paging_sent, == false, "%d");
|
|
|
|
|
|
|
|
|
|
btw("the paging timeout expires, the paging as well as the requests are canceled");
|
|
|
|
|
fake_time_passes(2, 0);
|
|
|
|
|
VERBOSE_ASSERT(paging_stopped, == true, "%d");
|
|
|
|
|
|
|
|
|
|
vsub = vlr_subscr_find_by_imsi(net->vlr, imsi);
|
|
|
|
|
OSMO_ASSERT(vsub);
|
|
|
|
|
VERBOSE_ASSERT(vsub->cs.is_paging, == false, "%d");
|
|
|
|
|
VERBOSE_ASSERT(llist_count(&vsub->cs.requests), == 0, "%d");
|
2017-12-15 02:48:48 +00:00
|
|
|
|
|
|
|
|
BTW("Now that the timeout has expired, another Paging is sent on request");
|
|
|
|
|
paging_expect_imsi(imsi);
|
|
|
|
|
paging_sent = false;
|
|
|
|
|
|
|
|
|
|
send_sms(vsub, vsub,
|
|
|
|
|
"Privacy in residential applications is a desirable"
|
|
|
|
|
" marketing option.");
|
|
|
|
|
|
|
|
|
|
VERBOSE_ASSERT(llist_count(&vsub->cs.requests), == 1, "%d");
|
fix paging: add timeout to discard unsuccessful paging
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
2017-12-15 02:02:27 +00:00
|
|
|
vlr_subscr_put(vsub);
|
|
|
|
|
vsub = NULL;
|
2017-12-15 02:48:48 +00:00
|
|
|
VERBOSE_ASSERT(paging_sent, == true, "%d");
|
|
|
|
|
VERBOSE_ASSERT(paging_stopped, == false, "%d");
|
fix paging: add timeout to discard unsuccessful paging
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
2017-12-15 02:02:27 +00:00
|
|
|
|
2017-12-15 02:48:48 +00:00
|
|
|
BTW("subscriber detaches, pagings are canceled");
|
fix paging: add timeout to discard unsuccessful paging
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
2017-12-15 02:02:27 +00:00
|
|
|
expect_bssap_clear();
|
|
|
|
|
ms_sends_msg("050130089910070000006402");
|
|
|
|
|
VERBOSE_ASSERT(bssap_clear_sent, == true, "%d");
|
2017-12-15 02:48:48 +00:00
|
|
|
VERBOSE_ASSERT(paging_stopped, == true, "%d");
|
fix paging: add timeout to discard unsuccessful paging
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
2017-12-15 02:02:27 +00:00
|
|
|
|
|
|
|
|
vsub = vlr_subscr_find_by_imsi(net->vlr, imsi);
|
|
|
|
|
OSMO_ASSERT(!vsub);
|
|
|
|
|
|
2018-04-01 18:55:54 +00:00
|
|
|
bss_sends_clear_complete();
|
fix paging: add timeout to discard unsuccessful paging
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
2017-12-15 02:02:27 +00:00
|
|
|
EXPECT_CONN_COUNT(0);
|
|
|
|
|
clear_vlr();
|
2018-03-01 23:40:58 +00:00
|
|
|
comment_end();
|
fix paging: add timeout to discard unsuccessful paging
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
2017-12-15 02:02:27 +00:00
|
|
|
}
|
|
|
|
|
|
A5/n Ciph: request Classmark Update if missing
When the VLR requests a Ciphering Mode with vlr_ops.set_ciph_mode(), and if we
need a ciph algo flag from a Classmark information that is not yet known
(usually CM 2 during LU), send a BSSMAP Classmark Request to get it.
To manage the intermission of the Classmark Request, add
- msc_classmark_request_then_cipher_mode_cmd(),
- state SUBSCR_CONN_S_WAIT_CLASSMARK_UPDATE,
- event SUBSCR_CONN_E_CLASSMARK_UPDATE.
From state AUTH_CIPH, switch to state WAIT_CLASSMARK_UPDATE. Once the BSSMAP
Classmark Response, is received, switch back to SUBSCR_CONN_S_AUTH_CIPH and
re-initiate Ciphering Mode.
To be able to re-enter the Ciphering Mode algo decision, factor it out into
msc_geran_set_cipher_mode().
Rationale:
In the following commit, essentially we stopped supporting A5/3 ciphering:
commit 71330720b6efdda2fcfd3e9c0cb45f89e32e5670
"MSC: Intersect configured A5 algorithms with MS-supported ones"
Change-Id: Id124923ee52a357cb7d3e04d33f585214774f3a3
A5/3 was no longer supported because from that commit on, we strictly checked
the MS-supported ciphers, but we did not have Classmark 2 available during
Location Updating.
This patch changes that: when Classmark 2 is missing, actively request it by a
BSSMAP Classmark Request; continue Ciphering only after the Response. Always
request missing Classmark, even if a lesser cipher were configured available.
If the Classmark Update response fails to come in, cause an attach failure.
Instead, we could attempt to use a lesser cipher that is also enabled. That is
left as a future feature, should that become relevant. I think it's unlikely.
Technically, we could now end up requesting a Classmark Updating both during LU
(vlr_lu_fsm) and CM Service/Paging Response (proc_arq_fsm), but in practice the
only time we lack a Classmark is: during Location Updating with A5/3 enabled.
A5/1 support is indicated in CM1 which is always available, and A5/3 support is
indicated in CM2, which is always available during CM Service Request as well
as Paging Response. So this patch has practical relevance only for Location
Updating. For networks that permit only A5/3, this patch fixes Location
Updating. For networks that support A5/3 and A5/1, so far we always used A5/1
during LU, and after this patch we request CM2 and likely use A5/3 instead.
In msc_vlr_test_gsm_ciph, verify that requesting Classmark 2 for A5/3 works
during LU. Also verify that the lack of a Classmark Response results in attach
failure.
In msc_vlr_test_gsm_ciph, a hacky unit test fakes a situation where a CM2 is
missing during proc_arq_fsm and proves that that code path works, even though
the practical relevance is currently zero. It would only become interesting if
ciphering algorithms A5/4 and higher became relevant, because support of those
would be indicated in Classmark 3, which would always require a Classmark
Request.
Related: OS#3043
Depends: I4a2e1d3923e33912579c4180aa1ff8e8f5abb7e7 (libosmocore)
Change-Id: I73c7cb6a86624695bd9c0f59abb72e2fdc655131
2018-09-13 01:23:07 +00:00
|
|
|
static void test_classmark_update_timeout()
|
|
|
|
|
{
|
|
|
|
|
comment_start();
|
|
|
|
|
|
|
|
|
|
fake_time_start();
|
|
|
|
|
|
|
|
|
|
/* implicit: net->authentication_required = true; */
|
|
|
|
|
net->a5_encryption_mask = (1 << 3); /* A5/3 */
|
|
|
|
|
|
|
|
|
|
btw("Location Update request causes a GSUP Send Auth Info request to HLR");
|
|
|
|
|
lu_result_sent = RES_NONE;
|
|
|
|
|
gsup_expect_tx("08010809710000004026f0");
|
|
|
|
|
ms_sends_msg("050802008168000130089910070000006402");
|
|
|
|
|
OSMO_ASSERT(gsup_tx_confirmed);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
|
|
|
|
|
btw("from HLR, rx _SEND_AUTH_INFO_RESULT; VLR sends Auth Req to MS");
|
|
|
|
|
/* Based on a Ki of 000102030405060708090a0b0c0d0e0f */
|
|
|
|
|
auth_request_sent = false;
|
|
|
|
|
auth_request_expect_rand = "585df1ae287f6e273dce07090d61320b";
|
|
|
|
|
auth_request_expect_autn = NULL;
|
|
|
|
|
gsup_rx("0a"
|
|
|
|
|
/* imsi */
|
|
|
|
|
"0108" "09710000004026f0"
|
|
|
|
|
/* TL TL rand */
|
|
|
|
|
"0322" "2010" "585df1ae287f6e273dce07090d61320b"
|
|
|
|
|
/* TL sres TL kc */
|
|
|
|
|
"2104" "2d8b2c3e" "2208" "61855fb81fc2a800"
|
|
|
|
|
,
|
|
|
|
|
NULL);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
VERBOSE_ASSERT(auth_request_sent, == true, "%d");
|
|
|
|
|
|
|
|
|
|
BTW("MS sends Authen Response, VLR accepts and wants to send Ciphering Mode Command to MS"
|
|
|
|
|
" -- but needs Classmark 2 to determine whether A5/3 is supported");
|
|
|
|
|
cipher_mode_cmd_sent = false;
|
|
|
|
|
ms_sends_msg("05542d8b2c3e");
|
|
|
|
|
OSMO_ASSERT(!cipher_mode_cmd_sent);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
|
|
|
|
|
BTW("But the BSSMAP Classmark Update never arrives");
|
|
|
|
|
btw("At first, we're still waiting");
|
|
|
|
|
fake_time_passes(0, 423);
|
|
|
|
|
EXPECT_CONN_COUNT(1);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
fake_time_passes(1, 235);
|
|
|
|
|
EXPECT_CONN_COUNT(1);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
fake_time_passes(1, 235);
|
|
|
|
|
EXPECT_CONN_COUNT(1);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
fake_time_passes(1, 235);
|
|
|
|
|
EXPECT_CONN_COUNT(1);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
fake_time_passes(1, 235);
|
|
|
|
|
EXPECT_CONN_COUNT(1);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_NONE, "%d");
|
|
|
|
|
expect_bssap_clear();
|
|
|
|
|
fake_time_passes(1, 235);
|
rename gsm_subscriber_connection to ran_conn
In preparation for inter-BSC and inter-MSC handover, we need to separate the
subscriber management logic from the actual RAN connections. What better time
to finally rename gsm_subscriber_connection.
* Name choice:
In 2G, this is a connection to the BSS, but even though 3GPP TS commonly talk
of "BSS-A" and "BSS-B" when explaining handover, it's not good to call it
"bss_conn": in 3G a BSS is called RNS, IIUC.
The overall term for 2G (GERAN) and 3G (UTRAN) is RAN: Radio Access Network.
* Rationale:
A subscriber in the MSC so far has only one RAN connection, but e.g. for
inter-BSC handover, a second one needs to be created to handover to. Most of
the items in the former gsm_subscriber_connection are actually related to the
RAN, with only a few MM and RTP related items. So, as a first step, just rename
it to ran_conn, to cosmetically prepare for moving the not strictly RAN related
items away later.
Also:
- Rename some functions from msc_subscr_conn_* to ran_conn_*
- Rename "Subscr_Conn" FSM instance name to "RAN_conn"
- Rename SUBSCR_CONN_* to RAN_CONN_*
Change-Id: Ic595f7a558d3553c067f77dc67543ab59659707a
2018-11-29 21:37:51 +00:00
|
|
|
btw("RAN_CONN_TIMEOUT has passed, conn is gone.");
|
A5/n Ciph: request Classmark Update if missing
When the VLR requests a Ciphering Mode with vlr_ops.set_ciph_mode(), and if we
need a ciph algo flag from a Classmark information that is not yet known
(usually CM 2 during LU), send a BSSMAP Classmark Request to get it.
To manage the intermission of the Classmark Request, add
- msc_classmark_request_then_cipher_mode_cmd(),
- state SUBSCR_CONN_S_WAIT_CLASSMARK_UPDATE,
- event SUBSCR_CONN_E_CLASSMARK_UPDATE.
From state AUTH_CIPH, switch to state WAIT_CLASSMARK_UPDATE. Once the BSSMAP
Classmark Response, is received, switch back to SUBSCR_CONN_S_AUTH_CIPH and
re-initiate Ciphering Mode.
To be able to re-enter the Ciphering Mode algo decision, factor it out into
msc_geran_set_cipher_mode().
Rationale:
In the following commit, essentially we stopped supporting A5/3 ciphering:
commit 71330720b6efdda2fcfd3e9c0cb45f89e32e5670
"MSC: Intersect configured A5 algorithms with MS-supported ones"
Change-Id: Id124923ee52a357cb7d3e04d33f585214774f3a3
A5/3 was no longer supported because from that commit on, we strictly checked
the MS-supported ciphers, but we did not have Classmark 2 available during
Location Updating.
This patch changes that: when Classmark 2 is missing, actively request it by a
BSSMAP Classmark Request; continue Ciphering only after the Response. Always
request missing Classmark, even if a lesser cipher were configured available.
If the Classmark Update response fails to come in, cause an attach failure.
Instead, we could attempt to use a lesser cipher that is also enabled. That is
left as a future feature, should that become relevant. I think it's unlikely.
Technically, we could now end up requesting a Classmark Updating both during LU
(vlr_lu_fsm) and CM Service/Paging Response (proc_arq_fsm), but in practice the
only time we lack a Classmark is: during Location Updating with A5/3 enabled.
A5/1 support is indicated in CM1 which is always available, and A5/3 support is
indicated in CM2, which is always available during CM Service Request as well
as Paging Response. So this patch has practical relevance only for Location
Updating. For networks that permit only A5/3, this patch fixes Location
Updating. For networks that support A5/3 and A5/1, so far we always used A5/1
during LU, and after this patch we request CM2 and likely use A5/3 instead.
In msc_vlr_test_gsm_ciph, verify that requesting Classmark 2 for A5/3 works
during LU. Also verify that the lack of a Classmark Response results in attach
failure.
In msc_vlr_test_gsm_ciph, a hacky unit test fakes a situation where a CM2 is
missing during proc_arq_fsm and proves that that code path works, even though
the practical relevance is currently zero. It would only become interesting if
ciphering algorithms A5/4 and higher became relevant, because support of those
would be indicated in Classmark 3, which would always require a Classmark
Request.
Related: OS#3043
Depends: I4a2e1d3923e33912579c4180aa1ff8e8f5abb7e7 (libosmocore)
Change-Id: I73c7cb6a86624695bd9c0f59abb72e2fdc655131
2018-09-13 01:23:07 +00:00
|
|
|
VERBOSE_ASSERT(bssap_clear_sent, == true, "%d");
|
|
|
|
|
bss_sends_clear_complete();
|
|
|
|
|
EXPECT_CONN_COUNT(0);
|
|
|
|
|
VERBOSE_ASSERT(lu_result_sent, == RES_REJECT, "%d");
|
|
|
|
|
|
|
|
|
|
comment_end();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
2017-01-25 14:04:16 +00:00
|
|
|
msc_vlr_test_func_t msc_vlr_tests[] = {
|
|
|
|
|
test_ms_timeout_lu_auth_resp,
|
|
|
|
|
test_ms_timeout_cm_auth_resp,
|
fix paging: add timeout to discard unsuccessful paging
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
2017-12-15 02:02:27 +00:00
|
|
|
test_ms_timeout_paging,
|
A5/n Ciph: request Classmark Update if missing
When the VLR requests a Ciphering Mode with vlr_ops.set_ciph_mode(), and if we
need a ciph algo flag from a Classmark information that is not yet known
(usually CM 2 during LU), send a BSSMAP Classmark Request to get it.
To manage the intermission of the Classmark Request, add
- msc_classmark_request_then_cipher_mode_cmd(),
- state SUBSCR_CONN_S_WAIT_CLASSMARK_UPDATE,
- event SUBSCR_CONN_E_CLASSMARK_UPDATE.
From state AUTH_CIPH, switch to state WAIT_CLASSMARK_UPDATE. Once the BSSMAP
Classmark Response, is received, switch back to SUBSCR_CONN_S_AUTH_CIPH and
re-initiate Ciphering Mode.
To be able to re-enter the Ciphering Mode algo decision, factor it out into
msc_geran_set_cipher_mode().
Rationale:
In the following commit, essentially we stopped supporting A5/3 ciphering:
commit 71330720b6efdda2fcfd3e9c0cb45f89e32e5670
"MSC: Intersect configured A5 algorithms with MS-supported ones"
Change-Id: Id124923ee52a357cb7d3e04d33f585214774f3a3
A5/3 was no longer supported because from that commit on, we strictly checked
the MS-supported ciphers, but we did not have Classmark 2 available during
Location Updating.
This patch changes that: when Classmark 2 is missing, actively request it by a
BSSMAP Classmark Request; continue Ciphering only after the Response. Always
request missing Classmark, even if a lesser cipher were configured available.
If the Classmark Update response fails to come in, cause an attach failure.
Instead, we could attempt to use a lesser cipher that is also enabled. That is
left as a future feature, should that become relevant. I think it's unlikely.
Technically, we could now end up requesting a Classmark Updating both during LU
(vlr_lu_fsm) and CM Service/Paging Response (proc_arq_fsm), but in practice the
only time we lack a Classmark is: during Location Updating with A5/3 enabled.
A5/1 support is indicated in CM1 which is always available, and A5/3 support is
indicated in CM2, which is always available during CM Service Request as well
as Paging Response. So this patch has practical relevance only for Location
Updating. For networks that permit only A5/3, this patch fixes Location
Updating. For networks that support A5/3 and A5/1, so far we always used A5/1
during LU, and after this patch we request CM2 and likely use A5/3 instead.
In msc_vlr_test_gsm_ciph, verify that requesting Classmark 2 for A5/3 works
during LU. Also verify that the lack of a Classmark Response results in attach
failure.
In msc_vlr_test_gsm_ciph, a hacky unit test fakes a situation where a CM2 is
missing during proc_arq_fsm and proves that that code path works, even though
the practical relevance is currently zero. It would only become interesting if
ciphering algorithms A5/4 and higher became relevant, because support of those
would be indicated in Classmark 3, which would always require a Classmark
Request.
Related: OS#3043
Depends: I4a2e1d3923e33912579c4180aa1ff8e8f5abb7e7 (libosmocore)
Change-Id: I73c7cb6a86624695bd9c0f59abb72e2fdc655131
2018-09-13 01:23:07 +00:00
|
|
|
test_classmark_update_timeout,
|
2017-01-25 14:04:16 +00:00
|
|
|
NULL
|
|
|
|
|
};
|
