Lack of maintenance for osmo-bts-trx

Harald Welte laforge at
Wed Apr 6 07:59:11 UTC 2016

Hi Tom,

On Wed, Apr 06, 2016 at 12:01:05AM -0700, Tom Tsou wrote:
> I suspect that there were issues since the beginning of the merge. The
> issue that I saw with master was reported by Sipos Csaba back in Nov
> 2015.
> I guess there is something wrong with the OML setup since
> trx->mo.nm_state is reporting NM_OPSTATE_NULL during the post-RACH
> channel allocation, but I am not familiar enough with those procedures
> to debug more.

The lack of proper OML MO state machines on both sides of the A-bis OML
link doesn't make it easier either, I know :/

I'm not quite sure how that relates to the bug report above, which
indicates a problem in the UDP-based osmo-trx/osmo-bts-trx control
interface about setting the BSIC.  I would assume that this is the root
cause, which only elevates towards e.g. a MO state not changing as it
normally should.

> I can provide a supporting role in the above tasks on behalf of Ettus


> but we do need a working starting point - that makes number 4 the most
> critical item. Unfortunately, I am not able to resolve the patch
> differences (I painfully tried) to make master the main user branch. I
> agree that directing users to the Fairwaves branch is the wrong
> approach, but right now it is the only branch for osmo-bts-trx that
> works.

Can you or somebody else interested in getting this resolved provide a
full bug report, including
* debug log output on OsmoNITB side for for the rsl and nm
* debug log output on OsmoBTS side for oml / transceiver interface or
  anything else related
* pcap file of A-bis traffic between OsmoBTS and OsmoNITB, as well as
  the control commands between osmo-bts-trx and osmo-trx

The above is what to me seems like the "obvious" way to report a bug in
order for other developers on this list to try to figure out what is
causing the problem.   Maybe it's not as obvious to others and we should
put together some guidelines in the wiki on this?

In any case, I don't recall seeing a comprehensive report like this on
the list yet.  If I missed it, my apologies.

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

More information about the OpenBSC mailing list