Bug #3789
BTS permits OPSTART of MO without attributes
80%
Description
After writing some OML testcases, I discovered that it's currently possible to OPSTART a Managed Object which doesn't yet have all of its attributes set. This is a likely cause of OML initialization failures, and should be NACKed.
As per TS 12.21 Figure 2, the Attribute setting happens before OPSTART. The OPSTART then attempts to put the object into the ENABLED operational state.
Related issues
History
#1 Updated by laforge about 1 month ago
- Related to Bug #3782: OML bringup fails for osmo-bts-oc2g on high latency links added
#2 Updated by laforge about 1 month ago
- Related to Feature #2469: Proper OML MO (managed object) using osmo_fsm added
#3 Updated by laforge about 1 month ago
- Status changed from New to In Progress
- % Done changed from 0 to 40
#4 Updated by laforge about 1 month ago
- % Done changed from 40 to 70
#5 Updated by laforge about 1 month ago
- if the state changes to OPSTATE_DISABLED + AVSTATE_OK. Here we only try to OPSTART without ever setting attributes or changing admin state before.
- if there's a a SW ACTIVATE REPORT. Here we also set the attributes and change admin state
Now the problem is that if we reject the OPSTART without having all relevant attributes set, then "1" above will fail. Only "2" will succeed. Unfortuantely the normal OsmoBSC bring-up will transition through "1" before going through "2".
So we either have to make OsmoBTS survive any such NACKs (which is probably a sane choice these days, we don't need to terminate the process just because something was NACKed), or teach OsmoBSC to not OPSTART twice.
#6 Updated by laforge about 1 month ago
I've just played with a nanoBTS. Confusingly, it also ACKs an OPSTART to a RADIO CARRIER MO that has no software installed nor any attributes set :(
So their implementation is also not really any better than ours in terms of a proper state machine?
#7 Updated by laforge about 1 month ago
- % Done changed from 70 to 80
laforge wrote:
- if the state changes to OPSTATE_DISABLED + AVSTATE_OK. Here we only try to OPSTART without ever setting attributes or changing admin state before.
If I deactivate this, it seems we can still successfully start a nanoBTS 165AU as well as a sysmobts 0.8.1+git29+bf87717cc8-r0.18.0. So I guess it's safe to remove this part. Will try to dig a bit further in the openbsc.git history.
#8 Updated by laforge about 1 month ago
- File osmobsc-os3789-dont_opstart_on_disabled_ok.patch osmobsc-os3789-dont_opstart_on_disabled_ok.patch added
attaching the patch I used for testing
#9 Updated by laforge about 1 month ago
The underliyng fundamental question remains:
Sshould setting the attributes and subsequent opstart depend on- a software activated report (like done for NM_OC_BASEB_TRANSC and NM_OC_RADIO_CARRIER), or
- a state changed event report (like for SITE_MANAGER, BTS, CHANNEL, NSE, CELL, NSVC)
RADIO_CARRIER is the only MO that's trying to do both, which is creating the problem here.
