aboutsummaryrefslogtreecommitdiffstats
path: root/src/osmo-bsc/abis_rsl.c
diff options
context:
space:
mode:
authorNeels Hofmeyr <neels@hofmeyr.de>2018-11-03 18:36:13 +0100
committerNeels Hofmeyr <nhofmeyr@sysmocom.de>2018-11-14 16:16:30 +0000
commit478e991a78c47988fdf2a667c6771ccd496e03a6 (patch)
tree02b8269cf63c664eb38dc9f250d6a4db5401ad14 /src/osmo-bsc/abis_rsl.c
parent946d1fb5c7f4a593567b407222c9235f8fac7a59 (diff)
fix: send RR Release (e.g. after BSSMAP Clear Cmd)
After commit [1], the code makes sure to disassociate lchan and conn before invoking the lchan release. However, we only send RR Release if a conn is present, which clearly is nonsense after [1]. [1] commit 8b818a01b00ea3daad4ad58c162ac52b4f08a5cb "subscr conn: properly forget lchan before release" Change-Id: I4fd582b41ba4599af704d670af83651d2450b1db Manage sending of RR Release via a flag, set during invoking lchan release. Add do_rr_release arg to lchan_release(), gscon_release_lchans(). In lchan_fsm.c, send RR Release only if do_rr_release was passed true; do not care whether a conn is still associated (because it won't ever be since [1]). That way we can intelligently decide what release process makes sense (whether the lchan terminates the subscriber connection or whether the connection goes on at another lchan), and still disassociate lchan and conn early. BTW, this problem wasn't caught by the stock OsmoBSC TTCN3 tests, because the f_expect_chan_rel() don't care whether an RR Release happens or not. This is being fixed by Ibc64058f1e214bea585f4e8dcb66f3df8ead3845. So far this patch should fix BSC_Tests_LCLS.TC_lcls_connect_clear. Related: OS#3413 Change-Id: I666b3b4f45706d898d664d380bd0fd2b018be358
Diffstat (limited to 'src/osmo-bsc/abis_rsl.c')
-rw-r--r--src/osmo-bsc/abis_rsl.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/src/osmo-bsc/abis_rsl.c b/src/osmo-bsc/abis_rsl.c
index bd104edd5..ea537fe81 100644
--- a/src/osmo-bsc/abis_rsl.c
+++ b/src/osmo-bsc/abis_rsl.c
@@ -901,7 +901,7 @@ static int rsl_rx_conn_fail(struct msgb *msg)
* the connection will presumably be torn down and lead to an lchan release. During initial
* Channel Request from the MS, an lchan has no conn yet, so in that case release now. */
if (!lchan->conn) {
- lchan_release(lchan, false, true, *cause_p);
+ lchan_release(lchan, false, false, true, *cause_p);
} else
osmo_fsm_inst_dispatch(lchan->conn->fi, GSCON_EV_RSL_CONN_FAIL, (void*)cause_p);