OsmoMSC never closes SCCP Connection after CM SERVICE ACCEPT
When OsmoMSC sends a CM SERVICE ACCEPT to the MS, it seems there is no global timer running. If there's no follow-up signalling message, OsmoMSC will apparently never close the channel, leading to resource exhaustion. I've tested this for 13 minutes, without any timeout.
See attached pcap file and the TC_establish_and_nothing timer in the TTCN-3 testsuite.
in osmo-msc's conn FSM, a CM Service Request should put the conn it the ACCEPTED state, and it should go to COMMUNICATING as soon as the request is actually issued.
The ACCEPTED state is always entered with a timeout, so the intention is that a conn goes away when there is a lack of an actual request.
The timeout of the ACCEPTED state should fire a CN_CLOSE event, closing the conn unconditionally.
Looking at the code indicates that this should work, and if it doesn't then a bug is hiding in there somewhere.
All of this is / should be happening in osmo-msc/src/libmsc/subscr_conn.c
- Various code paths enter the SUBSCR_CONN_S_ACCEPTED with a timeout.
- subscr_conn_fsm_accepted_enter() checks if a CM Service Request is pending.
- subscr_conn_fsm_timeout() should fire and close.
Implementing a test in ttcn3 would require to be silent for 5 seconds after a CM Service Request (far less than 13 minutes!),
so, quite practical.
An alternative is to use msc_vlr_tests and fake_time to tickle the bug.
See msc_vlr_test_ms_timeout.c intended for tests where the MS doesn't respond.
Should be easy to copy a basic msc_vlr_test_no_authen.c over there and just let fake time pass after a CM Service Request.