Project

General

Profile

Actions

Bug #3789

open

BTS permits OPSTART of MO without attributes

Added by laforge almost 3 years ago. Updated about 2 months ago.

Status:
Stalled
Priority:
Normal
Assignee:
Category:
Abis
Target version:
-
Start date:
02/07/2019
Due date:
% Done:

80%

Spec Reference:

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.


Files


Related issues

Related to OsmoBTS - Bug #3782: OML bringup fails for osmo-bts-oc2g on high latency linksNew02/06/2019

Actions
Related to OsmoBTS - Feature #2469: Proper OML MO (managed object) using osmo_fsmResolvedpespin08/29/2017

Actions
Actions #1

Updated by laforge almost 3 years ago

  • Related to Bug #3782: OML bringup fails for osmo-bts-oc2g on high latency links added
Actions #2

Updated by laforge almost 3 years ago

  • Related to Feature #2469: Proper OML MO (managed object) using osmo_fsm added
Actions #3

Updated by laforge almost 3 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 40
Actions #4

Updated by laforge almost 3 years ago

  • % Done changed from 40 to 70
Actions #5

Updated by laforge almost 3 years ago

The problem with the patch is on the OsmoBSC side. It seems there are two code paths that lead to the RADIO_CARRIER MO to be OPSTARTed:
  1. if the state changes to OPSTATE_DISABLED + AVSTATE_OK. Here we only try to OPSTART without ever setting attributes or changing admin state before.
  2. 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.

Actions #6

Updated by laforge almost 3 years 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?

Actions #7

Updated by laforge almost 3 years ago

  • % Done changed from 70 to 80

laforge wrote:

  1. 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.

Actions #9

Updated by laforge almost 3 years ago

The underliyng fundamental question remains:

Sshould setting the attributes and subsequent opstart depend on
  1. a software activated report (like done for NM_OC_BASEB_TRANSC and NM_OC_RADIO_CARRIER), or
  2. 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.

Actions #10

Updated by laforge almost 3 years ago

  • Status changed from In Progress to Stalled
Actions #11

Updated by laforge about 1 year ago

  • Assignee changed from laforge to pespin
Actions #12

Updated by laforge about 1 year ago

Actions #13

Updated by pespin about 2 months ago

Update current status after all OML FSM work which has been done in bsc and bts:

osmo-bsc:

According to TS 12.21 (a bit vague regarding this and other topics), SetAttrs must be set BEFORE unlocking the Managed Object (or at least at around same time):

[In Figure 2/GSM 12.21]:
Object doesn't have correct attribute values yet. They will be received when the unlock procedure is executed.

Furthermore, unlocking must be done BEFORE opstarting a Managed Object. Hence, the following steps must be done in this order by osmo-bsc: "SetAttr, Unlock, Opstart". osmo-bsc is already doing this properly in general AFAICT: see configure_loop() in nm_*_fsm.c in osmo-bsc.git.

osmo-bts:

Right now the OML FSMs in osmo-bts are not as further evolved as those in osmo-bsc, mainly because they have to interact with backend specific code/layers. Hence, right now, OML/RSL received messages trigger directly lower layers (l1) which will eventually ACK/NACK sending a related event to the OML NM FSMs (common code). We are right now tracking whether SetAttributes was already received or not, however since we only run code there when the OPSTART ACK/NACK is received from lower layers, it's too late to do verifications. We should instead change the paths to go OML->NM_FSM->L1 (ACK/NACK). This way, before calling L1 (bts_model) we could actually verify if SetAttr was already received or not and hence send a OPSTART NACK.
So far, we simply rely on osmo-bsc doing stuff properly (it should nowadays).

So in summary, we should improve osmo-bts to check this kind of stuff, but it will probably require a fair amount of refactoring to have the OML->NM_FSM->L1 path implemented for SetAttr and Opstart.

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)