Bug #2886
closedOsmoMSC doesn't reject subscriber after GSUP Cancel Location
Added by laforge over 6 years ago. Updated over 5 years ago.
0%
Description
When the HLR cancels a subscriber in the VLR, he must be removed and we must not provide any further service to the subscriber.
However, when trying this in MSC_Tests.TC_gsup_cancel, it doesn't work:- OsmoMSC positively acknowledges the GSUP LocationCancel
- a subsqeuenc CM SERV REQ is still acknowledged with a CM SERV ACK
Files
20180127-osmomsc-location_cancel.pcap | 20180127-osmomsc-location_cancel.pcap | 5.72 KB | pcap file showing the problem | laforge, 01/27/2018 02:51 PM |
Updated by laforge over 6 years ago
Seems to be related to the fact that vsub->imsi_detached_flag is set in three locations, but never actually used/read.
Updated by stsp over 5 years ago
The underlying problem could be an error in reference counting or mismanagement of the connection associated with the subscriber.
When the subscriber gets cancelled in the VLR, its reference count does not go down to zero, it only goes down to one:
Mon Dec 10 16:46:09 2018 DLINP <0013> input/ipa.c:135 127.0.0.1:4222 connected read Mon Dec 10 16:46:09 2018 DLINP <0013> input/ipa.c:56 127.0.0.1:4222 message received Mon Dec 10 16:46:09 2018 DVLR <000e> vlr.c:986 GSUP rx 14: 1c010862420200000030f3060101 Mon Dec 10 16:46:09 2018 DREF <000a> vlr.c:1007 VLR subscr MSISDN:491230000033 usage increases to: 2 Mon Dec 10 16:46:09 2018 DVLR <000e> vlr.c:965 SUBSCR(MSISDN:491230000033) Cancelling MS subscriber (subscription withdraw) Mon Dec 10 16:46:09 2018 DVLR <000e> vlr.c:175 GSUP tx: 1e010862420200000030f3 Mon Dec 10 16:46:09 2018 DREF <000a> vlr.c:282 VLR subscr MSISDN:491230000033 usage increases to: 3 Mon Dec 10 16:46:09 2018 DREF <000a> vlr.c:287 VLR subscr MSISDN:491230000033 usage decreases to: 2 Mon Dec 10 16:46:09 2018 DREF <000a> vlr.c:1051 VLR subscr MSISDN:491230000033 usage decreases to: 1
So the subscriber is now cancelled but it is not freed yet.
It seems quite likely that other code will still keep assuming that this subscriber is valid.
The MSC then simply continues with processing IPA messages:
Mon Dec 10 16:46:09 2018 DLINP <0013> input/ipa.c:139 127.0.0.1:4222 connected write Mon Dec 10 16:46:09 2018 DLINP <0013> input/ipa.c:89 127.0.0.1:4222 sending data Mon Dec 10 16:46:09 2018 DLINP <0013> input/ipa.c:139 127.0.0.1:4222 connected write Mon Dec 10 16:46:09 2018 DLINP <0013> input/ipa.c:89 127.0.0.1:4222 sending data
The remaining reference is held by the connection associated with the subscriber.
This reference is obtained in this section of gsm_04_08.c:
1765 /* VLR informs us that the subscriber has been associated with a conn */ 1766 static void msc_vlr_subscr_assoc(void *msc_conn_ref, 1767 struct vlr_subscr *vsub) 1768 { 1769 struct ran_conn *conn = msc_conn_ref; 1770 OSMO_ASSERT(vsub); 1771 OSMO_ASSERT(!conn->vsub); 1772 conn->vsub = vlr_subscr_get(vsub);
The only obvious place where this reference is released again is when an IMSI detach is processed:
833 static int gsm48_rx_mm_imsi_detach_ind(struct ran_conn *conn, struct msgb *msg) 834 { [...] 869 if (!vsub) { 870 LOGP(DMM, LOGL_ERROR, "IMSI DETACH for unknown subscriber MI(%s)=%s\n", 871 gsm48_mi_type_name(mi_type), mi_string); 872 } else { 873 LOGP(DMM, LOGL_INFO, "IMSI DETACH for %s\n", vlr_subscr_name(vsub)); 874 875 if (vsub->cs.is_paging) 876 subscr_paging_cancel(vsub, GSM_PAGING_EXPIRED); 877 878 /* We already got Classmark 1 during Location Updating ... but well, ok */ 879 vsub->classmark.classmark1 = idi->classmark1; 880 881 vlr_subscr_rx_imsi_detach(vsub); 882 osmo_signal_dispatch(SS_SUBSCR, S_SUBSCR_DETACHED, vsub); 883 vlr_subscr_put(vsub); 884 } 885 886 ran_conn_close(conn, 0); 887 return 0; 888 }
Shouldn't a cancelled subscriber be freed as well?
If so, what is the best way to go about this?
Should the VLR simulate an IMSI detach when the subscriber is cancelled?
Should the connection be closed directly in vlr.c?
Should we trigger some FSM state change which will cause the connection to be closed?
Updated by stsp over 5 years ago
Faking an IMSI detach makes the gsup_cancel test happy:
https://gerrit.osmocom.org/c/osmo-msc/+/12232
But is this the right approach?
Updated by stsp over 5 years ago
- Status changed from In Progress to Resolved
Apparently, it is the right approach. Above patch has been merged.