Project

General

Profile

Bug #3333

lchan release may stall indefinitely

Added by laforge 3 months ago. Updated about 1 month ago.

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

100%

Estimated time:
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.

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

History

#1 Updated by laforge 3 months 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.

#2 Updated by neels 2 months 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

#3 Updated by neels about 1 month 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.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)