2018-03-30 21:04:04 +00:00
full talloc report on 'msgb' (total 0 bytes in 1 blocks)
2018-12-06 11:06:59 +00:00
talloc_total_blocks(tall_bsc_ctx) == 13
2018-03-30 21:04:04 +00:00
2018-03-01 23:40:58 +00:00
===== test_ciph
2017-01-25 14:04:16 +00:00
- Location Update request causes a GSUP Send Auth Info request to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_LOC_UPD_REQUEST
2017-01-25 14:04:16 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_LOC_UPD_REQUEST (0x5:0x8)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: LOCATION UPDATING REQUEST: MI=IMSI-901700000004620 LU-type=IMSI-ATTACH
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: LU/new-LAC: 1/23
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Allocated
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: is child of RAN_conn(IMSI-901700000004620:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: rev=GSM net=GERAN Auth+Ciph
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Received Event VLR_ULA_E_UPDATE_LA
2019-02-19 01:36:35 +00:00
DREF VLR subscr unknown + _lu_fsm_associate_vsub: now used by 1 (_lu_fsm_associate_vsub)
2017-01-25 14:04:16 +00:00
DVLR set IMSI on subscriber; IMSI=901700000004620 id=901700000004620
DVLR New subscr, IMSI: 901700000004620
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + conn: now used by 2 (_lu_fsm_associate_vsub,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - _lu_fsm_associate_vsub: now used by 1 (conn)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: vlr_loc_upd_node1()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: state_chg to VLR_ULA_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: is child of vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
2017-01-25 14:04:16 +00:00
DVLR GSUP tx: 08010809710000004026f0
GSUP --> HLR: OSMO_GSUP_MSGT_SEND_AUTH_INFO_REQUEST: 08010809710000004026f0
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_NEEDS_AUTH_WAIT_AI
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000004620: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- from HLR, rx _SEND_AUTH_INFO_RESULT; VLR sends Auth Req to MS
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: 0a010809710000004026f003222010585df1ae287f6e273dce07090d61320b21042d8b2c3e220861855fb81fc2a8000322201012aca96fb4ffdea5c985cbafa9b6e18b210420bde240220807fa7502e07e1c0003222010e7c03ba7cf0e2fde82b2dc4d63077d422104a29514ae2208e2b234f80788640003222010fa8f20b781b5881329d4fea26b1a3c5121045afc8d7222082392f14f709ae000032220100fd4cc8dbe8715d1f439e304edfd68dc2104bc8d1c5b2208da7cdd6bfe2d7000
DVLR GSUP rx 191: 0a010809710000004026f003222010585df1ae287f6e273dce07090d61320b21042d8b2c3e220861855fb81fc2a8000322201012aca96fb4ffdea5c985cbafa9b6e18b210420bde240220807fa7502e07e1c0003222010e7c03ba7cf0e2fde82b2dc4d63077d422104a29514ae2208e2b234f80788640003222010fa8f20b781b5881329d4fea26b1a3c5121045afc8d7222082392f14f709ae000032220100fd4cc8dbe8715d1f439e304edfd68dc2104bc8d1c5b2208da7cdd6bfe2d7000
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: Received Event VLR_AUTH_E_HLR_SAI_ACK
DVLR SUBSCR(IMSI-901700000004620) Received 5 auth tuples
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=0 -- will use GSM AKA (is_r99=no, at->vec.auth_types=0x1)
- sending GSM Auth Request for IMSI-901700000004620: tuple use_count=1 key_seq=0 auth_types=0x1 and...
2017-01-25 14:04:16 +00:00
- ...rand=585df1ae287f6e273dce07090d61320b
- ...expecting sres=2d8b2c3e
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - vlr_gsupc_read_cb: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: vlr_gsupc_read_cb() returns 0
lu_result_sent == 0
auth_request_sent == 1
- MS sends Authen Response, VLR accepts and sends Ciphering Mode Command to MS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620: MSC conn use + dtap == 1 (0x2: dtap)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000004620: MM GSM AUTHENTICATION RESPONSE (sres = 2d8b2c3e)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000004620) AUTH on GERAN received SRES/RES: 2d8b2c3e (4 bytes)
DVLR SUBSCR(IMSI-901700000004620) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Received Event VLR_ULA_E_AUTH_RES
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: vlr_loc_upd_post_auth()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Set Ciphering Mode
DMM -> CIPHER MODE COMMAND IMSI-901700000004620
- sending Ciphering Mode Command for IMSI-901700000004620: include_imeisv=0
2018-09-16 22:54:52 +00:00
- ...perm algo: A5/1
2018-03-02 00:50:09 +00:00
- ...key: 61855fb81fc2a800
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: state_chg to VLR_ULA_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- needs ciph, not yet accepted
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- MS sends Ciphering Mode Complete, VLR accepts and sends GSUP LU Req to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000004620: CIPHERING MODE COMPLETE
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: Received Event VLR_ULA_E_CIPH_RES
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_post_ciph()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_node_4()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: state_chg to VLR_ULA_S_WAIT_HLR_UPD
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Allocated
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Received Event UPD_HLR_VLR_E_START
2018-09-28 00:41:39 +00:00
DVLR GSUP tx: 04010809710000004026f0280102
GSUP --> HLR: OSMO_GSUP_MSGT_UPDATE_LOCATION_REQUEST: 04010809710000004026f0280102
2019-01-03 01:32:14 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: state_chg to UPD_HLR_VLR_S_WAIT_FOR_DATA
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- HLR sends _INSERT_DATA_REQUEST, VLR responds with _INSERT_DATA_RESULT
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: 10010809710000004026f00804036470f1
DVLR GSUP rx 17: 10010809710000004026f00804036470f1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2017-01-25 14:04:16 +00:00
DVLR IMSI:901700000004620 has MSISDN:46071
2019-02-19 01:36:35 +00:00
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071) VLR: update for IMSI=901700000004620 (MSISDN=46071)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Updated ID
2017-01-25 14:04:16 +00:00
DVLR GSUP tx: 12010809710000004026f0
GSUP --> HLR: OSMO_GSUP_MSGT_INSERT_DATA_RESULT: 12010809710000004026f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_gsupc_read_cb: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: vlr_gsupc_read_cb() returns 0
lu_result_sent == 0
- HLR also sends GSUP _UPDATE_LOCATION_RESULT
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: 06010809710000004026f0
DVLR GSUP rx 11: 06010809710000004026f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_HLR_LU_RES
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: Received Event UPD_HLR_VLR_E_UPD_LOC_ACK
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: state_chg to UPD_HLR_VLR_S_DONE
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_UPD_HLR_COMPL
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: state_chg to VLR_ULA_S_WAIT_LU_COMPL
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Allocated
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Received Event LU_COMPL_VLR_E_START
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: state_chg to LU_COMPL_VLR_S_WAIT_SUB_PRES
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: Received Event LU_COMPL_VLR_E_SUB_PRES_COMPL
- sending LU Accept for IMSI-901700000004620:MSISDN-46071
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + attached: now used by 3 (conn,vlr_gsupc_read_cb,attached)
2019-01-03 01:32:14 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: state_chg to LU_COMPL_VLR_S_DONE
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_LU_COMPL_SUCCESS
2019-03-24 20:07:33 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU))
2019-01-03 01:32:14 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
2019-03-24 20:07:33 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Deferring: will deallocate with upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: state_chg to VLR_ULA_S_DONE
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_subscr_cancel_attach_fsm: now used by 4 (conn,vlr_gsupc_read_cb,attached,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_subscr_cancel_attach_fsm: now used by 3 (conn,vlr_gsupc_read_cb,attached)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2019-03-24 20:07:33 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Deallocated, including all deferred deallocations
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_gsupc_read_cb: now used by 2 (conn,attached)
2018-04-01 18:55:54 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: vlr_gsupc_read_cb() returns 0
bssap_clear_sent == 1
- LU was successful, and the conn has already been closed
lu_result_sent == 1
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU))
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_DONE}: Removing from parent RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_DONE}: fsm_lu_cleanup called with cause OSMO_FSM_TERM_PARENT
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000004620:MSISDN-46071: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
2017-01-25 14:04:16 +00:00
---
- after a while, a new conn sends a CM Service Request. VLR responds with Auth Req, 2nd auth vector
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_CM_SERV_REQ
2017-01-25 14:04:16 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_CM_SERV_REQ (0x5:0x24)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Updated ID
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Rx CM SERVICE REQUEST cm_service_type=0x08
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: Allocated
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: is child of RAN_conn(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: rev=GSM net=GERAN Auth+Ciph
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: Received Event PR_ARQ_E_START
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + proc_arq_vlr_fn_init: now used by 2 (attached,proc_arq_vlr_fn_init)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + conn: now used by 3 (attached,proc_arq_vlr_fn_init,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Updated ID
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: proc_arq_vlr_fn_post_imsi()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: state_chg to PR_ARQ_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: is child of Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=1 -- will use GSM AKA (is_r99=no, at->vec.auth_types=0x1)
- sending GSM Auth Request for IMSI-901700000004620:MSISDN-46071: tuple use_count=1 key_seq=1 auth_types=0x1 and...
2017-01-25 14:04:16 +00:00
- ...rand=12aca96fb4ffdea5c985cbafa9b6e18b
- ...expecting sres=20bde240
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - proc_arq_vlr_fn_init: now used by 2 (attached,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
auth_request_sent == 1
cm_service_result_sent == 0
- needs auth, not yet accepted
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
- MS sends Authen Response, VLR accepts and requests Ciphering
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use + dtap == 1 (0x2: dtap)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000004620:MSISDN-46071: MM GSM AUTHENTICATION RESPONSE (sres = 20bde240)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071) AUTH on GERAN received SRES/RES: 20bde240 (4 bytes)
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_AUTHENTICATED}: Removing from parent Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: Received Event PR_ARQ_E_AUTH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: _proc_arq_vlr_node2()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: Set Ciphering Mode
DMM -> CIPHER MODE COMMAND IMSI-901700000004620:MSISDN-46071
- sending Ciphering Mode Command for IMSI-901700000004620:MSISDN-46071: include_imeisv=0
2018-09-16 22:54:52 +00:00
- ...perm algo: A5/1
2018-03-02 00:50:09 +00:00
- ...key: 07fa7502e07e1c00
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: state_chg to PR_ARQ_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
cm_service_result_sent == 0
cipher_mode_cmd_sent == 1
- needs ciph, not yet accepted
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
- MS sends Ciphering Mode Complete, VLR accepts; above Ciphering is an implicit CM Service Accept
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000004620:MSISDN-46071: CIPHERING MODE COMPLETE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: Received Event PR_ARQ_E_CIPH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_ciph()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_vlr()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_pres()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_trace()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_imei()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: proc_arq_fsm_done(PASSED)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: state_chg to PR_ARQ_S_DONE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Process Access Request result: PASSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use + cm_service == 1 (0x8: cm_service)
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_ACCEPTED}: ran_conn_fsm_has_active_transactions: still awaiting first request after a CM Service Request
2017-01-25 14:04:16 +00:00
cm_service_result_sent == 0
2018-06-15 16:57:30 +00:00
- Concluding CM Service Request
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use - cm_service == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,conn,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,conn)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2018-04-01 18:55:54 +00:00
bssap_clear_sent == 1
- all requests serviced, conn has been released
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ))
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Removing from parent RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000004620:MSISDN-46071: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
2017-01-25 14:04:16 +00:00
---
- an SMS is sent, MS is paged
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + test_ciph: now used by 2 (attached,test_ciph)
2017-01-25 14:04:16 +00:00
llist_count(&vsub->cs.requests) == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + SMS-receiver: now used by 3 (attached,test_ciph,SMS-receiver)
2019-01-16 11:47:39 +00:00
DLSMS Going to send a MT SMS
2019-01-03 01:32:14 +00:00
DCC (ti 00 sub IMSI-901700000004620:MSISDN-46071 callref 40000001) New transaction
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + SMS: now used by 4 (attached,test_ciph,SMS-receiver,SMS)
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) instance created for network
DLSMS SMR(0) instance created for network.
DLSMS SMR(0) message SM-RL-DATA_REQ received in state IDLE
DLSMS SMR(0) TX SMS RP-DATA
DLSMS SMR(0) new RP state IDLE -> WAIT_FOR_RP_ACK
DLSMS SMC(0) message MNSMS-EST-REQ received in state IDLE
DLSMS SMC(0) new CP state IDLE -> MM_CONN_PENDING
DLSMS Initiating Paging procedure for IMSI-901700000004620:MSISDN-46071 due to MMSMS_EST_REQ
2019-01-03 01:32:14 +00:00
DMM Subscriber IMSI-901700000004620:MSISDN-46071 not paged yet, start paging.
2018-12-25 23:40:18 +00:00
GERAN-A sends out paging request to IMSI 901700000004620, TMSI 0xffffffff, LAC 23
2016-05-20 19:59:55 +00:00
strcmp(paging_expecting_imsi, imsi) == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + Paging: now used by 5 (attached,test_ciph,SMS-receiver,SMS,Paging)
2017-01-25 14:04:16 +00:00
llist_count(&vsub->cs.requests) == 1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - test_ciph: now used by 4 (attached,SMS-receiver,SMS,Paging)
2017-01-25 14:04:16 +00:00
paging_sent == 1
paging_stopped == 0
- the subscriber and its pending request should remain
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + test_ciph: now used by 5 (attached,SMS-receiver,SMS,Paging,test_ciph)
2017-01-25 14:04:16 +00:00
llist_count(&vsub->cs.requests) == 1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - test_ciph: now used by 4 (attached,SMS-receiver,SMS,Paging)
2017-01-25 14:04:16 +00:00
- MS replies with Paging Response, and VLR sends Auth Request with third key
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_PAG_RESP
2017-01-25 14:04:16 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_PAG_RESP (0x6:0x27)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: Updated ID
DRR RAN_conn(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: PAGING RESPONSE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: Allocated
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: is child of RAN_conn(IMSI-901700000004620:GERAN-A-0:PAGING_RESP)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: rev=GSM net=GERAN Auth+Ciph
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: Received Event PR_ARQ_E_START
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + proc_arq_vlr_fn_init: now used by 5 (attached,SMS-receiver,SMS,Paging,proc_arq_vlr_fn_init)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + conn: now used by 6 (attached,SMS-receiver,SMS,Paging,proc_arq_vlr_fn_init,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: Updated ID
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: proc_arq_vlr_fn_post_imsi()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: state_chg to PR_ARQ_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: is child of Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=2 -- will use GSM AKA (is_r99=no, at->vec.auth_types=0x1)
- sending GSM Auth Request for IMSI-901700000004620:MSISDN-46071: tuple use_count=1 key_seq=2 auth_types=0x1 and...
2017-01-25 14:04:16 +00:00
- ...rand=e7c03ba7cf0e2fde82b2dc4d63077d42
- ...expecting sres=a29514ae
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - proc_arq_vlr_fn_init: now used by 5 (attached,SMS-receiver,SMS,Paging,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
auth_request_sent == 1
- needs auth, not yet accepted
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
- MS sends Authen Response, VLR accepts and requests Ciphering
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use + dtap == 1 (0x2: dtap)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000004620:MSISDN-46071: MM GSM AUTHENTICATION RESPONSE (sres = a29514ae)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071) AUTH on GERAN received SRES/RES: a29514ae (4 bytes)
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_AUTHENTICATED}: Removing from parent Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: Received Event PR_ARQ_E_AUTH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: _proc_arq_vlr_node2()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: Set Ciphering Mode
DMM -> CIPHER MODE COMMAND IMSI-901700000004620:MSISDN-46071
- sending Ciphering Mode Command for IMSI-901700000004620:MSISDN-46071: include_imeisv=0
2018-09-16 22:54:52 +00:00
- ...perm algo: A5/1
2018-03-02 00:50:09 +00:00
- ...key: e2b234f807886400
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: state_chg to PR_ARQ_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
cipher_mode_cmd_sent == 1
- needs ciph, not yet accepted
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
- MS sends Ciphering Mode Complete, VLR accepts and sends pending SMS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000004620:MSISDN-46071: CIPHERING MODE COMPLETE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: Received Event PR_ARQ_E_CIPH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_ciph()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_vlr()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_pres()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_trace()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_imei()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: proc_arq_fsm_done(PASSED)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: state_chg to PR_ARQ_S_DONE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Process Access Request result: PASSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DPAG Paging success for IMSI-901700000004620:MSISDN-46071 (event=0)
2016-05-20 19:59:55 +00:00
DPAG Calling paging cbfn.
2019-01-16 11:47:39 +00:00
DLSMS paging_cb_mmsms_est_req(hooknum=1, event=0)
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use + trans_sms == 1 (0x20: trans_sms)
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) message MMSMS-EST-CNF received in state MM_CONN_PENDING
DLSMS SMC(0) send CP data
DLSMS SMC(0) new CP state MM_CONN_PENDING -> WAIT_CP_ACK
DLSMS sending CP message (trans=0)
DLSMS GSM4.11 TX 09 01 58 01 00 07 91 44 77 58 10 06 50 00 4c 00 05 80 64 70 f1 00 00 07 10 10 00 00 00 00 44 50 79 da 1e 1e e7 41 69 37 48 5e 9e a7 c9 65 37 3d 1d 66 83 c2 70 38 3b 3d 0e d3 d3 6f f7 1c 94 9e 83 c2 20 72 79 9e 96 87 c5 ec 32 a8 1d 96 af cb f4 b4 fb 0c 7a c3 e9 e9 b7 db 05
2019-01-03 01:32:14 +00:00
DMSC msc_tx 91 bytes to IMSI-901700000004620:MSISDN-46071 via GERAN-A
2018-12-25 23:40:18 +00:00
- DTAP --GERAN-A--> MS: SMS:0x01: 09015801000791447758100650004c0005806470f1000007101000000000445079da1e1ee7416937485e9ea7c965373d1d6683c270383b3d0ed3d36ff71c949e83c22072799e9687c5ec32a81d96afcbf4b4fb0c7ac3e9e9b7db05
2017-01-25 14:04:16 +00:00
- DTAP matches expected message
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - Paging: now used by 4 (attached,SMS-receiver,SMS,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_ACCEPTED}: ran_conn_fsm_has_active_transactions: connection still has active transaction: SMS
2017-01-25 14:04:16 +00:00
dtap_tx_confirmed == 1
paging_stopped == 1
- SMS was delivered, no requests pending for subscr
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + test_ciph: now used by 5 (attached,SMS-receiver,SMS,conn,test_ciph)
2017-01-25 14:04:16 +00:00
llist_count(&vsub->cs.requests) == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - test_ciph: now used by 4 (attached,SMS-receiver,SMS,conn)
2017-01-25 14:04:16 +00:00
- conn is still open to wait for SMS ack dance
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
llist_count(&net->ran_conns) == 1
2017-01-25 14:04:16 +00:00
- MS replies with CP-ACK for received SMS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: SMS:0x04
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use + dtap == 2 (0x22: dtap,trans_sms)
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x04 (0x9:0x4)
2019-01-16 11:47:39 +00:00
DLSMS receiving data (trans_id=0, msg_type=SMS:0x04)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_COMMUNICATING
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_COMMUNICATING
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) message MMSMS-DATA-IND (CP ACK) received in state WAIT_CP_ACK
DLSMS SMC(0) received CP-ACK
DLSMS SMC(0) new CP state WAIT_CP_ACK -> MM_ESTABLISHED
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use - dtap == 1 (0x20: trans_sms)
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
llist_count(&net->ran_conns) == 1
2017-01-25 14:04:16 +00:00
- MS also sends RP-ACK, MSC in turn sends CP-ACK for that
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: SMS:0x01
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use + dtap == 2 (0x22: dtap,trans_sms)
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-16 11:47:39 +00:00
DLSMS receiving data (trans_id=0, msg_type=SMS:0x01)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_COMMUNICATING}: Received Event RAN_CONN_E_COMMUNICATING
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) message MMSMS-DATA-IND (CP DATA) received in state MM_ESTABLISHED
DLSMS SMC(0) received CP-DATA
DLSMS sending CP message (trans=0)
DLSMS GSM4.11 TX 09 04
2019-01-03 01:32:14 +00:00
DMSC msc_tx 2 bytes to IMSI-901700000004620:MSISDN-46071 via GERAN-A
2018-12-25 23:40:18 +00:00
- DTAP --GERAN-A--> MS: SMS:0x04: 0904
2017-01-25 14:04:16 +00:00
- DTAP matches expected message
2019-01-16 11:47:39 +00:00
DLSMS MNSMS-DATA/EST-IND
DLSMS SMR(0) message MNSMS-DATA-IND received in state WAIT_FOR_RP_ACK
DLSMS SMR(0) RX SMS RP-ACK
DLSMS SMR(0) new RP state WAIT_FOR_RP_ACK -> IDLE
DLSMS RX SMS RP-ACK (MO)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - SMS-receiver: now used by 3 (attached,SMS,conn)
2019-01-16 11:47:39 +00:00
DLSMS SMR(0) TX: MNSMS-REL-REQ
DLSMS SMC(0) message MNSMS-REL-REQ received in state MM_ESTABLISHED
DLSMS SMC(0) new CP state MM_ESTABLISHED -> IDLE
DLSMS Got MMSMS_REL_REQ, destroying transaction.
DLSMS SMR(0) clearing SMR instance
DLSMS SMC(0) clearing instance
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - SMS: now used by 2 (attached,conn)
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use - trans_sms == 1 (0x2: dtap)
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_COMMUNICATING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_COMMUNICATING}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,conn,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,conn)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2018-04-01 18:55:54 +00:00
dtap_tx_confirmed == 1
bssap_clear_sent == 1
- SMS is done, conn is gone
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP))
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Removing from parent RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000004620:MSISDN-46071: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
2017-01-25 14:04:16 +00:00
---
- subscriber detaches
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_IMSI_DETACH_IND
2017-01-25 14:04:16 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_IMSI_DETACH_IND (0x5:0x1)
2017-01-25 14:04:16 +00:00
DMM IMSI DETACH INDICATION: MI(IMSI)=901700000004620
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + gsm48_rx_mm_imsi_detach_ind: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
2019-01-03 01:32:14 +00:00
DMM IMSI DETACH for IMSI-901700000004620:MSISDN-46071
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,gsm48_rx_mm_imsi_detach_ind,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - attached: now used by 1 (gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - gsm48_rx_mm_imsi_detach_ind: now used by 0 (-)
2019-01-03 01:32:14 +00:00
DREF freeing VLR subscr IMSI-901700000004620:MSISDN-46071
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
DMM RAN_conn{RAN_CONN_S_NEW}: Received Event RAN_CONN_E_CN_CLOSE
DMM RAN_conn{RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_RELEASING
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + release == 2 (0x101: compl_l3,release)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use - compl_l3 == 1 (0x100: release)
2018-04-01 18:55:54 +00:00
bssap_clear_sent == 1
- BSS sends BSSMAP Clear Complete
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use - release == 0 (0x0: )
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
DMM RAN_conn{RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn{RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn{RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DRLL Freeing RAN connection with NULL subscriber
DMM RAN_conn{RAN_CONN_S_RELEASED}: Deallocated
llist_count(&net->ran_conns) == 0
2018-03-01 23:40:58 +00:00
===== test_ciph: SUCCESS
2017-01-25 14:04:16 +00:00
full talloc report on 'msgb' (total 0 bytes in 1 blocks)
2018-12-06 11:06:59 +00:00
talloc_total_blocks(tall_bsc_ctx) == 13
2017-01-25 14:04:16 +00:00
2018-03-01 23:40:58 +00:00
===== test_ciph_tmsi
2017-01-25 14:04:16 +00:00
- Location Update request causes a GSUP Send Auth Info request to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_LOC_UPD_REQUEST
2017-01-25 14:04:16 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_LOC_UPD_REQUEST (0x5:0x8)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: LOCATION UPDATING REQUEST: MI=IMSI-901700000004620 LU-type=IMSI-ATTACH
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: LU/new-LAC: 1/23
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Allocated
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: is child of RAN_conn(IMSI-901700000004620:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: rev=GSM net=GERAN Auth+Ciph
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Received Event VLR_ULA_E_UPDATE_LA
2019-02-19 01:36:35 +00:00
DREF VLR subscr unknown + _lu_fsm_associate_vsub: now used by 1 (_lu_fsm_associate_vsub)
2017-01-25 14:04:16 +00:00
DVLR set IMSI on subscriber; IMSI=901700000004620 id=901700000004620
DVLR New subscr, IMSI: 901700000004620
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + conn: now used by 2 (_lu_fsm_associate_vsub,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - _lu_fsm_associate_vsub: now used by 1 (conn)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: vlr_loc_upd_node1()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: state_chg to VLR_ULA_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: is child of vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
2017-01-25 14:04:16 +00:00
DVLR GSUP tx: 08010809710000004026f0
GSUP --> HLR: OSMO_GSUP_MSGT_SEND_AUTH_INFO_REQUEST: 08010809710000004026f0
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_NEEDS_AUTH_WAIT_AI
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000004620: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- from HLR, rx _SEND_AUTH_INFO_RESULT; VLR sends Auth Req to MS
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: 0a010809710000004026f003222010585df1ae287f6e273dce07090d61320b21042d8b2c3e220861855fb81fc2a8000322201012aca96fb4ffdea5c985cbafa9b6e18b210420bde240220807fa7502e07e1c0003222010e7c03ba7cf0e2fde82b2dc4d63077d422104a29514ae2208e2b234f80788640003222010fa8f20b781b5881329d4fea26b1a3c5121045afc8d7222082392f14f709ae000032220100fd4cc8dbe8715d1f439e304edfd68dc2104bc8d1c5b2208da7cdd6bfe2d7000
DVLR GSUP rx 191: 0a010809710000004026f003222010585df1ae287f6e273dce07090d61320b21042d8b2c3e220861855fb81fc2a8000322201012aca96fb4ffdea5c985cbafa9b6e18b210420bde240220807fa7502e07e1c0003222010e7c03ba7cf0e2fde82b2dc4d63077d422104a29514ae2208e2b234f80788640003222010fa8f20b781b5881329d4fea26b1a3c5121045afc8d7222082392f14f709ae000032220100fd4cc8dbe8715d1f439e304edfd68dc2104bc8d1c5b2208da7cdd6bfe2d7000
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: Received Event VLR_AUTH_E_HLR_SAI_ACK
DVLR SUBSCR(IMSI-901700000004620) Received 5 auth tuples
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=0 -- will use GSM AKA (is_r99=no, at->vec.auth_types=0x1)
- sending GSM Auth Request for IMSI-901700000004620: tuple use_count=1 key_seq=0 auth_types=0x1 and...
2017-01-25 14:04:16 +00:00
- ...rand=585df1ae287f6e273dce07090d61320b
- ...expecting sres=2d8b2c3e
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - vlr_gsupc_read_cb: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: vlr_gsupc_read_cb() returns 0
auth_request_sent == 1
lu_result_sent == 0
- MS sends Authen Response, VLR accepts and sends Ciphering Mode Command to MS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620: MSC conn use + dtap == 1 (0x2: dtap)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000004620: MM GSM AUTHENTICATION RESPONSE (sres = 2d8b2c3e)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000004620) AUTH on GERAN received SRES/RES: 2d8b2c3e (4 bytes)
DVLR SUBSCR(IMSI-901700000004620) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Received Event VLR_ULA_E_AUTH_RES
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: vlr_loc_upd_post_auth()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Set Ciphering Mode
DMM -> CIPHER MODE COMMAND IMSI-901700000004620
- sending Ciphering Mode Command for IMSI-901700000004620: include_imeisv=0
2018-09-16 22:54:52 +00:00
- ...perm algo: A5/1
2018-03-02 00:50:09 +00:00
- ...key: 61855fb81fc2a800
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: state_chg to VLR_ULA_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
auth_request_sent == 1
- needs ciph, not yet accepted
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- MS sends Ciphering Mode Complete, VLR accepts and sends GSUP LU Req to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000004620: CIPHERING MODE COMPLETE
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: Received Event VLR_ULA_E_CIPH_RES
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_post_ciph()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_node_4()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: state_chg to VLR_ULA_S_WAIT_HLR_UPD
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Allocated
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Received Event UPD_HLR_VLR_E_START
2018-09-28 00:41:39 +00:00
DVLR GSUP tx: 04010809710000004026f0280102
GSUP --> HLR: OSMO_GSUP_MSGT_UPDATE_LOCATION_REQUEST: 04010809710000004026f0280102
2019-01-03 01:32:14 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: state_chg to UPD_HLR_VLR_S_WAIT_FOR_DATA
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- HLR sends _INSERT_DATA_REQUEST, VLR responds with _INSERT_DATA_RESULT
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: 10010809710000004026f00804036470f1
DVLR GSUP rx 17: 10010809710000004026f00804036470f1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2017-01-25 14:04:16 +00:00
DVLR IMSI:901700000004620 has MSISDN:46071
2019-02-19 01:36:35 +00:00
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071) VLR: update for IMSI=901700000004620 (MSISDN=46071)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Updated ID
2017-01-25 14:04:16 +00:00
DVLR GSUP tx: 12010809710000004026f0
GSUP --> HLR: OSMO_GSUP_MSGT_INSERT_DATA_RESULT: 12010809710000004026f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_gsupc_read_cb: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: vlr_gsupc_read_cb() returns 0
lu_result_sent == 0
- HLR also sends GSUP _UPDATE_LOCATION_RESULT
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: 06010809710000004026f0
DVLR GSUP rx 11: 06010809710000004026f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_HLR_LU_RES
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: Received Event UPD_HLR_VLR_E_UPD_LOC_ACK
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: state_chg to UPD_HLR_VLR_S_DONE
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_UPD_HLR_COMPL
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: state_chg to VLR_ULA_S_WAIT_LU_COMPL
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Allocated
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Received Event LU_COMPL_VLR_E_START
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: state_chg to LU_COMPL_VLR_S_WAIT_SUB_PRES
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: Received Event LU_COMPL_VLR_E_SUB_PRES_COMPL
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: lu_compl_vlr_new_tmsi()
2019-02-19 01:36:35 +00:00
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100) VLR: update for IMSI=901700000004620 (MSISDN=46071)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Updated ID
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: state_chg to LU_COMPL_VLR_S_WAIT_TMSI_CNF
- sending LU Accept for IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100, with TMSI 0x03020100
2019-03-24 20:07:33 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Deallocated
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100 - vlr_gsupc_read_cb: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: vlr_gsupc_read_cb() returns 0
- a LU Accept with a new TMSI was sent, waiting for TMSI Realloc Compl
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
llist_count(&net->ran_conns) == 1
2017-01-25 14:04:16 +00:00
lu_result_sent == 1
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
- even though the TMSI is not acked, we can already find the subscr with it
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100 + test_ciph_tmsi: now used by 2 (conn,test_ciph_tmsi)
2017-01-25 14:04:16 +00:00
vsub != NULL == 1
strcmp(vsub->imsi, imsi) == 0
vsub->tmsi_new == 0x03020100
vsub->tmsi == 0xffffffff
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100 - test_ciph_tmsi: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
- MS sends TMSI Realloc Complete
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_TMSI_REALL_COMPL
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100: MSC conn use + dtap == 1 (0x2: dtap)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_TMSI_REALL_COMPL (0x5:0x1b)
2019-01-03 01:32:14 +00:00
DMM TMSI Reallocation Completed. Subscriber: IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_NEW_TMSI_ACK
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_TMSI_CNF}: Received Event LU_COMPL_VLR_E_NEW_TMSI_ACK
2019-02-19 01:36:35 +00:00
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100) VLR: update for IMSI=901700000004620 (MSISDN=46071)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Updated ID
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + attached: now used by 2 (conn,attached)
2019-01-03 01:32:14 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_TMSI_CNF}: state_chg to LU_COMPL_VLR_S_DONE
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_LU_COMPL_SUCCESS
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Terminating (cause = OSMO_FSM_TERM_PARENT)
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU)
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Deallocated
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: state_chg to VLR_ULA_S_DONE
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use + release == 2 (0x102: dtap,release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + vlr_subscr_cancel_attach_fsm: now used by 3 (conn,attached,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - vlr_subscr_cancel_attach_fsm: now used by 2 (conn,attached)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use - dtap == 1 (0x100: release)
2018-04-01 18:55:54 +00:00
bssap_clear_sent == 1
- LU was successful, and the conn has already been closed
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){VLR_ULA_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU))
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){VLR_ULA_S_DONE}: Removing from parent RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){VLR_ULA_S_DONE}: fsm_lu_cleanup called with cause OSMO_FSM_TERM_PARENT
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){VLR_ULA_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
2017-01-25 14:04:16 +00:00
- Subscriber has the new TMSI
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + test_ciph_tmsi: now used by 2 (attached,test_ciph_tmsi)
2017-01-25 14:04:16 +00:00
vsub != NULL == 1
strcmp(vsub->imsi, imsi) == 0
vsub->tmsi_new == 0xffffffff
vsub->tmsi == 0x03020100
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - test_ciph_tmsi: now used by 1 (attached)
2017-01-25 14:04:16 +00:00
---
- after a while, a new conn sends a CM Service Request using above TMSI. VLR responds with Auth Req, 2nd auth vector
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_CM_SERV_REQ
2017-01-25 14:04:16 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_CM_SERV_REQ (0x5:0x24)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Updated ID
DMM RAN_conn(TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Rx CM SERVICE REQUEST cm_service_type=0x08
DVLR Process_Access_Request_VLR(TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: Allocated
DVLR Process_Access_Request_VLR(TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: is child of RAN_conn(TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ)
DVLR Process_Access_Request_VLR(TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: rev=GSM net=GERAN Auth+Ciph
DVLR Process_Access_Request_VLR(TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: Received Event PR_ARQ_E_START
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + proc_arq_vlr_fn_init: now used by 2 (attached,proc_arq_vlr_fn_init)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + conn: now used by 3 (attached,proc_arq_vlr_fn_init,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Updated ID
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: proc_arq_vlr_fn_post_imsi()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: state_chg to PR_ARQ_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: is child of Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=1 -- will use GSM AKA (is_r99=no, at->vec.auth_types=0x1)
- sending GSM Auth Request for IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: tuple use_count=1 key_seq=1 auth_types=0x1 and...
2017-01-25 14:04:16 +00:00
- ...rand=12aca96fb4ffdea5c985cbafa9b6e18b
- ...expecting sres=20bde240
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - proc_arq_vlr_fn_init: now used by 2 (attached,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
auth_request_sent == 1
cm_service_result_sent == 0
- needs auth, not yet accepted
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
- MS sends Authen Response, VLR accepts and requests Ciphering
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use + dtap == 1 (0x2: dtap)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MM GSM AUTHENTICATION RESPONSE (sres = 20bde240)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100) AUTH on GERAN received SRES/RES: 20bde240 (4 bytes)
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_AUTHENTICATED}: Removing from parent Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: Received Event PR_ARQ_E_AUTH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: _proc_arq_vlr_node2()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: Set Ciphering Mode
DMM -> CIPHER MODE COMMAND IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100
- sending Ciphering Mode Command for IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: include_imeisv=0
2018-09-16 22:54:52 +00:00
- ...perm algo: A5/1
2018-03-02 00:50:09 +00:00
- ...key: 07fa7502e07e1c00
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: state_chg to PR_ARQ_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
cm_service_result_sent == 0
cipher_mode_cmd_sent == 1
- needs ciph, not yet accepted
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
- MS sends Ciphering Mode Complete, VLR accepts; above Ciphering is an implicit CM Service Accept
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: CIPHERING MODE COMPLETE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: Received Event PR_ARQ_E_CIPH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_ciph()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_vlr()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_pres()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_trace()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_imei()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: proc_arq_fsm_done(PASSED)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: state_chg to PR_ARQ_S_DONE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Process Access Request result: PASSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use + cm_service == 1 (0x8: cm_service)
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_ACCEPTED}: ran_conn_fsm_has_active_transactions: still awaiting first request after a CM Service Request
2017-01-25 14:04:16 +00:00
cm_service_result_sent == 0
2018-06-15 16:57:30 +00:00
- Concluding CM Service Request
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use - cm_service == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,conn,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,conn)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2018-04-01 18:55:54 +00:00
bssap_clear_sent == 1
- all requests serviced, conn has been released
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ))
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Removing from parent RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
2017-01-25 14:04:16 +00:00
---
- an SMS is sent, MS is paged
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + test_ciph_tmsi: now used by 2 (attached,test_ciph_tmsi)
2017-01-25 14:04:16 +00:00
llist_count(&vsub->cs.requests) == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + SMS-receiver: now used by 3 (attached,test_ciph_tmsi,SMS-receiver)
2019-01-16 11:47:39 +00:00
DLSMS Going to send a MT SMS
2019-01-03 01:32:14 +00:00
DCC (ti 00 sub IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 callref 40000002) New transaction
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + SMS: now used by 4 (attached,test_ciph_tmsi,SMS-receiver,SMS)
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) instance created for network
DLSMS SMR(0) instance created for network.
DLSMS SMR(0) message SM-RL-DATA_REQ received in state IDLE
DLSMS SMR(0) TX SMS RP-DATA
DLSMS SMR(0) new RP state IDLE -> WAIT_FOR_RP_ACK
DLSMS SMC(0) message MNSMS-EST-REQ received in state IDLE
DLSMS SMC(0) new CP state IDLE -> MM_CONN_PENDING
DLSMS Initiating Paging procedure for IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 due to MMSMS_EST_REQ
2019-01-03 01:32:14 +00:00
DMM Subscriber IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 not paged yet, start paging.
2018-12-25 23:40:18 +00:00
GERAN-A sends out paging request to IMSI 901700000004620, TMSI 0x03020100, LAC 23
2017-01-25 14:04:16 +00:00
paging_expecting_tmsi == 0x03020100
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + Paging: now used by 5 (attached,test_ciph_tmsi,SMS-receiver,SMS,Paging)
2017-01-25 14:04:16 +00:00
llist_count(&vsub->cs.requests) == 1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - test_ciph_tmsi: now used by 4 (attached,SMS-receiver,SMS,Paging)
2017-01-25 14:04:16 +00:00
paging_sent == 1
paging_stopped == 0
- the subscriber and its pending request should remain
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + test_ciph_tmsi: now used by 5 (attached,SMS-receiver,SMS,Paging,test_ciph_tmsi)
2017-01-25 14:04:16 +00:00
llist_count(&vsub->cs.requests) == 1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - test_ciph_tmsi: now used by 4 (attached,SMS-receiver,SMS,Paging)
2017-01-25 14:04:16 +00:00
- MS replies with Paging Response using TMSI, and VLR sends Auth Request with third key
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_PAG_RESP
2017-01-25 14:04:16 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_PAG_RESP (0x6:0x27)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: Updated ID
DRR RAN_conn(TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: PAGING RESPONSE
DVLR Process_Access_Request_VLR(TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: Allocated
DVLR Process_Access_Request_VLR(TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: is child of RAN_conn(TMSI-0x03020100:GERAN-A-0:PAGING_RESP)
DVLR Process_Access_Request_VLR(TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: rev=GSM net=GERAN Auth+Ciph
DVLR Process_Access_Request_VLR(TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: Received Event PR_ARQ_E_START
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + proc_arq_vlr_fn_init: now used by 5 (attached,SMS-receiver,SMS,Paging,proc_arq_vlr_fn_init)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + conn: now used by 6 (attached,SMS-receiver,SMS,Paging,proc_arq_vlr_fn_init,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: Updated ID
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: proc_arq_vlr_fn_post_imsi()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: state_chg to PR_ARQ_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: is child of Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=2 -- will use GSM AKA (is_r99=no, at->vec.auth_types=0x1)
- sending GSM Auth Request for IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: tuple use_count=1 key_seq=2 auth_types=0x1 and...
2017-01-25 14:04:16 +00:00
- ...rand=e7c03ba7cf0e2fde82b2dc4d63077d42
- ...expecting sres=a29514ae
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - proc_arq_vlr_fn_init: now used by 5 (attached,SMS-receiver,SMS,Paging,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
auth_request_sent == 1
- needs auth, not yet accepted
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
- MS sends Authen Response, VLR accepts and requests Ciphering
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use + dtap == 1 (0x2: dtap)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MM GSM AUTHENTICATION RESPONSE (sres = a29514ae)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100) AUTH on GERAN received SRES/RES: a29514ae (4 bytes)
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_AUTHENTICATED}: Removing from parent Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: Received Event PR_ARQ_E_AUTH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: _proc_arq_vlr_node2()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: Set Ciphering Mode
DMM -> CIPHER MODE COMMAND IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100
- sending Ciphering Mode Command for IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: include_imeisv=0
2018-09-16 22:54:52 +00:00
- ...perm algo: A5/1
2018-03-02 00:50:09 +00:00
- ...key: e2b234f807886400
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: state_chg to PR_ARQ_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
cipher_mode_cmd_sent == 1
- needs ciph, not yet accepted
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
- MS sends Ciphering Mode Complete, VLR accepts and sends pending SMS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: CIPHERING MODE COMPLETE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: Received Event PR_ARQ_E_CIPH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_ciph()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_vlr()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_pres()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_trace()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_imei()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: proc_arq_fsm_done(PASSED)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: state_chg to PR_ARQ_S_DONE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Process Access Request result: PASSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DPAG Paging success for IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 (event=0)
2016-05-20 19:59:55 +00:00
DPAG Calling paging cbfn.
2019-01-16 11:47:39 +00:00
DLSMS paging_cb_mmsms_est_req(hooknum=1, event=0)
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use + trans_sms == 1 (0x20: trans_sms)
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) message MMSMS-EST-CNF received in state MM_CONN_PENDING
DLSMS SMC(0) send CP data
DLSMS SMC(0) new CP state MM_CONN_PENDING -> WAIT_CP_ACK
DLSMS sending CP message (trans=0)
DLSMS GSM4.11 TX 09 01 58 01 00 07 91 44 77 58 10 06 50 00 4c 00 05 80 64 70 f1 00 00 07 10 10 00 00 00 00 44 50 79 da 1e 1e e7 41 69 37 48 5e 9e a7 c9 65 37 3d 1d 66 83 c2 70 38 3b 3d 0e d3 d3 6f f7 1c 94 9e 83 c2 20 72 79 9e 96 87 c5 ec 32 a8 1d 96 af cb f4 b4 fb 0c 7a c3 e9 e9 b7 db 05
2019-01-03 01:32:14 +00:00
DMSC msc_tx 91 bytes to IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 via GERAN-A
2018-12-25 23:40:18 +00:00
- DTAP --GERAN-A--> MS: SMS:0x01: 09015801000791447758100650004c0005806470f1000007101000000000445079da1e1ee7416937485e9ea7c965373d1d6683c270383b3d0ed3d36ff71c949e83c22072799e9687c5ec32a81d96afcbf4b4fb0c7ac3e9e9b7db05
2017-01-25 14:04:16 +00:00
- DTAP matches expected message
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - Paging: now used by 4 (attached,SMS-receiver,SMS,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_ACCEPTED}: ran_conn_fsm_has_active_transactions: connection still has active transaction: SMS
2017-01-25 14:04:16 +00:00
dtap_tx_confirmed == 1
paging_stopped == 1
- SMS was delivered, no requests pending for subscr
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + test_ciph_tmsi: now used by 5 (attached,SMS-receiver,SMS,conn,test_ciph_tmsi)
2017-01-25 14:04:16 +00:00
llist_count(&vsub->cs.requests) == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - test_ciph_tmsi: now used by 4 (attached,SMS-receiver,SMS,conn)
2017-01-25 14:04:16 +00:00
- conn is still open to wait for SMS ack dance
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
llist_count(&net->ran_conns) == 1
2017-01-25 14:04:16 +00:00
- MS replies with CP-ACK for received SMS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: SMS:0x04
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use + dtap == 2 (0x22: dtap,trans_sms)
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x04 (0x9:0x4)
2019-01-16 11:47:39 +00:00
DLSMS receiving data (trans_id=0, msg_type=SMS:0x04)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_COMMUNICATING
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_COMMUNICATING
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) message MMSMS-DATA-IND (CP ACK) received in state WAIT_CP_ACK
DLSMS SMC(0) received CP-ACK
DLSMS SMC(0) new CP state WAIT_CP_ACK -> MM_ESTABLISHED
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use - dtap == 1 (0x20: trans_sms)
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
llist_count(&net->ran_conns) == 1
2017-01-25 14:04:16 +00:00
- MS also sends RP-ACK, MSC in turn sends CP-ACK for that
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: SMS:0x01
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use + dtap == 2 (0x22: dtap,trans_sms)
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-16 11:47:39 +00:00
DLSMS receiving data (trans_id=0, msg_type=SMS:0x01)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_COMMUNICATING}: Received Event RAN_CONN_E_COMMUNICATING
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) message MMSMS-DATA-IND (CP DATA) received in state MM_ESTABLISHED
DLSMS SMC(0) received CP-DATA
DLSMS sending CP message (trans=0)
DLSMS GSM4.11 TX 09 04
2019-01-03 01:32:14 +00:00
DMSC msc_tx 2 bytes to IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 via GERAN-A
2018-12-25 23:40:18 +00:00
- DTAP --GERAN-A--> MS: SMS:0x04: 0904
2017-01-25 14:04:16 +00:00
- DTAP matches expected message
2019-01-16 11:47:39 +00:00
DLSMS MNSMS-DATA/EST-IND
DLSMS SMR(0) message MNSMS-DATA-IND received in state WAIT_FOR_RP_ACK
DLSMS SMR(0) RX SMS RP-ACK
DLSMS SMR(0) new RP state WAIT_FOR_RP_ACK -> IDLE
DLSMS RX SMS RP-ACK (MO)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - SMS-receiver: now used by 3 (attached,SMS,conn)
2019-01-16 11:47:39 +00:00
DLSMS SMR(0) TX: MNSMS-REL-REQ
DLSMS SMC(0) message MNSMS-REL-REQ received in state MM_ESTABLISHED
DLSMS SMC(0) new CP state MM_ESTABLISHED -> IDLE
DLSMS Got MMSMS_REL_REQ, destroying transaction.
DLSMS SMR(0) clearing SMR instance
DLSMS SMC(0) clearing instance
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - SMS: now used by 2 (attached,conn)
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use - trans_sms == 1 (0x2: dtap)
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_COMMUNICATING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_COMMUNICATING}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,conn,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,conn)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2018-04-01 18:55:54 +00:00
dtap_tx_confirmed == 1
bssap_clear_sent == 1
- SMS is done, conn is gone
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP))
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Removing from parent RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
2017-01-25 14:04:16 +00:00
---
- subscriber detaches, using TMSI
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_IMSI_DETACH_IND
2017-01-25 14:04:16 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_IMSI_DETACH_IND (0x5:0x1)
2017-01-25 14:04:16 +00:00
DMM IMSI DETACH INDICATION: MI(TMSI)=50462976
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + gsm48_rx_mm_imsi_detach_ind: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
2019-01-03 01:32:14 +00:00
DMM IMSI DETACH for IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,gsm48_rx_mm_imsi_detach_ind,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - attached: now used by 1 (gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - gsm48_rx_mm_imsi_detach_ind: now used by 0 (-)
2019-01-03 01:32:14 +00:00
DREF freeing VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100
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
DMM RAN_conn{RAN_CONN_S_NEW}: Received Event RAN_CONN_E_CN_CLOSE
DMM RAN_conn{RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_RELEASING
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + release == 2 (0x101: compl_l3,release)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use - compl_l3 == 1 (0x100: release)
2018-04-01 18:55:54 +00:00
bssap_clear_sent == 1
- BSS sends BSSMAP Clear Complete
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use - release == 0 (0x0: )
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
DMM RAN_conn{RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn{RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn{RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DRLL Freeing RAN connection with NULL subscriber
DMM RAN_conn{RAN_CONN_S_RELEASED}: Deallocated
llist_count(&net->ran_conns) == 0
2018-03-01 23:40:58 +00:00
===== test_ciph_tmsi: SUCCESS
2017-01-25 14:04:16 +00:00
full talloc report on 'msgb' (total 0 bytes in 1 blocks)
2018-12-06 11:06:59 +00:00
talloc_total_blocks(tall_bsc_ctx) == 13
2017-01-25 14:04:16 +00:00
2018-03-01 23:40:58 +00:00
===== test_ciph_imei
2017-01-25 14:04:16 +00:00
- Location Update request causes a GSUP Send Auth Info request to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_LOC_UPD_REQUEST
2017-01-25 14:04:16 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_LOC_UPD_REQUEST (0x5:0x8)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: LOCATION UPDATING REQUEST: MI=IMSI-901700000004620 LU-type=IMSI-ATTACH
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: LU/new-LAC: 1/23
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Allocated
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: is child of RAN_conn(IMSI-901700000004620:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: rev=GSM net=GERAN Auth+Ciph
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Received Event VLR_ULA_E_UPDATE_LA
2019-02-19 01:36:35 +00:00
DREF VLR subscr unknown + _lu_fsm_associate_vsub: now used by 1 (_lu_fsm_associate_vsub)
2017-01-25 14:04:16 +00:00
DVLR set IMSI on subscriber; IMSI=901700000004620 id=901700000004620
DVLR New subscr, IMSI: 901700000004620
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + conn: now used by 2 (_lu_fsm_associate_vsub,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - _lu_fsm_associate_vsub: now used by 1 (conn)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: vlr_loc_upd_node1()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: state_chg to VLR_ULA_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: is child of vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
2017-01-25 14:04:16 +00:00
DVLR GSUP tx: 08010809710000004026f0
GSUP --> HLR: OSMO_GSUP_MSGT_SEND_AUTH_INFO_REQUEST: 08010809710000004026f0
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_NEEDS_AUTH_WAIT_AI
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000004620: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- from HLR, rx _SEND_AUTH_INFO_RESULT; VLR sends Auth Req to MS
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: 0a010809710000004026f003222010585df1ae287f6e273dce07090d61320b21042d8b2c3e220861855fb81fc2a8000322201012aca96fb4ffdea5c985cbafa9b6e18b210420bde240220807fa7502e07e1c0003222010e7c03ba7cf0e2fde82b2dc4d63077d422104a29514ae2208e2b234f80788640003222010fa8f20b781b5881329d4fea26b1a3c5121045afc8d7222082392f14f709ae000032220100fd4cc8dbe8715d1f439e304edfd68dc2104bc8d1c5b2208da7cdd6bfe2d7000
DVLR GSUP rx 191: 0a010809710000004026f003222010585df1ae287f6e273dce07090d61320b21042d8b2c3e220861855fb81fc2a8000322201012aca96fb4ffdea5c985cbafa9b6e18b210420bde240220807fa7502e07e1c0003222010e7c03ba7cf0e2fde82b2dc4d63077d422104a29514ae2208e2b234f80788640003222010fa8f20b781b5881329d4fea26b1a3c5121045afc8d7222082392f14f709ae000032220100fd4cc8dbe8715d1f439e304edfd68dc2104bc8d1c5b2208da7cdd6bfe2d7000
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: Received Event VLR_AUTH_E_HLR_SAI_ACK
DVLR SUBSCR(IMSI-901700000004620) Received 5 auth tuples
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=0 -- will use GSM AKA (is_r99=no, at->vec.auth_types=0x1)
- sending GSM Auth Request for IMSI-901700000004620: tuple use_count=1 key_seq=0 auth_types=0x1 and...
2017-01-25 14:04:16 +00:00
- ...rand=585df1ae287f6e273dce07090d61320b
- ...expecting sres=2d8b2c3e
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - vlr_gsupc_read_cb: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: vlr_gsupc_read_cb() returns 0
auth_request_sent == 1
lu_result_sent == 0
- MS sends Authen Response, VLR accepts and sends Ciphering Mode Command to MS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620: MSC conn use + dtap == 1 (0x2: dtap)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000004620: MM GSM AUTHENTICATION RESPONSE (sres = 2d8b2c3e)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000004620) AUTH on GERAN received SRES/RES: 2d8b2c3e (4 bytes)
DVLR SUBSCR(IMSI-901700000004620) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Received Event VLR_ULA_E_AUTH_RES
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: vlr_loc_upd_post_auth()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Set Ciphering Mode
DMM -> CIPHER MODE COMMAND IMSI-901700000004620
- sending Ciphering Mode Command for IMSI-901700000004620: include_imeisv=0
2018-09-16 22:54:52 +00:00
- ...perm algo: A5/1
2018-03-02 00:50:09 +00:00
- ...key: 61855fb81fc2a800
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: state_chg to VLR_ULA_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- needs ciph, not yet accepted
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- MS sends Ciphering Mode Complete, VLR accepts and sends GSUP LU Req to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000004620: CIPHERING MODE COMPLETE
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: Received Event VLR_ULA_E_CIPH_RES
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_post_ciph()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_node_4()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: state_chg to VLR_ULA_S_WAIT_HLR_UPD
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Allocated
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Received Event UPD_HLR_VLR_E_START
2018-09-28 00:41:39 +00:00
DVLR GSUP tx: 04010809710000004026f0280102
GSUP --> HLR: OSMO_GSUP_MSGT_UPDATE_LOCATION_REQUEST: 04010809710000004026f0280102
2019-01-03 01:32:14 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: state_chg to UPD_HLR_VLR_S_WAIT_FOR_DATA
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- HLR sends _INSERT_DATA_REQUEST, VLR responds with _INSERT_DATA_RESULT
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: 10010809710000004026f00804036470f1
DVLR GSUP rx 17: 10010809710000004026f00804036470f1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2017-01-25 14:04:16 +00:00
DVLR IMSI:901700000004620 has MSISDN:46071
2019-02-19 01:36:35 +00:00
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071) VLR: update for IMSI=901700000004620 (MSISDN=46071)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Updated ID
2017-01-25 14:04:16 +00:00
DVLR GSUP tx: 12010809710000004026f0
GSUP --> HLR: OSMO_GSUP_MSGT_INSERT_DATA_RESULT: 12010809710000004026f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_gsupc_read_cb: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: vlr_gsupc_read_cb() returns 0
lu_result_sent == 0
- HLR also sends GSUP _UPDATE_LOCATION_RESULT, and we send an ID Request for the IMEI to the MS
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: 06010809710000004026f0
DVLR GSUP rx 11: 06010809710000004026f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_HLR_LU_RES
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: Received Event UPD_HLR_VLR_E_UPD_LOC_ACK
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: state_chg to UPD_HLR_VLR_S_DONE
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_UPD_HLR_COMPL
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: state_chg to VLR_ULA_S_WAIT_LU_COMPL
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Allocated
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Received Event LU_COMPL_VLR_E_START
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: state_chg to LU_COMPL_VLR_S_WAIT_SUB_PRES
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: Received Event LU_COMPL_VLR_E_SUB_PRES_COMPL
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: state_chg to LU_COMPL_VLR_S_WAIT_IMEI
DMSC msc_tx 3 bytes to IMSI-901700000004620:MSISDN-46071 via GERAN-A
2018-12-25 23:40:18 +00:00
- DTAP --GERAN-A--> MS: GSM48_MT_MM_ID_REQ: 051802
2017-01-25 14:04:16 +00:00
- DTAP matches expected message
2019-03-24 20:07:33 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Deallocated
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_gsupc_read_cb: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: vlr_gsupc_read_cb() returns 0
- We will only do business when the IMEI is known
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
llist_count(&net->ran_conns) == 1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + test_ciph_imei: now used by 2 (conn,test_ciph_imei)
2017-01-25 14:04:16 +00:00
vsub->imei[0] == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - test_ciph_imei: now used by 1 (conn)
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: SMS:0x01
2018-12-14 16:37:38 +00:00
- MS replies with an Identity Response, VLR sends the IMEI to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_ID_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use + dtap == 1 (0x2: dtap)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_ID_RESP (0x5:0x19)
2019-01-10 23:04:32 +00:00
DMM IDENTITY RESPONSE: MI=IMEI-423423423423420
2017-07-20 00:56:21 +00:00
DVLR set IMEI on subscriber; IMSI=901700000004620 IMEI=423423423423420
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_ID_IMEI
2018-12-14 16:37:38 +00:00
DVLR GSUP tx: 30010809710000004026f050090824433224433224f0
GSUP --> HLR: OSMO_GSUP_MSGT_CHECK_IMEI_REQUEST: 30010809710000004026f050090824433224433224f0
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
ran_conn_is_accepted() == false
requests shall be thwarted
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_CC_SETUP
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: unknown 0x33
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: SMS:0x01
- HLR accepts the IMEI
<-- GSUP rx OSMO_GSUP_MSGT_CHECK_IMEI_RESULT: 32010809710000004026f0510100
DVLR GSUP rx 14: 32010809710000004026f0510100
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2018-12-14 16:37:38 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_HLR_IMEI_ACK
2019-01-03 01:32:14 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_IMEI}: Received Event LU_COMPL_VLR_E_IMEI_CHECK_ACK
- sending LU Accept for IMSI-901700000004620:MSISDN-46071
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + attached: now used by 3 (conn,vlr_gsupc_read_cb,attached)
2019-01-03 01:32:14 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_IMEI}: state_chg to LU_COMPL_VLR_S_DONE
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_LU_COMPL_SUCCESS
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Terminating (cause = OSMO_FSM_TERM_PARENT)
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Deallocated
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: state_chg to VLR_ULA_S_DONE
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_RELEASING
2018-12-14 16:37:38 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_subscr_cancel_attach_fsm: now used by 4 (conn,vlr_gsupc_read_cb,attached,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_subscr_cancel_attach_fsm: now used by 3 (conn,vlr_gsupc_read_cb,attached)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_gsupc_read_cb: now used by 2 (conn,attached)
2018-12-14 16:37:38 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_CHECK_IMEI_RESULT: vlr_gsupc_read_cb() returns 0
2018-04-01 18:55:54 +00:00
bssap_clear_sent == 1
- LU was successful, and the conn has already been closed
lu_result_sent == 1
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU))
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_DONE}: Removing from parent RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_DONE}: fsm_lu_cleanup called with cause OSMO_FSM_TERM_PARENT
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000004620:MSISDN-46071: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
2017-01-25 14:04:16 +00:00
- Subscriber has the IMEI
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + test_ciph_imei: now used by 2 (attached,test_ciph_imei)
2017-07-20 00:56:21 +00:00
strcmp(vsub->imei, "423423423423420") == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - test_ciph_imei: now used by 1 (attached)
2017-01-25 14:04:16 +00:00
---
- subscriber detaches
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_IMSI_DETACH_IND
2017-01-25 14:04:16 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_IMSI_DETACH_IND (0x5:0x1)
2017-01-25 14:04:16 +00:00
DMM IMSI DETACH INDICATION: MI(IMSI)=901700000004620
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + gsm48_rx_mm_imsi_detach_ind: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
2019-01-03 01:32:14 +00:00
DMM IMSI DETACH for IMSI-901700000004620:MSISDN-46071
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,gsm48_rx_mm_imsi_detach_ind,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - attached: now used by 1 (gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - gsm48_rx_mm_imsi_detach_ind: now used by 0 (-)
2019-01-03 01:32:14 +00:00
DREF freeing VLR subscr IMSI-901700000004620:MSISDN-46071
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
DMM RAN_conn{RAN_CONN_S_NEW}: Received Event RAN_CONN_E_CN_CLOSE
DMM RAN_conn{RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_RELEASING
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + release == 2 (0x101: compl_l3,release)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use - compl_l3 == 1 (0x100: release)
2018-04-01 18:55:54 +00:00
bssap_clear_sent == 1
- BSS sends BSSMAP Clear Complete
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use - release == 0 (0x0: )
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
DMM RAN_conn{RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn{RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn{RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DRLL Freeing RAN connection with NULL subscriber
DMM RAN_conn{RAN_CONN_S_RELEASED}: Deallocated
llist_count(&net->ran_conns) == 0
2018-03-01 23:40:58 +00:00
===== test_ciph_imei: SUCCESS
2017-01-25 14:04:16 +00:00
full talloc report on 'msgb' (total 0 bytes in 1 blocks)
2018-12-06 11:06:59 +00:00
talloc_total_blocks(tall_bsc_ctx) == 13
2017-01-25 14:04:16 +00:00
2018-03-01 23:40:58 +00:00
===== test_ciph_imeisv
2017-01-25 14:04:16 +00:00
- Location Update request causes a GSUP Send Auth Info request to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_LOC_UPD_REQUEST
2017-01-25 14:04:16 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_LOC_UPD_REQUEST (0x5:0x8)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: LOCATION UPDATING REQUEST: MI=IMSI-901700000004620 LU-type=IMSI-ATTACH
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: LU/new-LAC: 1/23
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Allocated
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: is child of RAN_conn(IMSI-901700000004620:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: rev=GSM net=GERAN Auth+Ciph
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Received Event VLR_ULA_E_UPDATE_LA
2019-02-19 01:36:35 +00:00
DREF VLR subscr unknown + _lu_fsm_associate_vsub: now used by 1 (_lu_fsm_associate_vsub)
2017-01-25 14:04:16 +00:00
DVLR set IMSI on subscriber; IMSI=901700000004620 id=901700000004620
DVLR New subscr, IMSI: 901700000004620
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + conn: now used by 2 (_lu_fsm_associate_vsub,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - _lu_fsm_associate_vsub: now used by 1 (conn)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: vlr_loc_upd_node1()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: state_chg to VLR_ULA_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: is child of vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
2017-01-25 14:04:16 +00:00
DVLR GSUP tx: 08010809710000004026f0
GSUP --> HLR: OSMO_GSUP_MSGT_SEND_AUTH_INFO_REQUEST: 08010809710000004026f0
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_NEEDS_AUTH_WAIT_AI
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000004620: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- from HLR, rx _SEND_AUTH_INFO_RESULT; VLR sends Auth Req to MS
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: 0a010809710000004026f003222010585df1ae287f6e273dce07090d61320b21042d8b2c3e220861855fb81fc2a8000322201012aca96fb4ffdea5c985cbafa9b6e18b210420bde240220807fa7502e07e1c0003222010e7c03ba7cf0e2fde82b2dc4d63077d422104a29514ae2208e2b234f80788640003222010fa8f20b781b5881329d4fea26b1a3c5121045afc8d7222082392f14f709ae000032220100fd4cc8dbe8715d1f439e304edfd68dc2104bc8d1c5b2208da7cdd6bfe2d7000
DVLR GSUP rx 191: 0a010809710000004026f003222010585df1ae287f6e273dce07090d61320b21042d8b2c3e220861855fb81fc2a8000322201012aca96fb4ffdea5c985cbafa9b6e18b210420bde240220807fa7502e07e1c0003222010e7c03ba7cf0e2fde82b2dc4d63077d422104a29514ae2208e2b234f80788640003222010fa8f20b781b5881329d4fea26b1a3c5121045afc8d7222082392f14f709ae000032220100fd4cc8dbe8715d1f439e304edfd68dc2104bc8d1c5b2208da7cdd6bfe2d7000
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: Received Event VLR_AUTH_E_HLR_SAI_ACK
DVLR SUBSCR(IMSI-901700000004620) Received 5 auth tuples
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=0 -- will use GSM AKA (is_r99=no, at->vec.auth_types=0x1)
- sending GSM Auth Request for IMSI-901700000004620: tuple use_count=1 key_seq=0 auth_types=0x1 and...
2017-01-25 14:04:16 +00:00
- ...rand=585df1ae287f6e273dce07090d61320b
- ...expecting sres=2d8b2c3e
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - vlr_gsupc_read_cb: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: vlr_gsupc_read_cb() returns 0
auth_request_sent == 1
lu_result_sent == 0
- MS sends Authen Response, VLR accepts and sends Ciphering Mode Command to MS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620: MSC conn use + dtap == 1 (0x2: dtap)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000004620: MM GSM AUTHENTICATION RESPONSE (sres = 2d8b2c3e)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000004620) AUTH on GERAN received SRES/RES: 2d8b2c3e (4 bytes)
DVLR SUBSCR(IMSI-901700000004620) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Received Event VLR_ULA_E_AUTH_RES
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: vlr_loc_upd_post_auth()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Set Ciphering Mode
DMM -> CIPHER MODE COMMAND IMSI-901700000004620
- sending Ciphering Mode Command for IMSI-901700000004620: include_imeisv=1
2018-09-16 22:54:52 +00:00
- ...perm algo: A5/1
2018-03-02 00:50:09 +00:00
- ...key: 61855fb81fc2a800
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: state_chg to VLR_ULA_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
cipher_mode_cmd_sent == 1
cipher_mode_cmd_sent_with_imeisv == 1
lu_result_sent == 0
- needs ciph, not yet accepted
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + test_ciph_imeisv: now used by 2 (conn,test_ciph_imeisv)
2017-01-25 14:04:16 +00:00
vsub->imeisv[0] == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - test_ciph_imeisv: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
- MS sends Ciphering Mode Complete with IMEISV, VLR accepts and sends GSUP LU Req to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000004620: CIPHERING MODE COMPLETE
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: Received Event VLR_ULA_E_CIPH_RES
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: got IMEISV: 4234234234234275F
2017-07-20 00:56:21 +00:00
DVLR set IMEISV on subscriber; IMSI=901700000004620 IMEISV=4234234234234275
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_post_ciph()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_node_4()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: state_chg to VLR_ULA_S_WAIT_HLR_UPD
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Allocated
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Received Event UPD_HLR_VLR_E_START
2018-09-28 00:41:39 +00:00
DVLR GSUP tx: 04010809710000004026f0280102
GSUP --> HLR: OSMO_GSUP_MSGT_UPDATE_LOCATION_REQUEST: 04010809710000004026f0280102
2019-01-03 01:32:14 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: state_chg to UPD_HLR_VLR_S_WAIT_FOR_DATA
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- Subscriber has the IMEISV
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + test_ciph_imeisv: now used by 2 (conn,test_ciph_imeisv)
2017-07-20 00:56:21 +00:00
strcmp(vsub->imeisv, "4234234234234275") == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - test_ciph_imeisv: now used by 1 (conn)
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
- HLR sends _INSERT_DATA_REQUEST, VLR responds with _INSERT_DATA_RESULT
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: 10010809710000004026f00804036470f1
DVLR GSUP rx 17: 10010809710000004026f00804036470f1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2017-01-25 14:04:16 +00:00
DVLR IMSI:901700000004620 has MSISDN:46071
2019-02-19 01:36:35 +00:00
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071) VLR: update for IMSI=901700000004620 (MSISDN=46071)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Updated ID
2017-01-25 14:04:16 +00:00
DVLR GSUP tx: 12010809710000004026f0
GSUP --> HLR: OSMO_GSUP_MSGT_INSERT_DATA_RESULT: 12010809710000004026f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_gsupc_read_cb: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: vlr_gsupc_read_cb() returns 0
lu_result_sent == 0
- HLR also sends GSUP _UPDATE_LOCATION_RESULT
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: 06010809710000004026f0
DVLR GSUP rx 11: 06010809710000004026f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_HLR_LU_RES
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: Received Event UPD_HLR_VLR_E_UPD_LOC_ACK
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: state_chg to UPD_HLR_VLR_S_DONE
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_UPD_HLR_COMPL
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: state_chg to VLR_ULA_S_WAIT_LU_COMPL
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Allocated
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Received Event LU_COMPL_VLR_E_START
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: state_chg to LU_COMPL_VLR_S_WAIT_SUB_PRES
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: Received Event LU_COMPL_VLR_E_SUB_PRES_COMPL
- sending LU Accept for IMSI-901700000004620:MSISDN-46071
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + attached: now used by 3 (conn,vlr_gsupc_read_cb,attached)
2019-01-03 01:32:14 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: state_chg to LU_COMPL_VLR_S_DONE
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_LU_COMPL_SUCCESS
2019-03-24 20:07:33 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU))
2019-01-03 01:32:14 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
2019-03-24 20:07:33 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Deferring: will deallocate with upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: state_chg to VLR_ULA_S_DONE
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_subscr_cancel_attach_fsm: now used by 4 (conn,vlr_gsupc_read_cb,attached,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_subscr_cancel_attach_fsm: now used by 3 (conn,vlr_gsupc_read_cb,attached)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2019-03-24 20:07:33 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Deallocated, including all deferred deallocations
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_gsupc_read_cb: now used by 2 (conn,attached)
2018-04-01 18:55:54 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: vlr_gsupc_read_cb() returns 0
bssap_clear_sent == 1
- LU was successful, and the conn has already been closed
lu_result_sent == 1
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU))
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_DONE}: Removing from parent RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_DONE}: fsm_lu_cleanup called with cause OSMO_FSM_TERM_PARENT
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000004620:MSISDN-46071: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
2017-01-25 14:04:16 +00:00
---
- subscriber detaches
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_IMSI_DETACH_IND
2017-01-25 14:04:16 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_IMSI_DETACH_IND (0x5:0x1)
2017-01-25 14:04:16 +00:00
DMM IMSI DETACH INDICATION: MI(IMSI)=901700000004620
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + gsm48_rx_mm_imsi_detach_ind: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
2019-01-03 01:32:14 +00:00
DMM IMSI DETACH for IMSI-901700000004620:MSISDN-46071
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,gsm48_rx_mm_imsi_detach_ind,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - attached: now used by 1 (gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - gsm48_rx_mm_imsi_detach_ind: now used by 0 (-)
2019-01-03 01:32:14 +00:00
DREF freeing VLR subscr IMSI-901700000004620:MSISDN-46071
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
DMM RAN_conn{RAN_CONN_S_NEW}: Received Event RAN_CONN_E_CN_CLOSE
DMM RAN_conn{RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_RELEASING
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + release == 2 (0x101: compl_l3,release)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use - compl_l3 == 1 (0x100: release)
2018-04-01 18:55:54 +00:00
bssap_clear_sent == 1
- BSS sends BSSMAP Clear Complete
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use - release == 0 (0x0: )
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
DMM RAN_conn{RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn{RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn{RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DRLL Freeing RAN connection with NULL subscriber
DMM RAN_conn{RAN_CONN_S_RELEASED}: Deallocated
llist_count(&net->ran_conns) == 0
2018-03-01 23:40:58 +00:00
===== test_ciph_imeisv: SUCCESS
2017-01-25 14:04:16 +00:00
full talloc report on 'msgb' (total 0 bytes in 1 blocks)
2018-12-06 11:06:59 +00:00
talloc_total_blocks(tall_bsc_ctx) == 13
2017-01-25 14:04:16 +00:00
2018-03-01 23:40:58 +00:00
===== test_ciph_tmsi_imei
2017-01-25 14:04:16 +00:00
- Location Update request causes a GSUP Send Auth Info request to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_LOC_UPD_REQUEST
2017-01-25 14:04:16 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_LOC_UPD_REQUEST (0x5:0x8)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: LOCATION UPDATING REQUEST: MI=IMSI-901700000004620 LU-type=IMSI-ATTACH
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: LU/new-LAC: 1/23
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Allocated
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: is child of RAN_conn(IMSI-901700000004620:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: rev=GSM net=GERAN Auth+Ciph
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Received Event VLR_ULA_E_UPDATE_LA
2019-02-19 01:36:35 +00:00
DREF VLR subscr unknown + _lu_fsm_associate_vsub: now used by 1 (_lu_fsm_associate_vsub)
2017-01-25 14:04:16 +00:00
DVLR set IMSI on subscriber; IMSI=901700000004620 id=901700000004620
DVLR New subscr, IMSI: 901700000004620
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + conn: now used by 2 (_lu_fsm_associate_vsub,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - _lu_fsm_associate_vsub: now used by 1 (conn)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: vlr_loc_upd_node1()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: state_chg to VLR_ULA_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: is child of vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
2017-01-25 14:04:16 +00:00
DVLR GSUP tx: 08010809710000004026f0
GSUP --> HLR: OSMO_GSUP_MSGT_SEND_AUTH_INFO_REQUEST: 08010809710000004026f0
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_NEEDS_AUTH_WAIT_AI
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000004620: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- from HLR, rx _SEND_AUTH_INFO_RESULT; VLR sends Auth Req to MS
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: 0a010809710000004026f003222010585df1ae287f6e273dce07090d61320b21042d8b2c3e220861855fb81fc2a8000322201012aca96fb4ffdea5c985cbafa9b6e18b210420bde240220807fa7502e07e1c0003222010e7c03ba7cf0e2fde82b2dc4d63077d422104a29514ae2208e2b234f80788640003222010fa8f20b781b5881329d4fea26b1a3c5121045afc8d7222082392f14f709ae000032220100fd4cc8dbe8715d1f439e304edfd68dc2104bc8d1c5b2208da7cdd6bfe2d7000
DVLR GSUP rx 191: 0a010809710000004026f003222010585df1ae287f6e273dce07090d61320b21042d8b2c3e220861855fb81fc2a8000322201012aca96fb4ffdea5c985cbafa9b6e18b210420bde240220807fa7502e07e1c0003222010e7c03ba7cf0e2fde82b2dc4d63077d422104a29514ae2208e2b234f80788640003222010fa8f20b781b5881329d4fea26b1a3c5121045afc8d7222082392f14f709ae000032220100fd4cc8dbe8715d1f439e304edfd68dc2104bc8d1c5b2208da7cdd6bfe2d7000
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: Received Event VLR_AUTH_E_HLR_SAI_ACK
DVLR SUBSCR(IMSI-901700000004620) Received 5 auth tuples
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=0 -- will use GSM AKA (is_r99=no, at->vec.auth_types=0x1)
- sending GSM Auth Request for IMSI-901700000004620: tuple use_count=1 key_seq=0 auth_types=0x1 and...
2017-01-25 14:04:16 +00:00
- ...rand=585df1ae287f6e273dce07090d61320b
- ...expecting sres=2d8b2c3e
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - vlr_gsupc_read_cb: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: vlr_gsupc_read_cb() returns 0
auth_request_sent == 1
lu_result_sent == 0
- MS sends Authen Response, VLR accepts and sends Ciphering Mode Command to MS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620: MSC conn use + dtap == 1 (0x2: dtap)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000004620: MM GSM AUTHENTICATION RESPONSE (sres = 2d8b2c3e)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000004620) AUTH on GERAN received SRES/RES: 2d8b2c3e (4 bytes)
DVLR SUBSCR(IMSI-901700000004620) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Received Event VLR_ULA_E_AUTH_RES
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: vlr_loc_upd_post_auth()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Set Ciphering Mode
DMM -> CIPHER MODE COMMAND IMSI-901700000004620
- sending Ciphering Mode Command for IMSI-901700000004620: include_imeisv=0
2018-09-16 22:54:52 +00:00
- ...perm algo: A5/1
2018-03-02 00:50:09 +00:00
- ...key: 61855fb81fc2a800
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: state_chg to VLR_ULA_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- needs ciph, not yet accepted
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- MS sends Ciphering Mode Complete, VLR accepts and sends GSUP LU Req to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000004620: CIPHERING MODE COMPLETE
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: Received Event VLR_ULA_E_CIPH_RES
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_post_ciph()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_node_4()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: state_chg to VLR_ULA_S_WAIT_HLR_UPD
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Allocated
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Received Event UPD_HLR_VLR_E_START
2018-09-28 00:41:39 +00:00
DVLR GSUP tx: 04010809710000004026f0280102
GSUP --> HLR: OSMO_GSUP_MSGT_UPDATE_LOCATION_REQUEST: 04010809710000004026f0280102
2019-01-03 01:32:14 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: state_chg to UPD_HLR_VLR_S_WAIT_FOR_DATA
2017-01-25 14:04:16 +00:00
lu_result_sent == 0
- HLR sends _INSERT_DATA_REQUEST, VLR responds with _INSERT_DATA_RESULT
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: 10010809710000004026f00804036470f1
DVLR GSUP rx 17: 10010809710000004026f00804036470f1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2017-01-25 14:04:16 +00:00
DVLR IMSI:901700000004620 has MSISDN:46071
2019-02-19 01:36:35 +00:00
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071) VLR: update for IMSI=901700000004620 (MSISDN=46071)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Updated ID
2017-01-25 14:04:16 +00:00
DVLR GSUP tx: 12010809710000004026f0
GSUP --> HLR: OSMO_GSUP_MSGT_INSERT_DATA_RESULT: 12010809710000004026f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_gsupc_read_cb: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: vlr_gsupc_read_cb() returns 0
lu_result_sent == 0
- HLR also sends GSUP _UPDATE_LOCATION_RESULT, and we send an ID Request for the IMEI to the MS
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: 06010809710000004026f0
DVLR GSUP rx 11: 06010809710000004026f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_HLR_LU_RES
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: Received Event UPD_HLR_VLR_E_UPD_LOC_ACK
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: state_chg to UPD_HLR_VLR_S_DONE
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_UPD_HLR_COMPL
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: state_chg to VLR_ULA_S_WAIT_LU_COMPL
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Allocated
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU)
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Received Event LU_COMPL_VLR_E_START
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: state_chg to LU_COMPL_VLR_S_WAIT_SUB_PRES
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: Received Event LU_COMPL_VLR_E_SUB_PRES_COMPL
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: state_chg to LU_COMPL_VLR_S_WAIT_IMEI_TMSI
DMSC msc_tx 3 bytes to IMSI-901700000004620:MSISDN-46071 via GERAN-A
2018-12-25 23:40:18 +00:00
- DTAP --GERAN-A--> MS: GSM48_MT_MM_ID_REQ: 051802
2017-01-25 14:04:16 +00:00
- DTAP matches expected message
2019-03-24 20:07:33 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Deallocated
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - vlr_gsupc_read_cb: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: vlr_gsupc_read_cb() returns 0
- We will only do business when the IMEI is known
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
llist_count(&net->ran_conns) == 1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + test_ciph_tmsi_imei: now used by 2 (conn,test_ciph_tmsi_imei)
2017-01-25 14:04:16 +00:00
vsub->imei[0] == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 - test_ciph_tmsi_imei: now used by 1 (conn)
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: SMS:0x01
2018-12-14 16:37:38 +00:00
- MS replies with an Identity Response, VLR sends the IMEI to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_ID_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use + dtap == 1 (0x2: dtap)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_ID_RESP (0x5:0x19)
2019-01-10 23:04:32 +00:00
DMM IDENTITY RESPONSE: MI=IMEI-423423423423420
2017-07-20 00:56:21 +00:00
DVLR set IMEI on subscriber; IMSI=901700000004620 IMEI=423423423423420
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_ID_IMEI
2018-12-14 16:37:38 +00:00
DVLR GSUP tx: 30010809710000004026f050090824433224433224f0
GSUP --> HLR: OSMO_GSUP_MSGT_CHECK_IMEI_REQUEST: 30010809710000004026f050090824433224433224f0
DREF IMSI-901700000004620:MSISDN-46071: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
ran_conn_is_accepted() == false
requests shall be thwarted
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_CC_SETUP
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: unknown 0x33
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
DRLL subscr IMSI-901700000004620:MSISDN-46071: Message not permitted for initial conn: SMS:0x01
- HLR accepts the IMEI
<-- GSUP rx OSMO_GSUP_MSGT_CHECK_IMEI_RESULT: 32010809710000004026f0510100
DVLR GSUP rx 14: 32010809710000004026f0510100
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2018-12-14 16:37:38 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_HLR_IMEI_ACK
2019-01-03 01:32:14 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_IMEI_TMSI}: Received Event LU_COMPL_VLR_E_IMEI_CHECK_ACK
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_IMEI_TMSI}: lu_compl_vlr_new_tmsi()
2019-02-19 01:36:35 +00:00
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100) VLR: update for IMSI=901700000004620 (MSISDN=46071)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Updated ID
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_IMEI_TMSI}: state_chg to LU_COMPL_VLR_S_WAIT_TMSI_CNF
- sending LU Accept for IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100, with TMSI 0x03020100
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100 - vlr_gsupc_read_cb: now used by 1 (conn)
2018-12-14 16:37:38 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_CHECK_IMEI_RESULT: vlr_gsupc_read_cb() returns 0
2017-01-25 14:04:16 +00:00
- a LU Accept with a new TMSI was sent, waiting for TMSI Realloc Compl
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
llist_count(&net->ran_conns) == 1
2017-01-25 14:04:16 +00:00
lu_result_sent == 1
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
ran_conn_is_accepted() == false
2017-01-25 14:04:16 +00:00
requests shall be thwarted
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100: Message not permitted for initial conn: unknown 0x33
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-01-24 21:53:00 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100: Message not permitted for initial conn: SMS:0x01
2017-01-25 14:04:16 +00:00
- even though the TMSI is not acked, we can already find the subscr with it
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100 + test_ciph_tmsi_imei: now used by 2 (conn,test_ciph_tmsi_imei)
2017-01-25 14:04:16 +00:00
vsub != NULL == 1
strcmp(vsub->imsi, imsi) == 0
vsub->tmsi_new == 0x03020100
vsub->tmsi == 0xffffffff
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100 - test_ciph_tmsi_imei: now used by 1 (conn)
2017-01-25 14:04:16 +00:00
- MS sends TMSI Realloc Complete
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_TMSI_REALL_COMPL
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100: MSC conn use + dtap == 1 (0x2: dtap)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_TMSI_REALL_COMPL (0x5:0x1b)
2019-01-03 01:32:14 +00:00
DMM TMSI Reallocation Completed. Subscriber: IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSInew-0x03020100:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_NEW_TMSI_ACK
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_TMSI_CNF}: Received Event LU_COMPL_VLR_E_NEW_TMSI_ACK
2019-02-19 01:36:35 +00:00
DVLR SUBSCR(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100) VLR: update for IMSI=901700000004620 (MSISDN=46071)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Updated ID
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + attached: now used by 2 (conn,attached)
2019-01-03 01:32:14 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_TMSI_CNF}: state_chg to LU_COMPL_VLR_S_DONE
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_LU_COMPL_SUCCESS
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Terminating (cause = OSMO_FSM_TERM_PARENT)
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU)
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-46071:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Deallocated
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: state_chg to VLR_ULA_S_DONE
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use + release == 2 (0x102: dtap,release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + vlr_subscr_cancel_attach_fsm: now used by 3 (conn,attached,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - vlr_subscr_cancel_attach_fsm: now used by 2 (conn,attached)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use - dtap == 1 (0x100: release)
2018-04-01 18:55:54 +00:00
bssap_clear_sent == 1
- LU was successful, and the conn has already been closed
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){VLR_ULA_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU))
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){VLR_ULA_S_DONE}: Removing from parent RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){VLR_ULA_S_DONE}: fsm_lu_cleanup called with cause OSMO_FSM_TERM_PARENT
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){VLR_ULA_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
2017-01-25 14:04:16 +00:00
- Subscriber has the IMEI and TMSI
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + test_ciph_tmsi_imei: now used by 2 (attached,test_ciph_tmsi_imei)
2017-07-20 00:56:21 +00:00
strcmp(vsub->imei, "423423423423420") == 0
2017-01-25 14:04:16 +00:00
vsub->tmsi == 0x03020100
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - test_ciph_tmsi_imei: now used by 1 (attached)
2017-01-25 14:04:16 +00:00
---
- subscriber detaches, using TMSI
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_IMSI_DETACH_IND
2017-01-25 14:04:16 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2017-03-10 01:15:20 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_IMSI_DETACH_IND (0x5:0x1)
2017-01-25 14:04:16 +00:00
DMM IMSI DETACH INDICATION: MI(TMSI)=50462976
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + gsm48_rx_mm_imsi_detach_ind: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
2019-01-03 01:32:14 +00:00
DMM IMSI DETACH for IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,gsm48_rx_mm_imsi_detach_ind,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - attached: now used by 1 (gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100 - gsm48_rx_mm_imsi_detach_ind: now used by 0 (-)
2019-01-03 01:32:14 +00:00
DREF freeing VLR subscr IMSI-901700000004620:MSISDN-46071:TMSI-0x03020100
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
DMM RAN_conn{RAN_CONN_S_NEW}: Received Event RAN_CONN_E_CN_CLOSE
DMM RAN_conn{RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_RELEASING
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + release == 2 (0x101: compl_l3,release)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use - compl_l3 == 1 (0x100: release)
2018-04-01 18:55:54 +00:00
bssap_clear_sent == 1
- BSS sends BSSMAP Clear Complete
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use - release == 0 (0x0: )
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
DMM RAN_conn{RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn{RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn{RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DRLL Freeing RAN connection with NULL subscriber
DMM RAN_conn{RAN_CONN_S_RELEASED}: Deallocated
llist_count(&net->ran_conns) == 0
2018-03-01 23:40:58 +00:00
===== test_ciph_tmsi_imei: SUCCESS
2017-01-25 14:04:16 +00:00
full talloc report on 'msgb' (total 0 bytes in 1 blocks)
2018-12-06 11:06:59 +00:00
talloc_total_blocks(tall_bsc_ctx) == 13
2017-01-25 14:04:16 +00:00
2018-03-10 01:05:44 +00:00
===== test_gsm_ciph_in_umts_env
- Location Update request causes a GSUP Send Auth Info request to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_LOC_UPD_REQUEST
2018-03-10 01:05:44 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2018-03-10 01:05:44 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_LOC_UPD_REQUEST (0x5:0x8)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000010650:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
DMM RAN_conn(IMSI-901700000010650:GERAN-A-0:LU){RAN_CONN_S_NEW}: LOCATION UPDATING REQUEST: MI=IMSI-901700000010650 LU-type=NORMAL
DMM RAN_conn(IMSI-901700000010650:GERAN-A-0:LU){RAN_CONN_S_NEW}: LU/new-LAC: 0/23
DVLR vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Allocated
DVLR vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU){VLR_ULA_S_IDLE}: is child of RAN_conn(IMSI-901700000010650:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU){VLR_ULA_S_IDLE}: rev=R99 net=GERAN Auth+Ciph
DVLR vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Received Event VLR_ULA_E_UPDATE_LA
2019-02-19 01:36:35 +00:00
DREF VLR subscr unknown + _lu_fsm_associate_vsub: now used by 1 (_lu_fsm_associate_vsub)
2018-03-10 01:05:44 +00:00
DVLR set IMSI on subscriber; IMSI=901700000010650 id=901700000010650
DVLR New subscr, IMSI: 901700000010650
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650 + conn: now used by 2 (_lu_fsm_associate_vsub,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000010650:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650 - _lu_fsm_associate_vsub: now used by 1 (conn)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU){VLR_ULA_S_IDLE}: vlr_loc_upd_node1()
DVLR vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU){VLR_ULA_S_IDLE}: state_chg to VLR_ULA_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000010650:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000010650:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: is child of vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU)
DVLR VLR_Authenticate(IMSI-901700000010650:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
2018-03-10 01:05:44 +00:00
DVLR GSUP tx: 08010809710000000156f0
GSUP --> HLR: OSMO_GSUP_MSGT_SEND_AUTH_INFO_REQUEST: 08010809710000000156f0
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000010650:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_NEEDS_AUTH_WAIT_AI
DMM RAN_conn(IMSI-901700000010650:GERAN-A-0:LU){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000010650:GERAN-A-0:LU){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000010650: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000010650:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000010650:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2018-03-10 01:05:44 +00:00
lu_result_sent == 0
- from HLR, rx _SEND_AUTH_INFO_RESULT; VLR sends *UMTS AKA* Auth Req to MS
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: 0a010809710000000156f0036220104ac8d1cd1a51937597ca1016fe69a0fa2104dacc4b2622087a75f0ac9b84440023103747da4e31545baa2db59e500bdae04724108544d35b945ccba01a7f1293575291c325102d837d2b0d6f00004b282d5acf23428d270837527064741f8ddb03622010b2661531b97b12c5a2edc21a0ed16fc521042fb4cfad2208da149b11d473f40023103fe013b1a428ea737c37f8f0288c8edf2410f275438c02b97e4d6f639dddda3d10b9251078cdd96c60840000322f421b3bb778b12708ed3ebf9cb6ea48ed0362201054d8f19778056666b41c8c25e52eb60c21040ff61e0f220826ec67fad307300023102868b0922c652616f1c975e3eaf7943a24106a84a20b1bc13ec9840466406d2dd91e251053f3e5632b3d00008865dd54d49663f2270886e848a9e7ad8cd5036220101f05607ff9c8984f46ad97f8c9a94982210491a36e3d22085d84421884fdcc0023102171fef54b81e30c83a598a5e44f634c2410f02d088697509827565b46938fece21125101b43bbf9815e00001cb9b2a9f6b8a77c2708373e67d62e719c510362201080d89a58a2a41050918caf68a4e93c642104a319f5f12208883df2b8672930002310fa5d70f929ff298efb160413698dc1072410ae9a3d8ce70ce13bac297bdb91cd6c6825105c0dc2eeaefa0000396882a1fe2cf80b270865ab1cad216bfe87
DVLR GSUP rx 511: 0a010809710000000156f0036220104ac8d1cd1a51937597ca1016fe69a0fa2104dacc4b2622087a75f0ac9b84440023103747da4e31545baa2db59e500bdae04724108544d35b945ccba01a7f1293575291c325102d837d2b0d6f00004b282d5acf23428d270837527064741f8ddb03622010b2661531b97b12c5a2edc21a0ed16fc521042fb4cfad2208da149b11d473f40023103fe013b1a428ea737c37f8f0288c8edf2410f275438c02b97e4d6f639dddda3d10b9251078cdd96c60840000322f421b3bb778b12708ed3ebf9cb6ea48ed0362201054d8f19778056666b41c8c25e52eb60c21040ff61e0f220826ec67fad307300023102868b0922c652616f1c975e3eaf7943a24106a84a20b1bc13ec9840466406d2dd91e251053f3e5632b3d00008865dd54d49663f2270886e848a9e7ad8cd5036220101f05607ff9c8984f46ad97f8c9a94982210491a36e3d22085d84421884fdcc0023102171fef54b81e30c83a598a5e44f634c2410f02d088697509827565b46938fece21125101b43bbf9815e00001cb9b2a9f6b8a77c2708373e67d62e719c510362201080d89a58a2a41050918caf68a4e93c642104a319f5f12208883df2b8672930002310fa5d70f929ff298efb160413698dc1072410ae9a3d8ce70ce13bac297bdb91cd6c6825105c0dc2eeaefa0000396882a1fe2cf80b270865ab1cad216bfe87
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000010650:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: Received Event VLR_AUTH_E_HLR_SAI_ACK
DVLR SUBSCR(IMSI-901700000010650) Received 5 auth tuples
DVLR VLR_Authenticate(IMSI-901700000010650:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000010650:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=0 -- will use UMTS AKA (is_r99=yes, at->vec.auth_types=0x3)
- sending UMTS Auth Request for IMSI-901700000010650: tuple use_count=1 key_seq=0 auth_types=0x3 and...
2018-03-10 01:05:44 +00:00
- ...rand=4ac8d1cd1a51937597ca1016fe69a0fa
- ...autn=2d837d2b0d6f00004b282d5acf23428d
- ...expecting res=37527064741f8ddb
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650 - vlr_gsupc_read_cb: now used by 1 (conn)
2018-03-10 01:05:44 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: vlr_gsupc_read_cb() returns 0
auth_request_sent == 1
lu_result_sent == 0
- MS sends *GSM AKA* Authen Response, VLR accepts and sends Ciphering Mode Command to MS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000010650: MSC conn use + dtap == 1 (0x2: dtap)
2018-03-10 01:05:44 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000010650: MM GSM AUTHENTICATION RESPONSE (sres = dacc4b26)
DVLR VLR_Authenticate(IMSI-901700000010650:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000010650) AUTH on GERAN received SRES/RES: dacc4b26 (4 bytes)
DVLR SUBSCR(IMSI-901700000010650) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000010650:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000010650:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000010650:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000010650:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Removing from parent vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Received Event VLR_ULA_E_AUTH_RES
DVLR vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: vlr_loc_upd_post_auth()
DVLR vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Set Ciphering Mode
DMM -> CIPHER MODE COMMAND IMSI-901700000010650
- sending Ciphering Mode Command for IMSI-901700000010650: include_imeisv=0
2018-09-16 22:54:52 +00:00
- ...perm algo: A5/1
2018-03-09 23:26:36 +00:00
- ...key: 7a75f0ac9b844400
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: state_chg to VLR_ULA_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000010650:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000010650: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000010650:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000010650:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2018-03-10 01:05:44 +00:00
lu_result_sent == 0
- MS sends Ciphering Mode Complete, VLR accepts and sends GSUP LU Req to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000010650: CIPHERING MODE COMPLETE
DVLR vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: Received Event VLR_ULA_E_CIPH_RES
DVLR vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_post_ciph()
DVLR vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_node_4()
DVLR vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: state_chg to VLR_ULA_S_WAIT_HLR_UPD
DVLR upd_hlr_vlr_fsm(IMSI-901700000010650:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Allocated
DVLR upd_hlr_vlr_fsm(IMSI-901700000010650:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000010650:GERAN-A-0:LU)
DVLR upd_hlr_vlr_fsm(IMSI-901700000010650:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Received Event UPD_HLR_VLR_E_START
2018-09-28 00:41:39 +00:00
DVLR GSUP tx: 04010809710000000156f0280102
GSUP --> HLR: OSMO_GSUP_MSGT_UPDATE_LOCATION_REQUEST: 04010809710000000156f0280102
2019-01-03 01:32:14 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000010650:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: state_chg to UPD_HLR_VLR_S_WAIT_FOR_DATA
2018-03-10 01:05:44 +00:00
lu_result_sent == 0
- HLR sends _INSERT_DATA_REQUEST, VLR responds with _INSERT_DATA_RESULT
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: 10010809710000000156f00804032443f2
DVLR GSUP rx 17: 10010809710000000156f00804032443f2
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2018-03-10 01:05:44 +00:00
DVLR IMSI:901700000010650 has MSISDN:42342
2019-02-19 01:36:35 +00:00
DVLR SUBSCR(IMSI-901700000010650:MSISDN-42342) VLR: update for IMSI=901700000010650 (MSISDN=42342)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Updated ID
2018-03-10 01:05:44 +00:00
DVLR GSUP tx: 12010809710000000156f0
GSUP --> HLR: OSMO_GSUP_MSGT_INSERT_DATA_RESULT: 12010809710000000156f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - vlr_gsupc_read_cb: now used by 1 (conn)
2018-03-10 01:05:44 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: vlr_gsupc_read_cb() returns 0
lu_result_sent == 0
- HLR also sends GSUP _UPDATE_LOCATION_RESULT
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: 06010809710000000156f0
DVLR GSUP rx 11: 06010809710000000156f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_HLR_LU_RES
DVLR upd_hlr_vlr_fsm(IMSI-901700000010650:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: Received Event UPD_HLR_VLR_E_UPD_LOC_ACK
DVLR upd_hlr_vlr_fsm(IMSI-901700000010650:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: state_chg to UPD_HLR_VLR_S_DONE
DVLR upd_hlr_vlr_fsm(IMSI-901700000010650:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR upd_hlr_vlr_fsm(IMSI-901700000010650:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_UPD_HLR_COMPL
DVLR vlr_lu_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: state_chg to VLR_ULA_S_WAIT_LU_COMPL
DVLR lu_compl_vlr_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Allocated
DVLR lu_compl_vlr_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU)
DVLR lu_compl_vlr_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Received Event LU_COMPL_VLR_E_START
DVLR lu_compl_vlr_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: state_chg to LU_COMPL_VLR_S_WAIT_SUB_PRES
DVLR lu_compl_vlr_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: Received Event LU_COMPL_VLR_E_SUB_PRES_COMPL
- sending LU Accept for IMSI-901700000010650:MSISDN-42342
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + attached: now used by 3 (conn,vlr_gsupc_read_cb,attached)
2019-01-03 01:32:14 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: state_chg to LU_COMPL_VLR_S_DONE
DVLR vlr_lu_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_LU_COMPL_SUCCESS
2019-03-24 20:07:33 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: upd_hlr_vlr_fsm(IMSI-901700000010650:GERAN-A-0:LU))
2019-01-03 01:32:14 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU)
2019-03-24 20:07:33 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Deferring: will deallocate with upd_hlr_vlr_fsm(IMSI-901700000010650:GERAN-A-0:LU)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: state_chg to VLR_ULA_S_DONE
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + vlr_subscr_cancel_attach_fsm: now used by 4 (conn,vlr_gsupc_read_cb,attached,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - vlr_subscr_cancel_attach_fsm: now used by 3 (conn,vlr_gsupc_read_cb,attached)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2019-03-24 20:07:33 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000010650:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Deallocated, including all deferred deallocations
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - vlr_gsupc_read_cb: now used by 2 (conn,attached)
2018-04-01 18:55:54 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: vlr_gsupc_read_cb() returns 0
bssap_clear_sent == 1
- LU was successful, and the conn has already been closed
lu_result_sent == 1
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU))
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_DONE}: Removing from parent RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_DONE}: fsm_lu_cleanup called with cause OSMO_FSM_TERM_PARENT
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000010650:MSISDN-42342: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
2018-03-10 01:05:44 +00:00
---
- after a while, a new conn sends a CM Service Request. VLR responds with *UMTS AKA* Auth Req, 2nd auth vector
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_CM_SERV_REQ
2018-03-10 01:05:44 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2018-03-10 01:05:44 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_CM_SERV_REQ (0x5:0x24)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000010650:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Updated ID
DMM RAN_conn(IMSI-901700000010650:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Rx CM SERVICE REQUEST cm_service_type=0x08
DVLR Process_Access_Request_VLR(IMSI-901700000010650:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: Allocated
DVLR Process_Access_Request_VLR(IMSI-901700000010650:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: is child of RAN_conn(IMSI-901700000010650:GERAN-A-0:CM_SERVICE_REQ)
DVLR Process_Access_Request_VLR(IMSI-901700000010650:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: rev=R99 net=GERAN Auth+Ciph
DVLR Process_Access_Request_VLR(IMSI-901700000010650:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: Received Event PR_ARQ_E_START
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + proc_arq_vlr_fn_init: now used by 2 (attached,proc_arq_vlr_fn_init)
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + conn: now used by 3 (attached,proc_arq_vlr_fn_init,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Updated ID
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: proc_arq_vlr_fn_post_imsi()
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: state_chg to PR_ARQ_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: is child of Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ)
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=1 -- will use UMTS AKA (is_r99=yes, at->vec.auth_types=0x3)
- sending UMTS Auth Request for IMSI-901700000010650:MSISDN-42342: tuple use_count=1 key_seq=1 auth_types=0x3 and...
2018-03-10 01:05:44 +00:00
- ...rand=b2661531b97b12c5a2edc21a0ed16fc5
- ...autn=78cdd96c60840000322f421b3bb778b1
- ...expecting res=ed3ebf9cb6ea48ed
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - proc_arq_vlr_fn_init: now used by 2 (attached,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2018-03-10 01:05:44 +00:00
cm_service_result_sent == 0
auth_request_sent == 1
- needs auth, not yet accepted
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
ran_conn_is_accepted() == false
2018-03-10 01:05:44 +00:00
requests shall be thwarted
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000010650:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2018-03-10 01:05:44 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000010650:MSISDN-42342: Message not permitted for initial conn: unknown 0x33
2018-03-10 01:05:44 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000010650:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-03-10 01:05:44 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000010650:MSISDN-42342: Message not permitted for initial conn: SMS:0x01
2018-03-10 01:05:44 +00:00
- MS sends *GSM AKA* Authen Response, VLR accepts and requests Ciphering
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use + dtap == 1 (0x2: dtap)
2018-03-10 01:05:44 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000010650:MSISDN-42342: MM GSM AUTHENTICATION RESPONSE (sres = 2fb4cfad)
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000010650:MSISDN-42342) AUTH on GERAN received SRES/RES: 2fb4cfad (4 bytes)
DVLR SUBSCR(IMSI-901700000010650:MSISDN-42342) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_AUTHENTICATED}: Removing from parent Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ)
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: Received Event PR_ARQ_E_AUTH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: _proc_arq_vlr_node2()
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: Set Ciphering Mode
DMM -> CIPHER MODE COMMAND IMSI-901700000010650:MSISDN-42342
- sending Ciphering Mode Command for IMSI-901700000010650:MSISDN-42342: include_imeisv=0
2018-09-16 22:54:52 +00:00
- ...perm algo: A5/1
2018-03-09 23:26:36 +00:00
- ...key: da149b11d473f400
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: state_chg to PR_ARQ_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2018-03-10 01:05:44 +00:00
cm_service_result_sent == 0
cipher_mode_cmd_sent == 1
- MS sends Ciphering Mode Complete, VLR accepts; above Ciphering is an implicit CM Service Accept
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000010650:MSISDN-42342: CIPHERING MODE COMPLETE
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: Received Event PR_ARQ_E_CIPH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_ciph()
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_vlr()
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_pres()
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_trace()
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_imei()
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: proc_arq_fsm_done(PASSED)
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: state_chg to PR_ARQ_S_DONE
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Process Access Request result: PASSED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use + cm_service == 1 (0x8: cm_service)
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_ACCEPTED}: ran_conn_fsm_has_active_transactions: still awaiting first request after a CM Service Request
2018-03-10 01:05:44 +00:00
cm_service_result_sent == 0
2018-06-15 16:57:30 +00:00
- Concluding CM Service Request
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use - cm_service == 0 (0x0: )
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,conn,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,conn)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2018-04-01 18:55:54 +00:00
bssap_clear_sent == 1
- all requests serviced, conn has been released
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ))
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Removing from parent RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000010650:MSISDN-42342: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
2018-03-10 01:05:44 +00:00
---
- an SMS is sent, MS is paged
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + test_gsm_ciph_in_umts_env: now used by 2 (attached,test_gsm_ciph_in_umts_env)
2018-03-10 01:05:44 +00:00
llist_count(&vsub->cs.requests) == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + SMS-receiver: now used by 3 (attached,test_gsm_ciph_in_umts_env,SMS-receiver)
2019-01-16 11:47:39 +00:00
DLSMS Going to send a MT SMS
2019-01-03 01:32:14 +00:00
DCC (ti 00 sub IMSI-901700000010650:MSISDN-42342 callref 40000003) New transaction
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + SMS: now used by 4 (attached,test_gsm_ciph_in_umts_env,SMS-receiver,SMS)
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) instance created for network
DLSMS SMR(0) instance created for network.
DLSMS SMR(0) message SM-RL-DATA_REQ received in state IDLE
DLSMS SMR(0) TX SMS RP-DATA
DLSMS SMR(0) new RP state IDLE -> WAIT_FOR_RP_ACK
DLSMS SMC(0) message MNSMS-EST-REQ received in state IDLE
DLSMS SMC(0) new CP state IDLE -> MM_CONN_PENDING
DLSMS Initiating Paging procedure for IMSI-901700000010650:MSISDN-42342 due to MMSMS_EST_REQ
2019-01-03 01:32:14 +00:00
DMM Subscriber IMSI-901700000010650:MSISDN-42342 not paged yet, start paging.
2018-12-25 23:40:18 +00:00
GERAN-A sends out paging request to IMSI 901700000010650, TMSI 0xffffffff, LAC 23
2018-03-10 01:05:44 +00:00
strcmp(paging_expecting_imsi, imsi) == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + Paging: now used by 5 (attached,test_gsm_ciph_in_umts_env,SMS-receiver,SMS,Paging)
2018-03-10 01:05:44 +00:00
llist_count(&vsub->cs.requests) == 1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - test_gsm_ciph_in_umts_env: now used by 4 (attached,SMS-receiver,SMS,Paging)
2018-03-10 01:05:44 +00:00
paging_sent == 1
paging_stopped == 0
- the subscriber and its pending request should remain
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + test_gsm_ciph_in_umts_env: now used by 5 (attached,SMS-receiver,SMS,Paging,test_gsm_ciph_in_umts_env)
2018-03-10 01:05:44 +00:00
llist_count(&vsub->cs.requests) == 1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - test_gsm_ciph_in_umts_env: now used by 4 (attached,SMS-receiver,SMS,Paging)
2018-03-10 01:05:44 +00:00
- MS replies with Paging Response, and VLR sends *UMTS AKA* Auth Request with third key
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_PAG_RESP
2018-03-10 01:05:44 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2018-03-10 01:05:44 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_PAG_RESP (0x6:0x27)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000010650:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: Updated ID
DRR RAN_conn(IMSI-901700000010650:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: PAGING RESPONSE
DVLR Process_Access_Request_VLR(IMSI-901700000010650:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: Allocated
DVLR Process_Access_Request_VLR(IMSI-901700000010650:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: is child of RAN_conn(IMSI-901700000010650:GERAN-A-0:PAGING_RESP)
DVLR Process_Access_Request_VLR(IMSI-901700000010650:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: rev=R99 net=GERAN Auth+Ciph
DVLR Process_Access_Request_VLR(IMSI-901700000010650:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: Received Event PR_ARQ_E_START
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + proc_arq_vlr_fn_init: now used by 5 (attached,SMS-receiver,SMS,Paging,proc_arq_vlr_fn_init)
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + conn: now used by 6 (attached,SMS-receiver,SMS,Paging,proc_arq_vlr_fn_init,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: Updated ID
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: proc_arq_vlr_fn_post_imsi()
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: state_chg to PR_ARQ_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: is child of Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP)
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=2 -- will use UMTS AKA (is_r99=yes, at->vec.auth_types=0x3)
- sending UMTS Auth Request for IMSI-901700000010650:MSISDN-42342: tuple use_count=1 key_seq=2 auth_types=0x3 and...
2018-03-10 01:05:44 +00:00
- ...rand=54d8f19778056666b41c8c25e52eb60c
- ...autn=53f3e5632b3d00008865dd54d49663f2
- ...expecting res=86e848a9e7ad8cd5
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - proc_arq_vlr_fn_init: now used by 5 (attached,SMS-receiver,SMS,Paging,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2018-03-10 01:05:44 +00:00
auth_request_sent == 1
- needs auth, not yet accepted
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
ran_conn_is_accepted() == false
2018-03-10 01:05:44 +00:00
requests shall be thwarted
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000010650:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_CC_SETUP
2018-03-10 01:05:44 +00:00
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000010650:MSISDN-42342: Message not permitted for initial conn: unknown 0x33
2018-03-10 01:05:44 +00:00
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000010650:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
2018-03-10 01:05:44 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000010650:MSISDN-42342: Message not permitted for initial conn: SMS:0x01
2018-03-10 01:05:44 +00:00
- MS sends *GSM AKA* Authen Response, VLR accepts and requests Ciphering
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use + dtap == 1 (0x2: dtap)
2018-03-10 01:05:44 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000010650:MSISDN-42342: MM GSM AUTHENTICATION RESPONSE (sres = 0ff61e0f)
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000010650:MSISDN-42342) AUTH on GERAN received SRES/RES: 0ff61e0f (4 bytes)
DVLR SUBSCR(IMSI-901700000010650:MSISDN-42342) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_AUTHENTICATED}: Removing from parent Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP)
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: Received Event PR_ARQ_E_AUTH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: _proc_arq_vlr_node2()
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: Set Ciphering Mode
DMM -> CIPHER MODE COMMAND IMSI-901700000010650:MSISDN-42342
- sending Ciphering Mode Command for IMSI-901700000010650:MSISDN-42342: include_imeisv=0
2018-09-16 22:54:52 +00:00
- ...perm algo: A5/1
2018-03-09 23:26:36 +00:00
- ...key: 26ec67fad3073000
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: state_chg to PR_ARQ_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2018-03-10 01:05:44 +00:00
cipher_mode_cmd_sent == 1
- MS sends Ciphering Mode Complete, VLR accepts and sends pending SMS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000010650:MSISDN-42342: CIPHERING MODE COMPLETE
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: Received Event PR_ARQ_E_CIPH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_ciph()
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_vlr()
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_pres()
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_trace()
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_imei()
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: proc_arq_fsm_done(PASSED)
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: state_chg to PR_ARQ_S_DONE
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Process Access Request result: PASSED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DPAG Paging success for IMSI-901700000010650:MSISDN-42342 (event=0)
2018-03-10 01:05:44 +00:00
DPAG Calling paging cbfn.
2019-01-16 11:47:39 +00:00
DLSMS paging_cb_mmsms_est_req(hooknum=1, event=0)
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use + trans_sms == 1 (0x20: trans_sms)
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) message MMSMS-EST-CNF received in state MM_CONN_PENDING
DLSMS SMC(0) send CP data
DLSMS SMC(0) new CP state MM_CONN_PENDING -> WAIT_CP_ACK
DLSMS sending CP message (trans=0)
DLSMS GSM4.11 TX 09 01 58 01 00 07 91 44 77 58 10 06 50 00 4c 00 05 80 24 43 f2 00 00 07 10 10 00 00 00 00 44 50 79 da 1e 1e e7 41 69 37 48 5e 9e a7 c9 65 37 3d 1d 66 83 c2 70 38 3b 3d 0e d3 d3 6f f7 1c 94 9e 83 c2 20 72 79 9e 96 87 c5 ec 32 a8 1d 96 af cb f4 b4 fb 0c 7a c3 e9 e9 b7 db 05
2019-01-03 01:32:14 +00:00
DMSC msc_tx 91 bytes to IMSI-901700000010650:MSISDN-42342 via GERAN-A
2018-12-25 23:40:18 +00:00
- DTAP --GERAN-A--> MS: SMS:0x01: 09015801000791447758100650004c0005802443f2000007101000000000445079da1e1ee7416937485e9ea7c965373d1d6683c270383b3d0ed3d36ff71c949e83c22072799e9687c5ec32a81d96afcbf4b4fb0c7ac3e9e9b7db05
2018-03-10 01:05:44 +00:00
- DTAP matches expected message
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - Paging: now used by 4 (attached,SMS-receiver,SMS,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_ACCEPTED}: ran_conn_fsm_has_active_transactions: connection still has active transaction: SMS
2018-03-10 01:05:44 +00:00
dtap_tx_confirmed == 1
paging_stopped == 1
- SMS was delivered, no requests pending for subscr
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + test_gsm_ciph_in_umts_env: now used by 5 (attached,SMS-receiver,SMS,conn,test_gsm_ciph_in_umts_env)
2018-03-10 01:05:44 +00:00
llist_count(&vsub->cs.requests) == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - test_gsm_ciph_in_umts_env: now used by 4 (attached,SMS-receiver,SMS,conn)
2018-03-10 01:05:44 +00:00
- conn is still open to wait for SMS ack dance
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
llist_count(&net->ran_conns) == 1
2018-03-10 01:05:44 +00:00
- MS replies with CP-ACK for received SMS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: SMS:0x04
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use + dtap == 2 (0x22: dtap,trans_sms)
2018-03-10 01:05:44 +00:00
DRLL Dispatching 04.08 message SMS:0x04 (0x9:0x4)
2019-01-16 11:47:39 +00:00
DLSMS receiving data (trans_id=0, msg_type=SMS:0x04)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_COMMUNICATING
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_COMMUNICATING
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) message MMSMS-DATA-IND (CP ACK) received in state WAIT_CP_ACK
DLSMS SMC(0) received CP-ACK
DLSMS SMC(0) new CP state WAIT_CP_ACK -> MM_ESTABLISHED
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use - dtap == 1 (0x20: trans_sms)
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
llist_count(&net->ran_conns) == 1
2018-03-10 01:05:44 +00:00
- MS also sends RP-ACK, MSC in turn sends CP-ACK for that
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: SMS:0x01
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use + dtap == 2 (0x22: dtap,trans_sms)
2018-03-10 01:05:44 +00:00
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-16 11:47:39 +00:00
DLSMS receiving data (trans_id=0, msg_type=SMS:0x01)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_COMMUNICATING}: Received Event RAN_CONN_E_COMMUNICATING
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) message MMSMS-DATA-IND (CP DATA) received in state MM_ESTABLISHED
DLSMS SMC(0) received CP-DATA
DLSMS sending CP message (trans=0)
DLSMS GSM4.11 TX 09 04
2019-01-03 01:32:14 +00:00
DMSC msc_tx 2 bytes to IMSI-901700000010650:MSISDN-42342 via GERAN-A
2018-12-25 23:40:18 +00:00
- DTAP --GERAN-A--> MS: SMS:0x04: 0904
2018-03-10 01:05:44 +00:00
- DTAP matches expected message
2019-01-16 11:47:39 +00:00
DLSMS MNSMS-DATA/EST-IND
DLSMS SMR(0) message MNSMS-DATA-IND received in state WAIT_FOR_RP_ACK
DLSMS SMR(0) RX SMS RP-ACK
DLSMS SMR(0) new RP state WAIT_FOR_RP_ACK -> IDLE
DLSMS RX SMS RP-ACK (MO)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - SMS-receiver: now used by 3 (attached,SMS,conn)
2019-01-16 11:47:39 +00:00
DLSMS SMR(0) TX: MNSMS-REL-REQ
DLSMS SMC(0) message MNSMS-REL-REQ received in state MM_ESTABLISHED
DLSMS SMC(0) new CP state MM_ESTABLISHED -> IDLE
DLSMS Got MMSMS_REL_REQ, destroying transaction.
DLSMS SMR(0) clearing SMR instance
DLSMS SMC(0) clearing instance
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - SMS: now used by 2 (attached,conn)
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use - trans_sms == 1 (0x2: dtap)
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_COMMUNICATING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_COMMUNICATING}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,conn,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,conn)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2018-04-01 18:55:54 +00:00
dtap_tx_confirmed == 1
bssap_clear_sent == 1
- SMS is done, conn is gone
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000010650:MSISDN-42342: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP))
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Removing from parent RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000010650:MSISDN-42342: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000010650:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
2018-03-10 01:05:44 +00:00
---
- subscriber detaches
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_IMSI_DETACH_IND
2018-03-10 01:05:44 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2018-03-10 01:05:44 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_IMSI_DETACH_IND (0x5:0x1)
DMM IMSI DETACH INDICATION: MI(IMSI)=901700000010650
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + gsm48_rx_mm_imsi_detach_ind: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
2019-01-03 01:32:14 +00:00
DMM IMSI DETACH for IMSI-901700000010650:MSISDN-42342
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,gsm48_rx_mm_imsi_detach_ind,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - attached: now used by 1 (gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000010650:MSISDN-42342 - gsm48_rx_mm_imsi_detach_ind: now used by 0 (-)
2019-01-03 01:32:14 +00:00
DREF freeing VLR subscr IMSI-901700000010650:MSISDN-42342
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
DMM RAN_conn{RAN_CONN_S_NEW}: Received Event RAN_CONN_E_CN_CLOSE
DMM RAN_conn{RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_RELEASING
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + release == 2 (0x101: compl_l3,release)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use - compl_l3 == 1 (0x100: release)
2018-04-01 18:55:54 +00:00
bssap_clear_sent == 1
- BSS sends BSSMAP Clear Complete
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use - release == 0 (0x0: )
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
DMM RAN_conn{RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn{RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn{RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DRLL Freeing RAN connection with NULL subscriber
DMM RAN_conn{RAN_CONN_S_RELEASED}: Deallocated
llist_count(&net->ran_conns) == 0
2018-03-10 01:05:44 +00:00
===== test_gsm_ciph_in_umts_env: SUCCESS
full talloc report on 'msgb' (total 0 bytes in 1 blocks)
2018-12-06 11:06:59 +00:00
talloc_total_blocks(tall_bsc_ctx) == 13
2018-03-10 01:05:44 +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
===== test_a5_3_supported
2018-03-02 00:50:42 +00:00
- Location Update request causes a GSUP Send Auth Info request to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_LOC_UPD_REQUEST
2018-03-02 00:50:42 +00:00
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
2018-04-09 18:44:56 +00:00
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
2018-03-02 00:50:42 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_LOC_UPD_REQUEST (0x5:0x8)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: LOCATION UPDATING REQUEST: MI=IMSI-901700000004620 LU-type=IMSI-ATTACH
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: LU/new-LAC: 1/23
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Allocated
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: is child of RAN_conn(IMSI-901700000004620:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: rev=GSM net=GERAN Auth+Ciph
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Received Event VLR_ULA_E_UPDATE_LA
2019-02-19 01:36:35 +00:00
DREF VLR subscr unknown + _lu_fsm_associate_vsub: now used by 1 (_lu_fsm_associate_vsub)
2018-03-02 00:50:42 +00:00
DVLR set IMSI on subscriber; IMSI=901700000004620 id=901700000004620
DVLR New subscr, IMSI: 901700000004620
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + conn: now used by 2 (_lu_fsm_associate_vsub,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - _lu_fsm_associate_vsub: now used by 1 (conn)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: vlr_loc_upd_node1()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: state_chg to VLR_ULA_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: is child of vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
2018-03-02 00:50:42 +00:00
DVLR GSUP tx: 08010809710000004026f0
GSUP --> HLR: OSMO_GSUP_MSGT_SEND_AUTH_INFO_REQUEST: 08010809710000004026f0
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_NEEDS_AUTH_WAIT_AI
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000004620: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
2018-03-02 00:50:42 +00:00
lu_result_sent == 0
- from HLR, rx _SEND_AUTH_INFO_RESULT; VLR sends Auth Req to MS
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: 0a010809710000004026f003222010585df1ae287f6e273dce07090d61320b21042d8b2c3e220861855fb81fc2a8000322201012aca96fb4ffdea5c985cbafa9b6e18b210420bde240220807fa7502e07e1c0003222010e7c03ba7cf0e2fde82b2dc4d63077d422104a29514ae2208e2b234f80788640003222010fa8f20b781b5881329d4fea26b1a3c5121045afc8d7222082392f14f709ae000032220100fd4cc8dbe8715d1f439e304edfd68dc2104bc8d1c5b2208da7cdd6bfe2d7000
DVLR GSUP rx 191: 0a010809710000004026f003222010585df1ae287f6e273dce07090d61320b21042d8b2c3e220861855fb81fc2a8000322201012aca96fb4ffdea5c985cbafa9b6e18b210420bde240220807fa7502e07e1c0003222010e7c03ba7cf0e2fde82b2dc4d63077d422104a29514ae2208e2b234f80788640003222010fa8f20b781b5881329d4fea26b1a3c5121045afc8d7222082392f14f709ae000032220100fd4cc8dbe8715d1f439e304edfd68dc2104bc8d1c5b2208da7cdd6bfe2d7000
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: Received Event VLR_AUTH_E_HLR_SAI_ACK
DVLR SUBSCR(IMSI-901700000004620) Received 5 auth tuples
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=0 -- will use GSM AKA (is_r99=no, at->vec.auth_types=0x1)
- sending GSM Auth Request for IMSI-901700000004620: tuple use_count=1 key_seq=0 auth_types=0x1 and...
2018-03-02 00:50:42 +00:00
- ...rand=585df1ae287f6e273dce07090d61320b
- ...expecting sres=2d8b2c3e
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - vlr_gsupc_read_cb: now used by 1 (conn)
2018-03-02 00:50:42 +00:00
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: vlr_gsupc_read_cb() returns 0
lu_result_sent == 0
auth_request_sent == 1
---
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
- 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
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620: MSC conn use + dtap == 1 (0x2: dtap)
2018-03-02 00:50:42 +00:00
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000004620: MM GSM AUTHENTICATION RESPONSE (sres = 2d8b2c3e)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000004620) AUTH on GERAN received SRES/RES: 2d8b2c3e (4 bytes)
DVLR SUBSCR(IMSI-901700000004620) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Received Event VLR_ULA_E_AUTH_RES
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: vlr_loc_upd_post_auth()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Set Ciphering Mode
DMM IMSI-901700000004620: to determine whether A5/3 is supported, first ask for a Classmark Update to obtain Classmark 2
DBSSAP RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Tx BSSMAP CLASSMARK REQUEST to BSC
2019-02-18 11:55:31 +00:00
DBSSAP RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: N-DATA.req(00 01 58 )
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
BSC <--BSSAP-BSS-MANAGEMENT-- MSC: CLASSMARK REQ [L3]> 00 01 58
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_WAIT_CLASSMARK_UPDATE
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: state_chg to VLR_ULA_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
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
lu_result_sent == 0
- BSC sends back a BSSMAP Classmark Update, that triggers the Ciphering Mode Command in A5/3
DMSC Looking for A subscriber: conn_id 0
2019-01-03 01:32:14 +00:00
DBSSAP RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Found A subscriber for conn_id 0
DBSSAP RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Rx BSSMAP DT1 CLASSMARK UPDATE
DBSSAP RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Rx BSSMAP CLASSMARK UPDATE
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Received Event RAN_CONN_E_CLASSMARK_UPDATE
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: state_chg to RAN_CONN_S_AUTH_CIPH
DMM -> CIPHER MODE COMMAND IMSI-901700000004620
- sending Ciphering Mode Command for IMSI-901700000004620: include_imeisv=0
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
- ...perm algo: A5/3
- ...key: 61855fb81fc2a800
lu_result_sent == 0
- MS sends Ciphering Mode Complete, VLR accepts and sends GSUP LU Req to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000004620: CIPHERING MODE COMPLETE
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: Received Event VLR_ULA_E_CIPH_RES
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_post_ciph()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_node_4()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: state_chg to VLR_ULA_S_WAIT_HLR_UPD
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Allocated
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Received Event UPD_HLR_VLR_E_START
2018-09-28 00:41:39 +00:00
DVLR GSUP tx: 04010809710000004026f0280102
GSUP --> HLR: OSMO_GSUP_MSGT_UPDATE_LOCATION_REQUEST: 04010809710000004026f0280102
2019-01-03 01:32:14 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: state_chg to UPD_HLR_VLR_S_WAIT_FOR_DATA
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
lu_result_sent == 0
- HLR sends _INSERT_DATA_REQUEST, VLR responds with _INSERT_DATA_RESULT
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: 10010809710000004026f00804032443f2
DVLR GSUP rx 17: 10010809710000004026f00804032443f2
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
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
DVLR IMSI:901700000004620 has MSISDN:42342
2019-02-19 01:36:35 +00:00
DVLR SUBSCR(IMSI-901700000004620:MSISDN-42342) VLR: update for IMSI=901700000004620 (MSISDN=42342)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Updated ID
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
DVLR GSUP tx: 12010809710000004026f0
GSUP --> HLR: OSMO_GSUP_MSGT_INSERT_DATA_RESULT: 12010809710000004026f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - vlr_gsupc_read_cb: now used by 1 (conn)
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
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: vlr_gsupc_read_cb() returns 0
lu_result_sent == 0
- HLR also sends GSUP _UPDATE_LOCATION_RESULT
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: 06010809710000004026f0
DVLR GSUP rx 11: 06010809710000004026f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_HLR_LU_RES
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: Received Event UPD_HLR_VLR_E_UPD_LOC_ACK
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: state_chg to UPD_HLR_VLR_S_DONE
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_UPD_HLR_COMPL
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: state_chg to VLR_ULA_S_WAIT_LU_COMPL
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Allocated
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU)
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Received Event LU_COMPL_VLR_E_START
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: state_chg to LU_COMPL_VLR_S_WAIT_SUB_PRES
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: Received Event LU_COMPL_VLR_E_SUB_PRES_COMPL
- sending LU Accept for IMSI-901700000004620:MSISDN-42342
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + attached: now used by 3 (conn,vlr_gsupc_read_cb,attached)
2019-01-03 01:32:14 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: state_chg to LU_COMPL_VLR_S_DONE
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_LU_COMPL_SUCCESS
2019-03-24 20:07:33 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU))
2019-01-03 01:32:14 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU)
2019-03-24 20:07:33 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Deferring: will deallocate with upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: state_chg to VLR_ULA_S_DONE
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + vlr_subscr_cancel_attach_fsm: now used by 4 (conn,vlr_gsupc_read_cb,attached,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - vlr_subscr_cancel_attach_fsm: now used by 3 (conn,vlr_gsupc_read_cb,attached)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2019-03-24 20:07:33 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Deallocated, including all deferred deallocations
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - vlr_gsupc_read_cb: now used by 2 (conn,attached)
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
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: vlr_gsupc_read_cb() returns 0
bssap_clear_sent == 1
- LU was successful, and the conn has already been closed
lu_result_sent == 1
2018-04-01 18:55:54 +00:00
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU))
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_DONE}: Removing from parent RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_DONE}: fsm_lu_cleanup called with cause OSMO_FSM_TERM_PARENT
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000004620:MSISDN-42342: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
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
---
- after a while, a new conn sends a CM Service Request. VLR responds with Auth Req, 2nd auth vector
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_CM_SERV_REQ
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
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
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
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
DRLL Dispatching 04.08 message GSM48_MT_MM_CM_SERV_REQ (0x5:0x24)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Updated ID
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Rx CM SERVICE REQUEST cm_service_type=0x08
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: Allocated
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: is child of RAN_conn(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: rev=GSM net=GERAN Auth+Ciph
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: Received Event PR_ARQ_E_START
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + proc_arq_vlr_fn_init: now used by 2 (attached,proc_arq_vlr_fn_init)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + conn: now used by 3 (attached,proc_arq_vlr_fn_init,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Updated ID
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: proc_arq_vlr_fn_post_imsi()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: state_chg to PR_ARQ_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: is child of Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=1 -- will use GSM AKA (is_r99=no, at->vec.auth_types=0x1)
- sending GSM Auth Request for IMSI-901700000004620:MSISDN-42342: tuple use_count=1 key_seq=1 auth_types=0x1 and...
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
- ...rand=12aca96fb4ffdea5c985cbafa9b6e18b
- ...expecting sres=20bde240
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - proc_arq_vlr_fn_init: now used by 2 (attached,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
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
auth_request_sent == 1
cm_service_result_sent == 0
- needs auth, not yet accepted
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
ran_conn_is_accepted() == false
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
requests shall be thwarted
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_CC_SETUP
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
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: unknown 0x33
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
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
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
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: SMS:0x01
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
- MS sends Authen Response, VLR accepts and requests Ciphering. We already know Classmark 3, so no need to request Classmark Update.
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + dtap == 1 (0x2: dtap)
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
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000004620:MSISDN-42342: MM GSM AUTHENTICATION RESPONSE (sres = 20bde240)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000004620:MSISDN-42342) AUTH on GERAN received SRES/RES: 20bde240 (4 bytes)
DVLR SUBSCR(IMSI-901700000004620:MSISDN-42342) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_AUTHENTICATED}: Removing from parent Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: Received Event PR_ARQ_E_AUTH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: _proc_arq_vlr_node2()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: Set Ciphering Mode
DMM -> CIPHER MODE COMMAND IMSI-901700000004620:MSISDN-42342
- sending Ciphering Mode Command for IMSI-901700000004620:MSISDN-42342: include_imeisv=0
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
- ...perm algo: A5/3
- ...key: 07fa7502e07e1c00
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: state_chg to PR_ARQ_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
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
cm_service_result_sent == 0
cipher_mode_cmd_sent == 1
- needs ciph, not yet accepted
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
ran_conn_is_accepted() == false
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
requests shall be thwarted
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_CC_SETUP
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
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: unknown 0x33
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
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
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
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: SMS:0x01
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
- MS sends Ciphering Mode Complete, VLR accepts; above Ciphering is an implicit CM Service Accept
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000004620:MSISDN-42342: CIPHERING MODE COMPLETE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: Received Event PR_ARQ_E_CIPH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_ciph()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_vlr()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_pres()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_trace()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_imei()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: proc_arq_fsm_done(PASSED)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: state_chg to PR_ARQ_S_DONE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Process Access Request result: PASSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + cm_service == 1 (0x8: cm_service)
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_ACCEPTED}: ran_conn_fsm_has_active_transactions: still awaiting first request after a CM Service Request
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
cm_service_result_sent == 0
- Concluding CM Service Request
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - cm_service == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,conn,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,conn)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
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
bssap_clear_sent == 1
- all requests serviced, conn has been released
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ))
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Removing from parent RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000004620:MSISDN-42342: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
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
---
- an SMS is sent, MS is paged
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + test_a5_3_supported: now used by 2 (attached,test_a5_3_supported)
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
llist_count(&vsub->cs.requests) == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + SMS-receiver: now used by 3 (attached,test_a5_3_supported,SMS-receiver)
2019-01-16 11:47:39 +00:00
DLSMS Going to send a MT SMS
2019-01-03 01:32:14 +00:00
DCC (ti 00 sub IMSI-901700000004620:MSISDN-42342 callref 40000004) New transaction
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + SMS: now used by 4 (attached,test_a5_3_supported,SMS-receiver,SMS)
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) instance created for network
DLSMS SMR(0) instance created for network.
DLSMS SMR(0) message SM-RL-DATA_REQ received in state IDLE
DLSMS SMR(0) TX SMS RP-DATA
DLSMS SMR(0) new RP state IDLE -> WAIT_FOR_RP_ACK
DLSMS SMC(0) message MNSMS-EST-REQ received in state IDLE
DLSMS SMC(0) new CP state IDLE -> MM_CONN_PENDING
DLSMS Initiating Paging procedure for IMSI-901700000004620:MSISDN-42342 due to MMSMS_EST_REQ
2019-01-03 01:32:14 +00:00
DMM Subscriber IMSI-901700000004620:MSISDN-42342 not paged yet, start paging.
2018-12-25 23:40:18 +00:00
GERAN-A sends out paging request to IMSI 901700000004620, TMSI 0xffffffff, LAC 23
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
strcmp(paging_expecting_imsi, imsi) == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + Paging: now used by 5 (attached,test_a5_3_supported,SMS-receiver,SMS,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
llist_count(&vsub->cs.requests) == 1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - test_a5_3_supported: now used by 4 (attached,SMS-receiver,SMS,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
paging_sent == 1
paging_stopped == 0
- the subscriber and its pending request should remain
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + test_a5_3_supported: now used by 5 (attached,SMS-receiver,SMS,Paging,test_a5_3_supported)
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
llist_count(&vsub->cs.requests) == 1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - test_a5_3_supported: now used by 4 (attached,SMS-receiver,SMS,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
- MS replies with Paging Response, and VLR sends Auth Request with third key
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_PAG_RESP
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
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
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
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
DRLL Dispatching 04.08 message GSM48_MT_RR_PAG_RESP (0x6:0x27)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: Updated ID
DRR RAN_conn(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: PAGING RESPONSE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: Allocated
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: is child of RAN_conn(IMSI-901700000004620:GERAN-A-0:PAGING_RESP)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: rev=GSM net=GERAN Auth+Ciph
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: Received Event PR_ARQ_E_START
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + proc_arq_vlr_fn_init: now used by 5 (attached,SMS-receiver,SMS,Paging,proc_arq_vlr_fn_init)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + conn: now used by 6 (attached,SMS-receiver,SMS,Paging,proc_arq_vlr_fn_init,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: Updated ID
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: proc_arq_vlr_fn_post_imsi()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: state_chg to PR_ARQ_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: is child of Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=2 -- will use GSM AKA (is_r99=no, at->vec.auth_types=0x1)
- sending GSM Auth Request for IMSI-901700000004620:MSISDN-42342: tuple use_count=1 key_seq=2 auth_types=0x1 and...
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
- ...rand=e7c03ba7cf0e2fde82b2dc4d63077d42
- ...expecting sres=a29514ae
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - proc_arq_vlr_fn_init: now used by 5 (attached,SMS-receiver,SMS,Paging,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
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
auth_request_sent == 1
- needs auth, not yet accepted
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
ran_conn_is_accepted() == false
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
requests shall be thwarted
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_CC_SETUP
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
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: unknown 0x33
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
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
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
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: SMS:0x01
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
- MS sends Authen Response, VLR accepts and requests Ciphering
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + dtap == 1 (0x2: dtap)
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
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000004620:MSISDN-42342: MM GSM AUTHENTICATION RESPONSE (sres = a29514ae)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000004620:MSISDN-42342) AUTH on GERAN received SRES/RES: a29514ae (4 bytes)
DVLR SUBSCR(IMSI-901700000004620:MSISDN-42342) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_AUTHENTICATED}: Removing from parent Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: Received Event PR_ARQ_E_AUTH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: _proc_arq_vlr_node2()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: Set Ciphering Mode
DMM -> CIPHER MODE COMMAND IMSI-901700000004620:MSISDN-42342
- sending Ciphering Mode Command for IMSI-901700000004620:MSISDN-42342: include_imeisv=0
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
- ...perm algo: A5/3
- ...key: e2b234f807886400
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: state_chg to PR_ARQ_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
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
cipher_mode_cmd_sent == 1
- needs ciph, not yet accepted
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
ran_conn_is_accepted() == false
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
requests shall be thwarted
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_CC_SETUP
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
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: unknown 0x33
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
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
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
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: SMS:0x01
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
- MS sends Ciphering Mode Complete, VLR accepts and sends pending SMS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000004620:MSISDN-42342: CIPHERING MODE COMPLETE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: Received Event PR_ARQ_E_CIPH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_ciph()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_vlr()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_pres()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_trace()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_imei()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: proc_arq_fsm_done(PASSED)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: state_chg to PR_ARQ_S_DONE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Process Access Request result: PASSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DPAG Paging success for IMSI-901700000004620:MSISDN-42342 (event=0)
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
DPAG Calling paging cbfn.
2019-01-16 11:47:39 +00:00
DLSMS paging_cb_mmsms_est_req(hooknum=1, event=0)
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + trans_sms == 1 (0x20: trans_sms)
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) message MMSMS-EST-CNF received in state MM_CONN_PENDING
DLSMS SMC(0) send CP data
DLSMS SMC(0) new CP state MM_CONN_PENDING -> WAIT_CP_ACK
DLSMS sending CP message (trans=0)
DLSMS GSM4.11 TX 09 01 58 01 00 07 91 44 77 58 10 06 50 00 4c 00 05 80 24 43 f2 00 00 07 10 10 00 00 00 00 44 50 79 da 1e 1e e7 41 69 37 48 5e 9e a7 c9 65 37 3d 1d 66 83 c2 70 38 3b 3d 0e d3 d3 6f f7 1c 94 9e 83 c2 20 72 79 9e 96 87 c5 ec 32 a8 1d 96 af cb f4 b4 fb 0c 7a c3 e9 e9 b7 db 05
2019-01-03 01:32:14 +00:00
DMSC msc_tx 91 bytes to IMSI-901700000004620:MSISDN-42342 via GERAN-A
2018-12-25 23:40:18 +00:00
- DTAP --GERAN-A--> MS: SMS:0x01: 09015801000791447758100650004c0005802443f2000007101000000000445079da1e1ee7416937485e9ea7c965373d1d6683c270383b3d0ed3d36ff71c949e83c22072799e9687c5ec32a81d96afcbf4b4fb0c7ac3e9e9b7db05
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
- DTAP matches expected message
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - Paging: now used by 4 (attached,SMS-receiver,SMS,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_ACCEPTED}: ran_conn_fsm_has_active_transactions: connection still has active transaction: SMS
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
dtap_tx_confirmed == 1
paging_stopped == 1
- SMS was delivered, no requests pending for subscr
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + test_a5_3_supported: now used by 5 (attached,SMS-receiver,SMS,conn,test_a5_3_supported)
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
llist_count(&vsub->cs.requests) == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - test_a5_3_supported: now used by 4 (attached,SMS-receiver,SMS,conn)
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
- conn is still open to wait for SMS ack dance
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
llist_count(&net->ran_conns) == 1
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
- MS replies with CP-ACK for received SMS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: SMS:0x04
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + dtap == 2 (0x22: dtap,trans_sms)
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
DRLL Dispatching 04.08 message SMS:0x04 (0x9:0x4)
2019-01-16 11:47:39 +00:00
DLSMS receiving data (trans_id=0, msg_type=SMS:0x04)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_COMMUNICATING
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_COMMUNICATING
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) message MMSMS-DATA-IND (CP ACK) received in state WAIT_CP_ACK
DLSMS SMC(0) received CP-ACK
DLSMS SMC(0) new CP state WAIT_CP_ACK -> MM_ESTABLISHED
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - dtap == 1 (0x20: trans_sms)
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
llist_count(&net->ran_conns) == 1
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
- MS also sends RP-ACK, MSC in turn sends CP-ACK for that
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: SMS:0x01
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + dtap == 2 (0x22: dtap,trans_sms)
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
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-16 11:47:39 +00:00
DLSMS receiving data (trans_id=0, msg_type=SMS:0x01)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_COMMUNICATING}: Received Event RAN_CONN_E_COMMUNICATING
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) message MMSMS-DATA-IND (CP DATA) received in state MM_ESTABLISHED
DLSMS SMC(0) received CP-DATA
DLSMS sending CP message (trans=0)
DLSMS GSM4.11 TX 09 04
2019-01-03 01:32:14 +00:00
DMSC msc_tx 2 bytes to IMSI-901700000004620:MSISDN-42342 via GERAN-A
2018-12-25 23:40:18 +00:00
- DTAP --GERAN-A--> MS: SMS:0x04: 0904
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
- DTAP matches expected message
2019-01-16 11:47:39 +00:00
DLSMS MNSMS-DATA/EST-IND
DLSMS SMR(0) message MNSMS-DATA-IND received in state WAIT_FOR_RP_ACK
DLSMS SMR(0) RX SMS RP-ACK
DLSMS SMR(0) new RP state WAIT_FOR_RP_ACK -> IDLE
DLSMS RX SMS RP-ACK (MO)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - SMS-receiver: now used by 3 (attached,SMS,conn)
2019-01-16 11:47:39 +00:00
DLSMS SMR(0) TX: MNSMS-REL-REQ
DLSMS SMC(0) message MNSMS-REL-REQ received in state MM_ESTABLISHED
DLSMS SMC(0) new CP state MM_ESTABLISHED -> IDLE
DLSMS Got MMSMS_REL_REQ, destroying transaction.
DLSMS SMR(0) clearing SMR instance
DLSMS SMC(0) clearing instance
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - SMS: now used by 2 (attached,conn)
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - trans_sms == 1 (0x2: dtap)
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_COMMUNICATING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_COMMUNICATING}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,conn,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,conn)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
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
dtap_tx_confirmed == 1
bssap_clear_sent == 1
- SMS is done, conn is gone
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP))
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Removing from parent RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000004620:MSISDN-42342: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
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
---
- subscriber detaches
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_IMSI_DETACH_IND
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
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
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
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
DRLL Dispatching 04.08 message GSM48_MT_MM_IMSI_DETACH_IND (0x5:0x1)
DMM IMSI DETACH INDICATION: MI(IMSI)=901700000004620
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + gsm48_rx_mm_imsi_detach_ind: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
2019-01-03 01:32:14 +00:00
DMM IMSI DETACH for IMSI-901700000004620:MSISDN-42342
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,gsm48_rx_mm_imsi_detach_ind,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - attached: now used by 1 (gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - gsm48_rx_mm_imsi_detach_ind: now used by 0 (-)
2019-01-03 01:32:14 +00:00
DREF freeing VLR subscr IMSI-901700000004620:MSISDN-42342
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
DMM RAN_conn{RAN_CONN_S_NEW}: Received Event RAN_CONN_E_CN_CLOSE
DMM RAN_conn{RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_RELEASING
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
DREF unknown: MSC conn use + release == 2 (0x101: compl_l3,release)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
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
DREF unknown: MSC conn use - compl_l3 == 1 (0x100: release)
bssap_clear_sent == 1
- BSS sends BSSMAP Clear Complete
DREF unknown: MSC conn use - release == 0 (0x0: )
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
DMM RAN_conn{RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn{RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn{RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DRLL Freeing RAN connection with NULL subscriber
DMM RAN_conn{RAN_CONN_S_RELEASED}: Deallocated
llist_count(&net->ran_conns) == 0
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_a5_3_supported: SUCCESS
full talloc report on 'msgb' (total 0 bytes in 1 blocks)
2018-12-06 11:06:59 +00:00
talloc_total_blocks(tall_bsc_ctx) == 13
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_cm_service_needs_classmark_update
- Location Update request causes a GSUP Send Auth Info request to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_LOC_UPD_REQUEST
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
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
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
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
DRLL Dispatching 04.08 message GSM48_MT_MM_LOC_UPD_REQUEST (0x5:0x8)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: LOCATION UPDATING REQUEST: MI=IMSI-901700000004620 LU-type=IMSI-ATTACH
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: LU/new-LAC: 1/23
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Allocated
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: is child of RAN_conn(IMSI-901700000004620:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: rev=GSM net=GERAN Auth+Ciph
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: Received Event VLR_ULA_E_UPDATE_LA
2019-02-19 01:36:35 +00:00
DREF VLR subscr unknown + _lu_fsm_associate_vsub: now used by 1 (_lu_fsm_associate_vsub)
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
DVLR set IMSI on subscriber; IMSI=901700000004620 id=901700000004620
DVLR New subscr, IMSI: 901700000004620
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + conn: now used by 2 (_lu_fsm_associate_vsub,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Updated ID
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - _lu_fsm_associate_vsub: now used by 1 (conn)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: vlr_loc_upd_node1()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_IDLE}: state_chg to VLR_ULA_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: is child of vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
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
DVLR GSUP tx: 08010809710000004026f0
GSUP --> HLR: OSMO_GSUP_MSGT_SEND_AUTH_INFO_REQUEST: 08010809710000004026f0
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_NEEDS_AUTH_WAIT_AI
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000004620: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
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
lu_result_sent == 0
- from HLR, rx _SEND_AUTH_INFO_RESULT; VLR sends Auth Req to MS
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: 0a010809710000004026f003222010585df1ae287f6e273dce07090d61320b21042d8b2c3e220861855fb81fc2a8000322201012aca96fb4ffdea5c985cbafa9b6e18b210420bde240220807fa7502e07e1c0003222010e7c03ba7cf0e2fde82b2dc4d63077d422104a29514ae2208e2b234f80788640003222010fa8f20b781b5881329d4fea26b1a3c5121045afc8d7222082392f14f709ae000032220100fd4cc8dbe8715d1f439e304edfd68dc2104bc8d1c5b2208da7cdd6bfe2d7000
DVLR GSUP rx 191: 0a010809710000004026f003222010585df1ae287f6e273dce07090d61320b21042d8b2c3e220861855fb81fc2a8000322201012aca96fb4ffdea5c985cbafa9b6e18b210420bde240220807fa7502e07e1c0003222010e7c03ba7cf0e2fde82b2dc4d63077d422104a29514ae2208e2b234f80788640003222010fa8f20b781b5881329d4fea26b1a3c5121045afc8d7222082392f14f709ae000032220100fd4cc8dbe8715d1f439e304edfd68dc2104bc8d1c5b2208da7cdd6bfe2d7000
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: Received Event VLR_AUTH_E_HLR_SAI_ACK
DVLR SUBSCR(IMSI-901700000004620) Received 5 auth tuples
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_NEEDS_AUTH_WAIT_AI}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=0 -- will use GSM AKA (is_r99=no, at->vec.auth_types=0x1)
- sending GSM Auth Request for IMSI-901700000004620: tuple use_count=1 key_seq=0 auth_types=0x1 and...
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
- ...rand=585df1ae287f6e273dce07090d61320b
- ...expecting sres=2d8b2c3e
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 - vlr_gsupc_read_cb: now used by 1 (conn)
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
<-- GSUP rx OSMO_GSUP_MSGT_SEND_AUTH_INFO_RESULT: vlr_gsupc_read_cb() returns 0
lu_result_sent == 0
auth_request_sent == 1
---
- 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
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620: MSC conn use + dtap == 1 (0x2: dtap)
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
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000004620: MM GSM AUTHENTICATION RESPONSE (sres = 2d8b2c3e)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000004620) AUTH on GERAN received SRES/RES: 2d8b2c3e (4 bytes)
DVLR SUBSCR(IMSI-901700000004620) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Received Event VLR_ULA_E_AUTH_RES
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: vlr_loc_upd_post_auth()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: Set Ciphering Mode
DMM IMSI-901700000004620: to determine whether A5/3 is supported, first ask for a Classmark Update to obtain Classmark 2
DBSSAP RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Tx BSSMAP CLASSMARK REQUEST to BSC
2019-02-18 11:55:31 +00:00
DBSSAP RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: N-DATA.req(00 01 58 )
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
BSC <--BSSAP-BSS-MANAGEMENT-- MSC: CLASSMARK REQ [L3]> 00 01 58
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_WAIT_CLASSMARK_UPDATE
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_AUTH}: state_chg to VLR_ULA_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:GERAN-A-0:LU){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
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
lu_result_sent == 0
- BSC sends back a BSSMAP Classmark Update, that triggers the Ciphering Mode Command in A5/3
DMSC Looking for A subscriber: conn_id 0
2019-01-03 01:32:14 +00:00
DBSSAP RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Found A subscriber for conn_id 0
DBSSAP RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Rx BSSMAP DT1 CLASSMARK UPDATE
DBSSAP RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Rx BSSMAP CLASSMARK UPDATE
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Received Event RAN_CONN_E_CLASSMARK_UPDATE
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:LU){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: state_chg to RAN_CONN_S_AUTH_CIPH
DMM -> CIPHER MODE COMMAND IMSI-901700000004620
- sending Ciphering Mode Command for IMSI-901700000004620: include_imeisv=0
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
- ...perm algo: A5/3
- ...key: 61855fb81fc2a800
lu_result_sent == 0
- MS sends Ciphering Mode Complete, VLR accepts and sends GSUP LU Req to HLR
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000004620: CIPHERING MODE COMPLETE
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: Received Event VLR_ULA_E_CIPH_RES
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_post_ciph()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: vlr_loc_upd_node_4()
DVLR vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU){VLR_ULA_S_WAIT_CIPH}: state_chg to VLR_ULA_S_WAIT_HLR_UPD
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Allocated
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000004620:GERAN-A-0:LU)
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: Received Event UPD_HLR_VLR_E_START
2018-09-28 00:41:39 +00:00
DVLR GSUP tx: 04010809710000004026f0280102
GSUP --> HLR: OSMO_GSUP_MSGT_UPDATE_LOCATION_REQUEST: 04010809710000004026f0280102
2019-01-03 01:32:14 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_INIT}: state_chg to UPD_HLR_VLR_S_WAIT_FOR_DATA
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
lu_result_sent == 0
- HLR sends _INSERT_DATA_REQUEST, VLR responds with _INSERT_DATA_RESULT
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: 10010809710000004026f00804032443f2
DVLR GSUP rx 17: 10010809710000004026f00804032443f2
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
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
DVLR IMSI:901700000004620 has MSISDN:42342
2019-02-19 01:36:35 +00:00
DVLR SUBSCR(IMSI-901700000004620:MSISDN-42342) VLR: update for IMSI=901700000004620 (MSISDN=42342)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Updated ID
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
DVLR GSUP tx: 12010809710000004026f0
GSUP --> HLR: OSMO_GSUP_MSGT_INSERT_DATA_RESULT: 12010809710000004026f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - vlr_gsupc_read_cb: now used by 1 (conn)
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
<-- GSUP rx OSMO_GSUP_MSGT_INSERT_DATA_REQUEST: vlr_gsupc_read_cb() returns 0
lu_result_sent == 0
- HLR also sends GSUP _UPDATE_LOCATION_RESULT
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: 06010809710000004026f0
DVLR GSUP rx 11: 06010809710000004026f0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + vlr_gsupc_read_cb: now used by 2 (conn,vlr_gsupc_read_cb)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_HLR_LU_RES
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: Received Event UPD_HLR_VLR_E_UPD_LOC_ACK
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_WAIT_FOR_DATA}: state_chg to UPD_HLR_VLR_S_DONE
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: Received Event VLR_ULA_E_UPD_HLR_COMPL
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_WAIT_HLR_UPD}: state_chg to VLR_ULA_S_WAIT_LU_COMPL
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Allocated
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: is child of vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU)
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: Received Event LU_COMPL_VLR_E_START
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_INIT}: state_chg to LU_COMPL_VLR_S_WAIT_SUB_PRES
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: Received Event LU_COMPL_VLR_E_SUB_PRES_COMPL
- sending LU Accept for IMSI-901700000004620:MSISDN-42342
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + attached: now used by 3 (conn,vlr_gsupc_read_cb,attached)
2019-01-03 01:32:14 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_WAIT_SUB_PRES}: state_chg to LU_COMPL_VLR_S_DONE
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: Received Event VLR_ULA_E_LU_COMPL_SUCCESS
2019-03-24 20:07:33 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU))
2019-01-03 01:32:14 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Removing from parent vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU)
2019-03-24 20:07:33 +00:00
DVLR lu_compl_vlr_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){LU_COMPL_VLR_S_DONE}: Deferring: will deallocate with upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU)
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_WAIT_LU_COMPL}: state_chg to VLR_ULA_S_DONE
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + vlr_subscr_cancel_attach_fsm: now used by 4 (conn,vlr_gsupc_read_cb,attached,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - vlr_subscr_cancel_attach_fsm: now used by 3 (conn,vlr_gsupc_read_cb,attached)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
2019-03-24 20:07:33 +00:00
DVLR upd_hlr_vlr_fsm(IMSI-901700000004620:GERAN-A-0:LU){UPD_HLR_VLR_S_DONE}: Deallocated, including all deferred deallocations
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - vlr_gsupc_read_cb: now used by 2 (conn,attached)
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
<-- GSUP rx OSMO_GSUP_MSGT_UPDATE_LOCATION_RESULT: vlr_gsupc_read_cb() returns 0
bssap_clear_sent == 1
- LU was successful, and the conn has already been closed
lu_result_sent == 1
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU))
2019-01-03 01:32:14 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_DONE}: Removing from parent RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU)
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_DONE}: fsm_lu_cleanup called with cause OSMO_FSM_TERM_PARENT
2019-03-24 20:07:33 +00:00
DVLR vlr_lu_fsm(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){VLR_ULA_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000004620:MSISDN-42342: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:LU){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
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
---
- after a while, a new conn sends a CM Service Request. VLR responds with Auth Req, 2nd auth vector
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_CM_SERV_REQ
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
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
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
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
DRLL Dispatching 04.08 message GSM48_MT_MM_CM_SERV_REQ (0x5:0x24)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Updated ID
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Rx CM SERVICE REQUEST cm_service_type=0x08
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: Allocated
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: is child of RAN_conn(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: rev=GSM net=GERAN Auth+Ciph
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: Received Event PR_ARQ_E_START
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + proc_arq_vlr_fn_init: now used by 2 (attached,proc_arq_vlr_fn_init)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + conn: now used by 3 (attached,proc_arq_vlr_fn_init,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Updated ID
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: proc_arq_vlr_fn_post_imsi()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_INIT}: state_chg to PR_ARQ_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: is child of Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=1 -- will use GSM AKA (is_r99=no, at->vec.auth_types=0x1)
- sending GSM Auth Request for IMSI-901700000004620:MSISDN-42342: tuple use_count=1 key_seq=1 auth_types=0x1 and...
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
- ...rand=12aca96fb4ffdea5c985cbafa9b6e18b
- ...expecting sres=20bde240
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - proc_arq_vlr_fn_init: now used by 2 (attached,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
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
auth_request_sent == 1
cm_service_result_sent == 0
- needs auth, not yet accepted
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
ran_conn_is_accepted() == false
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
requests shall be thwarted
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_CC_SETUP
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
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: unknown 0x33
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
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
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
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: SMS:0x01
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
- MS sends Authen Response, VLR accepts and requests Ciphering. We already know Classmark 3, so no need to request Classmark Update.
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + dtap == 1 (0x2: dtap)
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
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000004620:MSISDN-42342: MM GSM AUTHENTICATION RESPONSE (sres = 20bde240)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000004620:MSISDN-42342) AUTH on GERAN received SRES/RES: 20bde240 (4 bytes)
DVLR SUBSCR(IMSI-901700000004620:MSISDN-42342) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_AUTHENTICATED}: Removing from parent Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: Received Event PR_ARQ_E_AUTH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: _proc_arq_vlr_node2()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: Set Ciphering Mode
DMM -> CIPHER MODE COMMAND IMSI-901700000004620:MSISDN-42342
- sending Ciphering Mode Command for IMSI-901700000004620:MSISDN-42342: include_imeisv=0
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
- ...perm algo: A5/3
- ...key: 07fa7502e07e1c00
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_AUTH}: state_chg to PR_ARQ_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
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
cm_service_result_sent == 0
cipher_mode_cmd_sent == 1
- needs ciph, not yet accepted
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
ran_conn_is_accepted() == false
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
requests shall be thwarted
DRLL Dispatching 04.08 message GSM48_MT_CC_SETUP (0x3:0x5)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_CC_SETUP
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
DRLL Dispatching 04.08 message unknown 0x33 (0x5:0x33)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: unknown 0x33
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
DRLL Dispatching 04.08 message GSM48_MT_RR_SYSINFO_1 (0x6:0x19)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: GSM48_MT_RR_SYSINFO_1
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
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-03 01:32:14 +00:00
DRLL subscr IMSI-901700000004620:MSISDN-42342: Message not permitted for initial conn: SMS:0x01
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
- MS sends Ciphering Mode Complete, VLR accepts; above Ciphering is an implicit CM Service Accept
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000004620:MSISDN-42342: CIPHERING MODE COMPLETE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: Received Event PR_ARQ_E_CIPH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_ciph()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_vlr()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_pres()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_trace()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_imei()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: proc_arq_fsm_done(PASSED)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_WAIT_CIPH}: state_chg to PR_ARQ_S_DONE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Process Access Request result: PASSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + cm_service == 1 (0x8: cm_service)
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_ACCEPTED}: ran_conn_fsm_has_active_transactions: still awaiting first request after a CM Service Request
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
cm_service_result_sent == 0
- Concluding CM Service Request
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - cm_service == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,conn,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,conn)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
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
bssap_clear_sent == 1
- all requests serviced, conn has been released
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ))
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Removing from parent RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){PR_ARQ_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000004620:MSISDN-42342: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:CM_SERVICE_REQ){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
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
---
- an SMS is sent, MS is paged
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + test_cm_service_needs_classmark_update: now used by 2 (attached,test_cm_service_needs_classmark_update)
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
llist_count(&vsub->cs.requests) == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + SMS-receiver: now used by 3 (attached,test_cm_service_needs_classmark_update,SMS-receiver)
2019-01-16 11:47:39 +00:00
DLSMS Going to send a MT SMS
2019-01-03 01:32:14 +00:00
DCC (ti 00 sub IMSI-901700000004620:MSISDN-42342 callref 40000005) New transaction
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + SMS: now used by 4 (attached,test_cm_service_needs_classmark_update,SMS-receiver,SMS)
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) instance created for network
DLSMS SMR(0) instance created for network.
DLSMS SMR(0) message SM-RL-DATA_REQ received in state IDLE
DLSMS SMR(0) TX SMS RP-DATA
DLSMS SMR(0) new RP state IDLE -> WAIT_FOR_RP_ACK
DLSMS SMC(0) message MNSMS-EST-REQ received in state IDLE
DLSMS SMC(0) new CP state IDLE -> MM_CONN_PENDING
DLSMS Initiating Paging procedure for IMSI-901700000004620:MSISDN-42342 due to MMSMS_EST_REQ
2019-01-03 01:32:14 +00:00
DMM Subscriber IMSI-901700000004620:MSISDN-42342 not paged yet, start paging.
2018-12-25 23:40:18 +00:00
GERAN-A sends out paging request to IMSI 901700000004620, TMSI 0xffffffff, LAC 23
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
strcmp(paging_expecting_imsi, imsi) == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + Paging: now used by 5 (attached,test_cm_service_needs_classmark_update,SMS-receiver,SMS,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
llist_count(&vsub->cs.requests) == 1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - test_cm_service_needs_classmark_update: now used by 4 (attached,SMS-receiver,SMS,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
paging_sent == 1
paging_stopped == 0
- the subscriber and its pending request should remain
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + test_cm_service_needs_classmark_update: now used by 5 (attached,SMS-receiver,SMS,Paging,test_cm_service_needs_classmark_update)
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
llist_count(&vsub->cs.requests) == 1
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - test_cm_service_needs_classmark_update: now used by 4 (attached,SMS-receiver,SMS,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
- MS replies with Paging Response, and VLR sends Auth Request with third key
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_PAG_RESP
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
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
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
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
DRLL Dispatching 04.08 message GSM48_MT_RR_PAG_RESP (0x6:0x27)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: Updated ID
DRR RAN_conn(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: PAGING RESPONSE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: Allocated
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: is child of RAN_conn(IMSI-901700000004620:GERAN-A-0:PAGING_RESP)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: rev=GSM net=GERAN Auth+Ciph
DVLR Process_Access_Request_VLR(IMSI-901700000004620:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: Received Event PR_ARQ_E_START
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + proc_arq_vlr_fn_init: now used by 5 (attached,SMS-receiver,SMS,Paging,proc_arq_vlr_fn_init)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + conn: now used by 6 (attached,SMS-receiver,SMS,Paging,proc_arq_vlr_fn_init,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: Updated ID
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: proc_arq_vlr_fn_post_imsi()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_INIT}: state_chg to PR_ARQ_S_WAIT_AUTH
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: Allocated
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: is child of Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: Received Event VLR_AUTH_E_START
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_NEEDS_AUTH}: state_chg to VLR_SUB_AS_WAIT_RESP
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: got auth tuple: use_count=1 key_seq=2 -- will use GSM AKA (is_r99=no, at->vec.auth_types=0x1)
- sending GSM Auth Request for IMSI-901700000004620:MSISDN-42342: tuple use_count=1 key_seq=2 auth_types=0x1 and...
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
- ...rand=e7c03ba7cf0e2fde82b2dc4d63077d42
- ...expecting sres=a29514ae
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - proc_arq_vlr_fn_init: now used by 5 (attached,SMS-receiver,SMS,Paging,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: Received Event RAN_CONN_E_COMPLETE_LAYER_3
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_AUTH_CIPH
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - compl_l3 == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
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
auth_request_sent == 1
---
- Fake a situation where Classmark 2 is unknown during proc_arq_fsm
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + test_cm_service_needs_classmark_update: now used by 6 (attached,SMS-receiver,SMS,Paging,conn,test_cm_service_needs_classmark_update)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - test_cm_service_needs_classmark_update: now used by 5 (attached,SMS-receiver,SMS,Paging,conn)
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
- MS sends Authen Response, VLR accepts and requests Ciphering
- MS sends Authen Response, VLR accepts and requests Ciphering. Normally, we'd know Classmark 3, but this test removed it. Hence a Classmark Request is generated.
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_AUTH_RESP
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + dtap == 1 (0x2: dtap)
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
DRLL Dispatching 04.08 message GSM48_MT_MM_AUTH_RESP (0x5:0x14)
2019-01-03 01:32:14 +00:00
DMM IMSI-901700000004620:MSISDN-42342: MM GSM AUTHENTICATION RESPONSE (sres = a29514ae)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: Received Event VLR_AUTH_E_MS_AUTH_RESP
DVLR SUBSCR(IMSI-901700000004620:MSISDN-42342) AUTH on GERAN received SRES/RES: a29514ae (4 bytes)
DVLR SUBSCR(IMSI-901700000004620:MSISDN-42342) AUTH established GSM security context
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: Authentication terminating with result PASSED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_WAIT_RESP}: state_chg to VLR_SUB_AS_AUTHENTICATED
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_AUTHENTICATED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_AUTHENTICATED}: Removing from parent Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: Received Event PR_ARQ_E_AUTH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: _proc_arq_vlr_node2()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: Set Ciphering Mode
DMM IMSI-901700000004620:MSISDN-42342: to determine whether A5/3 is supported, first ask for a Classmark Update to obtain Classmark 2
DBSSAP RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Tx BSSMAP CLASSMARK REQUEST to BSC
2019-02-18 11:55:31 +00:00
DBSSAP RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: N-DATA.req(00 01 58 )
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
BSC <--BSSAP-BSS-MANAGEMENT-- MSC: CLASSMARK REQ [L3]> 00 01 58
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_WAIT_CLASSMARK_UPDATE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_AUTH}: state_chg to PR_ARQ_S_WAIT_CIPH
2019-03-24 20:07:33 +00:00
DVLR VLR_Authenticate(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){VLR_SUB_AS_AUTHENTICATED}: Deallocated
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Awaiting results for Auth+Ciph, overruling event RAN_CONN_E_UNUSED
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
- BSC sends back a BSSMAP Classmark Update, that triggers the Ciphering Mode Command in A5/3
DMSC Looking for A subscriber: conn_id 0
2019-01-03 01:32:14 +00:00
DBSSAP RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Found A subscriber for conn_id 0
DBSSAP RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Rx BSSMAP DT1 CLASSMARK UPDATE
DBSSAP RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Rx BSSMAP CLASSMARK UPDATE
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: Received Event RAN_CONN_E_CLASSMARK_UPDATE
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_WAIT_CLASSMARK_UPDATE}: state_chg to RAN_CONN_S_AUTH_CIPH
DMM -> CIPHER MODE COMMAND IMSI-901700000004620:MSISDN-42342
- sending Ciphering Mode Command for IMSI-901700000004620:MSISDN-42342: include_imeisv=0
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
- ...perm algo: A5/3
- ...key: e2b234f807886400
- needs ciph, not yet accepted
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
ran_conn_is_accepted() == false
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
- MS sends Ciphering Mode Complete, VLR accepts and sends pending SMS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_RR_CIPH_M_COMPL
2019-01-03 01:32:14 +00:00
DRR IMSI-901700000004620:MSISDN-42342: CIPHERING MODE COMPLETE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: Received Event PR_ARQ_E_CIPH_RES
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_ciph()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_node2_post_vlr()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_pres()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_trace()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: _proc_arq_vlr_post_imei()
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: proc_arq_fsm_done(PASSED)
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_WAIT_CIPH}: state_chg to PR_ARQ_S_DONE
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Process Access Request result: PASSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: Received Event RAN_CONN_E_ACCEPTED
DPAG Paging success for IMSI-901700000004620:MSISDN-42342 (event=0)
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
DPAG Calling paging cbfn.
2019-01-16 11:47:39 +00:00
DLSMS paging_cb_mmsms_est_req(hooknum=1, event=0)
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + trans_sms == 1 (0x20: trans_sms)
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) message MMSMS-EST-CNF received in state MM_CONN_PENDING
DLSMS SMC(0) send CP data
DLSMS SMC(0) new CP state MM_CONN_PENDING -> WAIT_CP_ACK
DLSMS sending CP message (trans=0)
DLSMS GSM4.11 TX 09 01 58 01 00 07 91 44 77 58 10 06 50 00 4c 00 05 80 24 43 f2 00 00 07 10 10 00 00 00 00 44 50 79 da 1e 1e e7 41 69 37 48 5e 9e a7 c9 65 37 3d 1d 66 83 c2 70 38 3b 3d 0e d3 d3 6f f7 1c 94 9e 83 c2 20 72 79 9e 96 87 c5 ec 32 a8 1d 96 af cb f4 b4 fb 0c 7a c3 e9 e9 b7 db 05
2019-01-03 01:32:14 +00:00
DMSC msc_tx 91 bytes to IMSI-901700000004620:MSISDN-42342 via GERAN-A
2018-12-25 23:40:18 +00:00
- DTAP --GERAN-A--> MS: SMS:0x01: 09015801000791447758100650004c0005802443f2000007101000000000445079da1e1ee7416937485e9ea7c965373d1d6683c270383b3d0ed3d36ff71c949e83c22072799e9687c5ec32a81d96afcbf4b4fb0c7ac3e9e9b7db05
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
- DTAP matches expected message
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - Paging: now used by 4 (attached,SMS-receiver,SMS,conn)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_AUTH_CIPH}: state_chg to RAN_CONN_S_ACCEPTED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_ACCEPTED}: ran_conn_fsm_has_active_transactions: connection still has active transaction: SMS
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
dtap_tx_confirmed == 1
paging_stopped == 1
- SMS was delivered, no requests pending for subscr
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + test_cm_service_needs_classmark_update: now used by 5 (attached,SMS-receiver,SMS,conn,test_cm_service_needs_classmark_update)
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
llist_count(&vsub->cs.requests) == 0
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - test_cm_service_needs_classmark_update: now used by 4 (attached,SMS-receiver,SMS,conn)
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
- conn is still open to wait for SMS ack dance
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
llist_count(&net->ran_conns) == 1
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
- MS replies with CP-ACK for received SMS
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: SMS:0x04
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + dtap == 2 (0x22: dtap,trans_sms)
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
DRLL Dispatching 04.08 message SMS:0x04 (0x9:0x4)
2019-01-16 11:47:39 +00:00
DLSMS receiving data (trans_id=0, msg_type=SMS:0x04)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_ACCEPTED}: Received Event RAN_CONN_E_COMMUNICATING
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_ACCEPTED}: state_chg to RAN_CONN_S_COMMUNICATING
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) message MMSMS-DATA-IND (CP ACK) received in state WAIT_CP_ACK
DLSMS SMC(0) received CP-ACK
DLSMS SMC(0) new CP state WAIT_CP_ACK -> MM_ESTABLISHED
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - dtap == 1 (0x20: trans_sms)
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
llist_count(&net->ran_conns) == 1
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
- MS also sends RP-ACK, MSC in turn sends CP-ACK for that
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: SMS:0x01
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + dtap == 2 (0x22: dtap,trans_sms)
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
DRLL Dispatching 04.08 message SMS:0x01 (0x9:0x1)
2019-01-16 11:47:39 +00:00
DLSMS receiving data (trans_id=0, msg_type=SMS:0x01)
2019-01-03 01:32:14 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_COMMUNICATING}: Received Event RAN_CONN_E_COMMUNICATING
2019-01-16 11:47:39 +00:00
DLSMS SMC(0) message MMSMS-DATA-IND (CP DATA) received in state MM_ESTABLISHED
DLSMS SMC(0) received CP-DATA
DLSMS sending CP message (trans=0)
DLSMS GSM4.11 TX 09 04
2019-01-03 01:32:14 +00:00
DMSC msc_tx 2 bytes to IMSI-901700000004620:MSISDN-42342 via GERAN-A
2018-12-25 23:40:18 +00:00
- DTAP --GERAN-A--> MS: SMS:0x04: 0904
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
- DTAP matches expected message
2019-01-16 11:47:39 +00:00
DLSMS MNSMS-DATA/EST-IND
DLSMS SMR(0) message MNSMS-DATA-IND received in state WAIT_FOR_RP_ACK
DLSMS SMR(0) RX SMS RP-ACK
DLSMS SMR(0) new RP state WAIT_FOR_RP_ACK -> IDLE
DLSMS RX SMS RP-ACK (MO)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - SMS-receiver: now used by 3 (attached,SMS,conn)
2019-01-16 11:47:39 +00:00
DLSMS SMR(0) TX: MNSMS-REL-REQ
DLSMS SMC(0) message MNSMS-REL-REQ received in state MM_ESTABLISHED
DLSMS SMC(0) new CP state MM_ESTABLISHED -> IDLE
DLSMS Got MMSMS_REL_REQ, destroying transaction.
DLSMS SMR(0) clearing SMR instance
DLSMS SMC(0) clearing instance
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - SMS: now used by 2 (attached,conn)
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - trans_sms == 1 (0x2: dtap)
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - dtap == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_COMMUNICATING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_COMMUNICATING}: state_chg to RAN_CONN_S_RELEASING
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use + release == 1 (0x100: release)
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,conn,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,conn)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
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
dtap_tx_confirmed == 1
bssap_clear_sent == 1
- SMS is done, conn is gone
- BSS sends BSSMAP Clear Complete
2019-01-03 01:32:14 +00:00
DREF IMSI-901700000004620:MSISDN-42342: MSC conn use - release == 0 (0x0: )
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Terminating in cascade, depth 2 (cause = OSMO_FSM_TERM_PARENT, caused by: RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP))
2019-01-03 01:32:14 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Removing from parent RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP)
2019-03-24 20:07:33 +00:00
DVLR Process_Access_Request_VLR(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){PR_ARQ_S_DONE}: Deferring: will deallocate with RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP)
2019-01-03 01:32:14 +00:00
DRLL IMSI-901700000004620:MSISDN-42342: Freeing RAN connection
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - conn: now used by 1 (attached)
2019-03-24 20:07:33 +00:00
DMM RAN_conn(IMSI-901700000004620:MSISDN-42342:GERAN-A-0:PAGING_RESP){RAN_CONN_S_RELEASED}: Deallocated, including all deferred deallocations
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
llist_count(&net->ran_conns) == 0
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
---
- subscriber detaches
2018-12-25 23:40:18 +00:00
MSC <--GERAN-A-- MS: GSM48_MT_MM_IMSI_DETACH_IND
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
new conn
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
DMM RAN_conn{RAN_CONN_S_NEW}: Allocated
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
DREF unknown: MSC conn use + compl_l3 == 1 (0x1: compl_l3)
DRLL Dispatching 04.08 message GSM48_MT_MM_IMSI_DETACH_IND (0x5:0x1)
DMM IMSI DETACH INDICATION: MI(IMSI)=901700000004620
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + gsm48_rx_mm_imsi_detach_ind: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
2019-01-03 01:32:14 +00:00
DMM IMSI DETACH for IMSI-901700000004620:MSISDN-42342
2019-02-19 01:36:35 +00:00
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 + vlr_subscr_cancel_attach_fsm: now used by 3 (attached,gsm48_rx_mm_imsi_detach_ind,vlr_subscr_cancel_attach_fsm)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - vlr_subscr_cancel_attach_fsm: now used by 2 (attached,gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - attached: now used by 1 (gsm48_rx_mm_imsi_detach_ind)
DREF VLR subscr IMSI-901700000004620:MSISDN-42342 - gsm48_rx_mm_imsi_detach_ind: now used by 0 (-)
2019-01-03 01:32:14 +00:00
DREF freeing VLR subscr IMSI-901700000004620:MSISDN-42342
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
DMM RAN_conn{RAN_CONN_S_NEW}: Received Event RAN_CONN_E_CN_CLOSE
DMM RAN_conn{RAN_CONN_S_NEW}: state_chg to RAN_CONN_S_RELEASING
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
DREF unknown: MSC conn use + release == 2 (0x101: compl_l3,release)
2018-12-25 23:40:18 +00:00
- BSSAP Clear --GERAN-A--> MS
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
DREF unknown: MSC conn use - compl_l3 == 1 (0x100: release)
bssap_clear_sent == 1
- BSS sends BSSMAP Clear Complete
DREF unknown: MSC conn use - release == 0 (0x0: )
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
DMM RAN_conn{RAN_CONN_S_RELEASING}: Received Event RAN_CONN_E_UNUSED
DMM RAN_conn{RAN_CONN_S_RELEASING}: state_chg to RAN_CONN_S_RELEASED
DMM RAN_conn{RAN_CONN_S_RELEASED}: Terminating (cause = OSMO_FSM_TERM_REGULAR)
DRLL Freeing RAN connection with NULL subscriber
DMM RAN_conn{RAN_CONN_S_RELEASED}: Deallocated
llist_count(&net->ran_conns) == 0
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_cm_service_needs_classmark_update: SUCCESS
2018-03-02 00:50:42 +00:00
full talloc report on 'msgb' (total 0 bytes in 1 blocks)
2018-12-06 11:06:59 +00:00
talloc_total_blocks(tall_bsc_ctx) == 13
2018-03-02 00:50:42 +00:00
2017-01-25 14:04:16 +00:00
full talloc report on 'msgb' (total 0 bytes in 1 blocks)
2018-12-06 11:06:59 +00:00
talloc_total_blocks(tall_bsc_ctx) == 13
2017-01-25 14:04:16 +00:00