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