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:
parent
93fbcdfb39
commit
c97a7f51e1
|
@ -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));
|
||||
|
|
Loading…
Reference in New Issue