Cellular Network Infrastructure » Radio Access Network » OsmoBTS

I don't observe this behaviour with osmo-bts-sysmo from the 201705 distribution.

I compiled osmo-bts-sysmo latest tag (version 0.7.0) against current master libosmocore and the behaviour existed there.

I tried to go back and compile from 69ec4a419e (which is the version in 201705 ?) but currently running into problems with the dependency on gsm_shared_data.h from openbsc, which presumably is not going to work with current libosmocore master.

make[2]: Entering directory '/home/keith/src/sysmoBTS/osmo-bts/src/common'
  CC       gsm_data_shared.o
In file included from gsm_data_shared.c:1:0:
../../../openbsc/openbsc/src/libcommon/gsm_data_shared.c:38:41: error: array type has incomplete element type ‘struct osmo_stat_item_desc’
 static const struct osmo_stat_item_desc bts_stat_desc[] = {
                                         ^~~~~~~~~~~~~
../../../openbsc/openbsc/src/libcommon/gsm_data_shared.c:40:75: error: ‘GSM_T3122_DEFAULT’ undeclared here (not in a function)
  { "T3122", "T3122 IMMEDIATE ASSIGNMENT REJECT wait indicator.", "s", 16, GSM_T3122_DEFAULT },

etc...

Notes:

8aa85bd31abadedf69947250188795fad598dedd is good
 0f7bcb5f17f18682f7f9dc41e2d0fc73c4c08318 is good.

6cb9e7d8981e127161f14f22ad9271252c531aec is bad.
 f2e83ad40d231e87e2604ec4c97c810a8182e145 would appear to be what introduces this.

Since that other libosmocore patch was my doing, I took a look at this failure, found out this:
The Abort cause is actually the deferred CTRL command. The sysmobts clock commands seem to be the only implementations of deferred ctrl command.

Attached patch adds a dummy deferred ctrl command to the common vty part of osmo-bts, so it's convenient for testing that in osmo-bts-virtual (without an actual BTS hardware). Start a BSC the osmo-bts-virtual can connect to, then trigger the failure by:

▶ osmo_interact_ctrl.py -p 4238
GET 0 test-defer

Now going to find out how on earth that patch of mine broke deferred ctrl commands.

actually attaching patch...

Actually it was not above mentioned change that introduced the failure,
instead it was https://cgit.osmocom.org/libosmocore/commit/?id=f2c10f108202c350a3c16f49156b11b0cd0dfa96
-- it looked like just fixing an obvious memory leak, which it did as shown by the unit test, but deferred ctrl commands relied on that leak.

Leave the leak fixed but also support deferred ctrl commands: https://gerrit.osmocom.org/7618

Enabled ttcn3 BTS_Tests to be able to test CTRL interaction https://gerrit.osmocom.org/7621 https://gerrit.osmocom.org/7622, but of course the deferred clock-info command only exists in osmo-bts-sysmo, and we're only testing osmo-bts-trx in ttcn3.

There's a stub for sending the ctrl command here https://git.osmocom.org/osmo-ttcn3-hacks/commit/?h=neels/wip&id=4cc2374bdae26e2b2a002c941213f91fe745cc50 but it's so far useless.

laforge suggested to create some useful deferred command for osmo-bts-trx, e.g. "something that triggers a trx-control (ASCCI/UDP) protocol transaction and returns it via osmocom-ctrl? like the gain settings", and then test that in ttcn3.

An alternative is to test deferred ctrl interface in libosmocore, which is also a tricky decision, since we do no python tests in libosmocore yet, AFAIK. Not sure if we want to add that to libosmocore at all.

So while the fix is ready to be merged, testing against regression is TBD.

neels wrote:

An alternative is to test deferred ctrl interface in libosmocore, which is also a tricky decision, since we do no python tests in libosmocore yet, AFAIK. Not sure if we want to add that to libosmocore at all.

could of course cook up a C test without external communication, should be simple enough.

test https://gerrit.osmocom.org/7636
fix https://gerrit.osmocom.org/7618
all merged