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