nanoBTS fails to start with osmo-bsc

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Pau Espin Pedrol pespin at sysmocom.de
Mon Nov 26 10:34:39 UTC 2018


Hi,

First of all, can you please create a ticket with all the information, 
link it to #3063 and also provide a full log of osmo-bsc with "logging 
level set-all debug" together with a pcap file and bsc.cfg.


> With the newest git repo version of osmo-bsc, my nanoBTS fails to start.
> 

Was it recently working for you with up to date osmocom? Or never got it 
to work?

> I can confirm that they work normally with ip.access softBSC.

Would be nice if you could provice a pcap file while using it to see the 
differences.

> 
> 
> I thought osmocom Redmine issue #3063 might be relevant and tried
> setting/unsetting force-combined-si but I am still getting the same
> result. Attached are the packet capture and bsc config file
> 
> The following is the log from osmo-bsc:
> 
> <0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port 3002
> <0004> abis_nm.c:847 OC=BTS(01) INST=(ff,ff,ff): GET ATTRIBUTE NACK
> <0004> osmo_bsc_main.c:178 BTS0 does not support Get Attributes OML message.
> <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0:
> ARI reported sw[0/5]: 168a004 is v136d0
> <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0:
> ARI reported sw[1/5]: 168a002 is v136d0
> <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0:
> ARI reported sw[2/5]: 168a002 is v136d0
> <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0:
> ARI reported sw[3/5]: 168a001 is v136d0
> <0004> abis_nm.c:560 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff): BTS0:
> ARI reported sw[4/5]: 168a001 is v136d0
> <0004> abis_nm.c:494 BTS0 Attribute Manufacturer Dependent State is
> unreported

That looks fine I think. Get attributes fails at BTS level but then it 
asks at transceiver level and it gets the information. The initial 
failure is not important.

> <0004> abis_nm.c:2888 (bts=0,trx=0) IPA RSL CONNECT IP=0.0.0.0 PORT=3003
> STREAM=0x00
> <0015> input/ipa.c:262 accept()ed new link from 192.168.27.40 to port 3003
> <0003> osmo_bsc_main.c:283 bootstrapping RSL for BTS/TRX (0/0) on ARFCN
> 600 using MCC-MNC 450-09 LAC=23 CID=0 BSIC=63
> BTS 0: Failure Event Report: Type=processing failure, Severity=critical
> failure, Probable cause=Manufacturer specific values: Fatal software
> error, Additional Text=l2_bch.c:1149
> ****
> ** l2_bch.c#1149:BCHbcchSItypeValid( prim_p->infoType )
> ** IPA_SW_FATAL_ERROR
> ** In task "TRX Proc:L2_BCH" @ (325).
> ****
> 

Looks like the BTS doesn't like some type of SI we are sending to it. A 
fulldebug log of osmo-bsc.cfg would help. I'm right now trying to find 
in the pcap file were the SI info is sent.

BTW, try using following setup, it's the one I did test with. Tell me if 
you see any change:
    timeslot 0
     phys_chan_config CCCH+SDCCH4
     hopping enabled 0
    timeslot 1
     phys_chan_config TCH/F
     hopping enabled 0
    timeslot 2
     phys_chan_config TCH/F
     hopping enabled 0
    timeslot 3
     phys_chan_config TCH/F
     hopping enabled 0
    timeslot 4
     phys_chan_config TCH/F
     hopping enabled 0
    timeslot 5
     phys_chan_config TCH/F
     hopping enabled 0
    timeslot 6
     phys_chan_config PDCH
     hopping enabled 0
    timeslot 7
     phys_chan_config PDCH
     hopping enabled 0

Regards,
Pau

-- 
- Pau Espin Pedrol <pespin at sysmocom.de>         http://www.sysmocom.de/
=======================================================================
* sysmocom - systems for mobile communications GmbH
* Alt-Moabit 93
* 10559 Berlin, Germany
* Sitz / Registered office: Berlin, HRB 134158 B
* Geschaeftsfuehrer / Managing Director: Harald Welte



More information about the OpenBSC mailing list