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