rsl: NACK Chan Activation for lchans on disabled TS

A broken BSC could send a Chan Activation on a TS which has not yet been
enabled (or even configured). This is the case with our TTCN3 tests,
where OML side is currently handled in parallel by an osmo-bsc while
TTCN3 takes care of the RSL side. This can actually be seen as a
malfunctioning BSC, but it was spotted that given this sequence of
events osmo-bts can crash (see ticket below).

Hence, let's NACK any attempt from a BSC to activate an lchan on a
disabled TS.

Related: OS#5249
Change-Id: I9c3b68487c12efc412a057728a561e061560c544
This commit is contained in:
Pau Espin 2021-10-06 20:23:56 +02:00
parent 93fbcdfb39
commit c97a7f51e1
1 changed files with 7 additions and 0 deletions

View File

@ -1633,6 +1633,13 @@ static int rsl_rx_chan_activ(struct msgb *msg)
return rsl_tx_chan_act_nack(lchan, RSL_ERR_EQUIPMENT_FAIL);
}
if (ts->mo.nm_state.operational != NM_OPSTATE_ENABLED ||
ts->mo.nm_state.availability != NM_AVSTATE_OK) {
LOGP(DRSL, LOGL_ERROR, "%s rx chan activ but TS not in nm_state oper=ENABLED avail=OK, nack!\n",
gsm_ts_and_pchan_name(ts));
return rsl_tx_chan_act_nack(lchan, RSL_ERR_RR_UNAVAIL);
}
if (ts->pchan == GSM_PCHAN_OSMO_DYN) {
ts->dyn.pchan_want = dyn_pchan_from_chan_nr(dch->chan_nr);
DEBUGP(DRSL, "%s rx chan activ\n", gsm_ts_and_pchan_name(ts));