diff options
| author | Pau Espin Pedrol <pespin@sysmocom.de> | 2022-06-02 12:14:17 +0200 |
|---|---|---|
| committer | Pau Espin Pedrol <pespin@sysmocom.de> | 2022-06-02 12:51:35 +0200 |
| commit | 7e10af9ab06138430d4c7cded8b826e20897ef60 (patch) | |
| tree | 6f77c2b70ebc8a37944f1943dfdbb056be56c38d | |
| parent | b4269f15ebfe9bb28df0c439e1d7df0f45118a8d (diff) | |
nm_rcarrier_fsm: Trigger S_NM_RUNNING_CHG when Admin st changes in op=Enabled
It was described in [1] that the NM FSM failed to trigger the
S_NM_RUNNNG_CHG signal when locking/unlocking the TRX.
That's because current osmo-bts doesn't fully conform to TS 52.021 and
it doesn't go back to Op=Disabled Avail=Dependency when becoming
Admin=Locked. It's true though that TS 52.021 sec 5.3.1 is not really
helpful since it doesn't explicitly state that specific object should go
into Disabled Dependency, despite saying it for most of the other ones.
Hence, let's account for both possibilities at the BSC side.
[1] https://gerrit.osmocom.org/c/osmo-bsc/+/28205
Related: OS#5576
Change-Id: Ifbdc066fd88bdbf826800d14524e74416815b625
| -rw-r--r-- | src/osmo-bsc/nm_rcarrier_fsm.c | 21 |
1 files changed, 20 insertions, 1 deletions
diff --git a/src/osmo-bsc/nm_rcarrier_fsm.c b/src/osmo-bsc/nm_rcarrier_fsm.c index fbd31799a..c8b95ade9 100644 --- a/src/osmo-bsc/nm_rcarrier_fsm.c +++ b/src/osmo-bsc/nm_rcarrier_fsm.c @@ -250,8 +250,27 @@ static void st_op_enabled(struct osmo_fsm_inst *fi, uint32_t event, void *data) case NM_EV_STATE_CHG_REP: nsd = (struct nm_statechg_signal_data *)data; new_state = &nsd->new_state; - if (new_state->operational == NM_OPSTATE_ENABLED) + /* Op state stays in Enabled, hence either Avail or Admin changed: */ + if (new_state->operational == NM_OPSTATE_ENABLED) { + /* Some sort of availability change we don't care about: */ + if (nsd->old_state.administrative == new_state->administrative) + return; + /* HACK: Admin state change without Op state change: + * According to TS 52.021 sec 5.3.1, Locking the NM obj should make + * it go into Disabled Dependency state, but current and older + * versions of osmo-bts (and potentially nanobts?) don't move from + * Operative=Enabled state and only change the Adminsitrative one. + * Let's account for this behavior here: */ + switch (new_state->administrative) { + case NM_STATE_LOCKED: + nm_rcarrier_fsm_becomes_disabled(trx); + break; + case NM_STATE_UNLOCKED: + nm_rcarrier_fsm_becomes_enabled(trx); + break; + } return; + } switch (new_state->availability) { /* operational = DISABLED */ case NM_AVSTATE_NOT_INSTALLED: case NM_AVSTATE_POWER_OFF: |