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?
One possible workaround (unless we find 1-way-fits-all technical interpretation of a spec) would be to use notion of major vs. minor releases.
We can guarantee backward compatibility within major releases (any osmo-bts 1.x.y works with any osmo-bsc 1.a.b) but not between them (osmo-bts 1.x.y might not work with osmo-bsc 2.m.n).
On a related note, we can follow the same principle with our libraries: any minor libosmocore 1.k.l. release preserve backward compatibility while moving to libosmocore 2.q.w. might require some porting efforts.
That would match general expectations set by other free software projects like GTK for example - nobody expects application written for GTK2.x to work effortlessly with GTK3.y
On Thu, Feb 14, 2019 at 10:22:21AM +0100, Max wrote:
That would match general expectations set by other free software projects like GTK for example - nobody expects application written for GTK2.x to work effortlessly with GTK3.y
Yes, but such a compatibility break always brings a lot of overhead and a split of the user base, as we have seen with the osmo-nitb split. The community is infinitely slow in taking on the newer incompatible version.
The aim should be to remain compatible.
~N
Hi.
15.02.19 20:03, Neels Hofmeyr пишет:
Yes, but such a compatibility break always brings a lot of overhead and a split of the user base, as we have seen with the osmo-nitb split. The community is infinitely slow in taking on the newer incompatible version.
I don't think it's fair comparison: nitb split require users to update pretty much everything at once, including updating config files etc. Of course it's "a lot of overhead" - it requires manual human labor.
It's a different story when user have to update one or two programs, without changing config files. That happens automatically all the time on pretty much daily basis.
Yes, we should try to be backward compatible whenever possible. Doesn't mean we can't consider introducing incompatible changes if it's really necessary.
On Wed, Feb 13, 2019 at 02:20:40PM +0100, Harald Welte wrote:
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.
If we want newer OsmoBTS to enforce a specific order of messages:
Introduce a legacy non-compat config option, sort of like that vi "set nocompatible". In the lack of any config, osmo-bts ignores OPSTARTs that came too early. IIUC a second opstart will follow?
As new example config, we ship with an option like "oml strict", which then rejects OPSTARTs that came too early, instead of just ignoring.
OTOH, if ignoring too early OPSTARTs works for both old and new osmo-bsc, we might not even need to be strict about it at all?
If anyone out there is using osmo-bts with a BSC that only sends an early OPSTART, then this idea of ignorng early OPSTART would break that setup, I guess.
~N
-
Harald Welte -
Max -
Neels Hofmeyr