Bug #2879

OsmoMSC never closes SCCP Connection after CM SERVICE ACCEPT

Added by laforge 12 months ago. Updated 8 months ago.

A interface (general)
Target version:
Start date:
Due date:
% Done:




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.


#1 Updated by laforge 8 months ago

  • Assignee changed from sysmocom to stsp

#2 Updated by neels 8 months ago

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.

#3 Updated by stsp 8 months ago

I believe this issue can now be closed.

Looking through the Jenkins TTCN3 test logs, test case TC_establish_and_nothing passes and the associated pcap file shows 5 seconds of silence between the MSC sending a CM Service Accept message and then a Clear Command message which is ACKed with a Clear Complete.

Direct link to pcap file:

#4 Updated by stsp 8 months ago

  • Status changed from New to Resolved

#5 Updated by stsp 8 months ago updates expected test result for the "establish and nothing" test case.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)