Project

General

Profile

Bug #3120

osmo-bts aborts on GET trx.0.clock-info on CTRL interface

Added by keith over 1 year ago. Updated over 1 year ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
03/28/2018
Due date:
% Done:

100%

Spec Reference:

Description

I noticed this as the sysmobts-mgr attempts to calibrate the 2050 clock crashes the BTS every time.

Reproduced with current master on sysmoBTS 1002:

$ python ./bsc_control.py -d 192.168.11.190 -p 4238 -g trx.0.clock-info

RESULT:

<0006> ../../../git/src/osmo-bts-sysmo/l1_if.c:184 Tx SYS prim RF-CLOCK-INFO.req
<0006> ../../../git/src/osmo-bts-sysmo/sysmobts_ctrl.c:67 RfClockInfo iClkCor=529/clkSrc=ocxo Err=0/ErrRes=0/clkSrc=None
Aborted (core dumped)

History

#1 Updated by keith over 1 year ago

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...

#2 Updated by keith over 1 year ago

Notes:

8aa85bd31abadedf69947250188795fad598dedd is good
0f7bcb5f17f18682f7f9dc41e2d0fc73c4c08318 is good.
6cb9e7d8981e127161f14f22ad9271252c531aec is bad.
f2e83ad40d231e87e2604ec4c97c810a8182e145 would appear to be what introduces this.

#3 Updated by neels over 1 year ago

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.

#5 Updated by laforge over 1 year ago

for the record: we definitely want a test case for this in the ttcn3 test suite. If
it's all about sending one specific ctrl command, it should be rather easy.

#6 Updated by neels over 1 year ago

  • Status changed from New to In Progress
  • Assignee set to neels
  • % Done changed from 0 to 80

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

#7 Updated by neels over 1 year ago

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.

#8 Updated by neels over 1 year ago

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.

#9 Updated by neels over 1 year ago

  • Status changed from In Progress to Resolved
  • % Done changed from 80 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)