Cellular Network Infrastructure » Core Network (CN) » OsmoMSC

Seems to be related to the fact that vsub->imsi_detached_flag is set in three locations, but never actually used/read.

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?

Faking an IMSI detach makes the gsup_cancel test happy:
https://gerrit.osmocom.org/c/osmo-msc/+/12232

But is this the right approach?

Apparently, it is the right approach. Above patch has been merged.