OML bringup bugs and compatibility

[Harald Welte]

Dear Osmocom community,

It has recently been uncovered that there are some problems in the OML bringup
sequence between OsmoBSC and OsmoBTS.

Basically, the core of the issue circulates around the RADIO CARRIER managed object.
* OsmoBTS is accepting OPSTART even though no attributes (such as ARFCN) are set
* OsmoBSC is sending OPSTART twice for this MO, while it's only sending it once
  for all other MOs

The problem now is: If we "fix" the BTS side to reject the OPSTART without
prior SET RADIO CARRIER ATTRIBUTES, then older OsmoBSC will stop to work with
newer OsmoBTS.

The underlying issue is that if we OPSTART the transceiver before setting the ARFCN,
then the later setting of attributes is no longer going to do anything, as the radio
has already started with "ARFCN 0".

TS 12.21 is not very clear on *when* attributes are permitted to be set.
The MO can be either locked or unlocked, or it can be enabled or not...
My idea so far was that if you want to change attributes of a MO (such
as the ARFCN), you need to first bring it down somehow (e.g. set it to
"locked"), then make the change and finally bring it online again.

A bit of playing with a nanoBTS revealed that it actually permits the
OPSTART not only before the attributes are set, but also before the
software has even been activated for that MO.  This makes no sense
whatsoever, though.

More details in: https://osmocom.org/issues/3789 and https://osmocom.org/issues/3782,
particularly the last few updates to those tickets.

Any ideas?

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)