Project

General

Profile

Actions

Bug #3333

closed

lchan release may stall indefinitely

Added by laforge almost 6 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
A-bis RSL
Target version:
-
Start date:
06/11/2018
Due date:
% Done:

100%

Spec Reference:

Description

When the MSC hard-releases the SCCP connection, we terminate the bsc_subscr_conn_fsm, which calls lchan_release(conn->lchan, 0, RSL_REL_LOCAL_END); from the fsm cleanup call-back.

That in turn causes a RLL_REL_REQ to be transmitted. However, if the MS never responds to that (out of reach, power-cycle, ...) there appears to be no timer running which would proceed with sending an RSL RF CHAN REL to actually release the channel.

This is currently triggered by TC_bssap_rlsd_does_not_cause_bssmap_reset involuntarily, as it tries to allocate 8 SDCCH.

Attaching a pcap file.

I'll add a dedicated test for this behavior.


Files

20180611-lchan_rel.pcap 20180611-lchan_rel.pcap 1.67 KB laforge, 06/11/2018 03:54 PM
Actions #1

Updated by laforge almost 6 years ago

New test provoking this problem is in https://gerrit.osmocom.org/#/c/osmo-ttcn3-hacks/+/9548

Assigned to neels as his existing work on lchan FSM will likely solve this bug.

Actions #2

Updated by neels almost 6 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 90

is solved on branch neels/inter-bsc-ho (ttcn3 test passes), as part of the "large refactoring" lchan FSMs

Actions #3

Updated by neels over 5 years ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

in the new lchan FSM merged to osmo-bsc master, the lchan release will no longer stall, since we have FSM state timeouts now.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)