Bug #3122

Updated by neels almost 3 years ago

Various reports and patches pop up with various people about the MSC's subscr_conn FSM not handling specific corner cases properly.

* If anything goes wrong during compl-l3, the FSM might think that it is busy with auth+ciph. Need a separate state for auth+ciph; then at the end of msc_compl_l3() discard any conn that is still in state 'NEW'.
* For failure situations causing premature conn release, properly handle release messages and receive responses in a separate 'RELEASING' state.

* In the course of that, it may make sense to refactor:
** closely tie the FSM with the struct gsm_subscriber_connection. Historically, the ownership was shared between libbsc and libmsc, complicating the ref-count in that the FSM was a separate entity. It should be possible to refactor the conn struct and the FSM as "a single entity", triggering a release event by the ref-count reaching zero, instead of needing explicit "release if unused" events.
** -CM CM Service Requests may actually overlap. The conn->received_cm_service_request however is a boolean, which means that we possibly lose the pending-ness of a second CM Service Request if a first one concludes at just the wrong time, or if two come in "consecutively".- -> #3156 "consecutively".

That's a lot to ask for in a single issue, but it makes sense to tie all of these items into a refactoring of the subscr_conn FSM.


Add picture from clipboard (Maximum size: 48.8 MB)