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/.
Pierre Kim admin at manateeshome.comHello, I created a redmine issue here: https://osmocom.org/issues/3707 And the BTS used to work with osmo-nitb before the split, I remember setting it up about a year and half ago. I connected it to softBSC just to make sure that it wasn't a hardware problem. Regards. Pierre On 2018-11-26 오후 7:34, Pau Espin Pedrol wrote: > 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 >