From abdulghafar1412 at gmail.com Fri Sep 2 14:18:30 2016 From: abdulghafar1412 at gmail.com (Abdulghafar Shabaneh) Date: Fri, 2 Sep 2016 15:18:30 +0100 Subject: chan_alloc.c help Message-ID: Hi Neels and everyone in the list, Thanks for your help in installing OpenBSc on my Raspberry Pi :) It was as you said that I should delete it and build from scratch. The prefix command fixed the issue as well ./configure --prefix=/usr .. I was unable to install lcr due to an error: Makefile:1306: recipe for target 'chan_lcr.po' failed I don't know if that will fix the problem, though, its optional, and osmo-nitb should do the job by it self. Now I ran the osmo-nitb, osmo-bts-trx and osmo-trx all together with the USRP2 with FLEX900 daughter board GSM900 band, it all works well except the mobile is not able to register on the network. osmo-nitb shows this error: (towards the end) my file >trybsc.cfg contains this: ! password foo ! line vty no login ! e1_input e1_line 0 driver ipa network network country code 416 mobile network code 77 short name GSMab long name GSMab auth policy accept-all location updating reject cause 13 encryption a5 0 neci 1 paging any use tch 0 rrlp mode none mm info 1 handover 0 handover window rxlev averaging 10 handover window rxqual averaging 1 handover window rxlev neighbor averaging 10 handover power budget interval 6 handover power budget hysteresis 3 handover maximum distance 9999 timer t3101 10 timer t3103 0 timer t3105 0 timer t3107 0 timer t3109 0 timer t3111 0 timer t3113 60 timer t3115 0 timer t3117 0 timer t3119 0 timer t3122 10 timer t3141 0 dtx-used 0 subscriber-keep-in-ram 0 bts 0 type sysmobts band GSM900 cell_identity 0 location_area_code 1 training_sequence_code 7 base_station_id_code 63 ms max power 0 cell reselection hysteresis 4 rxlev access min 0 periodic location update 30 channel allocator descending rach tx integer 9 rach max transmission 7 ! channel-descrption attach 1 ! channel-descrption bs-pa-mfrms 5 ! channel-descrption bs-ag-blks-res 1 ip.access unit_id 1801 0 oml ip.access stream_id 255 line 0 neighbor-list mode automatic trx 0 rf_locked 0 arfcn 100 nominal power 0 max_power_red 0 rsl e1 tei 0 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 TCH/F hopping enabled 0 timeslot 7 phys_chan_config TCH/F hopping enabled 0 pi at dwarfabd:~ $ sudo osmo-nitb -c ~/trybsc.cfg -l hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM <0005> bsc_init.c:498 VTY at 127.0.0.1 4242 <0005> bsc_init.c:427 WARNING: You are running an 'accept-all' network on a BTS that is not barred. This configuration is likely to interfere with production GSM networks and should only be used in a RF shielded environment such as a faraday cage! <0005> bsc_hack.c:318 CTRL at 127.0.0.1 4249 DB: Database initialized. DB: Database prepared. <0005> abis_nm.c:316 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:1768 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART <0005> abis_nm.c:316 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) <0005> abis_nm.c:1449 Set BTS Attr (bts=0) <0005> abis_nm.c:1768 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART <0005> abis_nm.c:316 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) <0005> abis_nm.c:316 OC=GPRS-CELL(f1) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) <0005> abis_nm.c:316 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) <0005> abis_nm.c:316 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) <0005> abis_nm.c:316 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) <0005> abis_nm.c:316 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) <0005> abis_nm.c:1768 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:316 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=OK(ff) <0005> abis_nm.c:316 OC=RADIO-CARRIER(02) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:1466 Set TRX Attr (bts=0,trx=0) <0005> abis_nm.c:1768 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:316 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report <0005> abis_nm.c:1768 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Sending OPSTART <0005> abis_nm.c:2587 ip.access RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=0) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=1) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=2) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,02) Sending OPSTART <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=3) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,03) Sending OPSTART <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=4) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,04) Sending OPSTART <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=5) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,05) Sending OPSTART <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=6) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,06) Sending OPSTART <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=7) <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,07) Sending OPSTART <0005> abis_nm.c:316 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:2429 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xe1): RSL CONNECT ACK <0004> bsc_init.c:287 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 100 using MCC=416 MNC=77 LAC=1 CID=0 BSIC=63 <0003> system_information.c:525 Serving cell: 100 <0003> bsc_init.c:104 SI1: 55 06 19 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 e5 04 00 2b <0003> bsc_init.c:104 SI2: 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00 <0003> bsc_init.c:104 SI3: 49 06 1b 00 00 14 f6 77 00 01 49 03 05 27 53 40 e5 04 00 39 2b 2b 2b <0003> bsc_init.c:104 SI4: 31 06 1c 14 f6 77 00 01 53 40 e5 04 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0003> bsc_init.c:104 SI5: 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b <0003> bsc_init.c:104 SI6: 2d 06 1e 00 00 14 f6 77 00 01 27 ff 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) <0000> chan_alloc.c:367 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH <0004> abis_rsl.c:1705 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(100) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0b ta=3 <0004> abis_rsl.c:539 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1434 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0000> chan_alloc.c:367 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=1 as SDCCH <0004> abis_rsl.c:1705 (bts=0,trx=0,ts=0,ss=1) Activating ARFCN(100) SS(1) lctype SDCCH r=OTHER ra=0x1f ta=2 <0004> abis_rsl.c:539 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=1) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1434 (bts=0,trx=0,ts=0,ss=1) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=1) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:772 (bts=0,trx=0,ts=0,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:721 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:830 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:736 (bts=0,trx=0,ts=0,ss=0) is back in operation. <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE <0004> abis_rsl.c:772 (bts=0,trx=0,ts=0,ss=1) RF Channel Release CMD due error 1 <0004> abis_rsl.c:721 (bts=0,trx=0,ts=0,ss=1) DEACTivate SACCH CMD <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=1) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:830 (bts=0,trx=0,ts=0,ss=1) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:736 (bts=0,trx=0,ts=0,ss=1) is back in operation. <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=1) state RELEASE DUE ERROR -> NONE <0000> chan_alloc.c:367 (bts=0,trx=0,ts=7,pchan=TCH/F) Allocating lchan=0 as TCH_F <0004> abis_rsl.c:1705 (bts=0,trx=0,ts=7,ss=0) Activating ARFCN(100) SS(0) lctype TCH_F r=PAGING ra=0x37 ta=0 <0004> abis_rsl.c:539 (bts=0,trx=0,ts=7,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1434 (bts=0,trx=0,ts=7,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:772 (bts=0,trx=0,ts=7,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:721 (bts=0,trx=0,ts=7,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:830 (bts=0,trx=0,ts=7,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:736 (bts=0,trx=0,ts=7,ss=0) is back in operation. <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state RELEASE DUE ERROR -> NONE <0000> chan_alloc.c:367 (bts=0,trx=0,ts=7,pchan=TCH/F) Allocating lchan=0 as TCH_F <0004> abis_rsl.c:1705 (bts=0,trx=0,ts=7,ss=0) Activating ARFCN(100) SS(0) lctype TCH_F r=CALL ra=0xc4 ta=5 <0004> abis_rsl.c:539 (bts=0,trx=0,ts=7,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1434 (bts=0,trx=0,ts=7,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:772 (bts=0,trx=0,ts=7,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:721 (bts=0,trx=0,ts=7,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:830 (bts=0,trx=0,ts=7,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:736 (bts=0,trx=0,ts=7,ss=0) is back in operation. <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state RELEASE DUE ERROR -> NONE <0000> chan_alloc.c:367 (bts=0,trx=0,ts=7,pchan=TCH/F) Allocating lchan=0 as TCH_F <0004> abis_rsl.c:1705 (bts=0,trx=0,ts=7,ss=0) Activating ARFCN(100) SS(0) lctype TCH_F r=OTHER ra=0x51 ta=1 <0004> abis_rsl.c:539 (bts=0,trx=0,ts=7,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1434 (bts=0,trx=0,ts=7,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:772 (bts=0,trx=0,ts=7,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:721 (bts=0,trx=0,ts=7,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:830 (bts=0,trx=0,ts=7,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:736 (bts=0,trx=0,ts=7,ss=0) is back in operation. <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state RELEASE DUE ERROR -> NONE ************************************************************************************************************************************************ ************************************************************************************************************************************************ Part of osmo-bts-trx output: :375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1611408 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1611412 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1611412 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00 fn=1611449 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=1611449 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1611453 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1611453 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1611459 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1611459 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1611463 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1611463 ts=0 trx=0 9 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613809 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00 fn=1613846 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=1613846 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613850 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613850 ts=0 trx=0 7 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616247 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1616253 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616253 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1616257 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616257 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00 fn=1616294 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=1616294 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1616298 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616298 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1616304 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616304 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1616308 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616308 ts=0 trx=0 <0006> scheduler_trx.c:1517 GSM clock jitter: -2556 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613856 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613856 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613860 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613860 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00 fn=1613897 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=1613897 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613901 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613901 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613907 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613907 ts=0 trx=0 <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613911 ts=0 trx=0 <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613911 ts=0 trx=0 Thanks Abdulghafar -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.0jacob0 at gmail.com Sat Sep 3 08:15:36 2016 From: sami.0jacob0 at gmail.com (sami) Date: Sat, 3 Sep 2016 11:15:36 +0300 Subject: chan_alloc.c help In-Reply-To: References: Message-ID: <7F5EA366-6552-4C6F-A703-03C1114254B1@gmail.com> Hi, What version of UHD are you using ? I would suggest using version 3.7 or 3.8. Best regards, Robert, On Sep 2, 2016, at 5:18 PM, Abdulghafar Shabaneh wrote: > Hi Neels and everyone in the list, > > Thanks for your help in installing OpenBSc on my Raspberry Pi :) > It was as you said that I should delete it and build from scratch. > The prefix command fixed the issue as well > ./configure --prefix=/usr .. > > I was unable to install lcr due to an error: > Makefile:1306: recipe for target 'chan_lcr.po' failed > I don't know if that will fix the problem, though, its optional, and osmo-nitb should do the job by it self. > > Now I ran the osmo-nitb, osmo-bts-trx and osmo-trx all together with the USRP2 with FLEX900 daughter board GSM900 band, it all works well except the mobile is not able to register on the network. osmo-nitb shows this error: (towards the end) > > my file >trybsc.cfg contains this: > ! password foo > ! > line vty > no login > ! > e1_input > e1_line 0 driver ipa > network > network country code 416 > mobile network code 77 > short name GSMab > long name GSMab > auth policy accept-all > location updating reject cause 13 > encryption a5 0 > neci 1 > paging any use tch 0 > rrlp mode none > mm info 1 > handover 0 > handover window rxlev averaging 10 > handover window rxqual averaging 1 > handover window rxlev neighbor averaging 10 > handover power budget interval 6 > handover power budget hysteresis 3 > handover maximum distance 9999 > timer t3101 10 > timer t3103 0 > timer t3105 0 > timer t3107 0 > timer t3109 0 > timer t3111 0 > timer t3113 60 > timer t3115 0 > timer t3117 0 > timer t3119 0 > timer t3122 10 > timer t3141 0 > dtx-used 0 > subscriber-keep-in-ram 0 > bts 0 > type sysmobts > band GSM900 > cell_identity 0 > location_area_code 1 > training_sequence_code 7 > base_station_id_code 63 > ms max power 0 > cell reselection hysteresis 4 > rxlev access min 0 > periodic location update 30 > channel allocator descending > rach tx integer 9 > rach max transmission 7 > ! channel-descrption attach 1 > ! channel-descrption bs-pa-mfrms 5 > ! channel-descrption bs-ag-blks-res 1 > ip.access unit_id 1801 0 > oml ip.access stream_id 255 line 0 > neighbor-list mode automatic > trx 0 > rf_locked 0 > arfcn 100 > nominal power 0 > max_power_red 0 > rsl e1 tei 0 > 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 TCH/F > hopping enabled 0 > timeslot 7 > phys_chan_config TCH/F > hopping enabled 0 > > pi at dwarfabd:~ $ sudo osmo-nitb -c ~/trybsc.cfg -l hlr.sqlite3 -P -C --debug=DRLL:DCC:DMM:DRR:DRSL:DNM > <0005> bsc_init.c:498 VTY at 127.0.0.1 4242 > <0005> bsc_init.c:427 > WARNING: You are running an 'accept-all' network on a BTS that is not barred. This configuration is likely to interfere with production GSM networks and should only be used in a RF shielded environment such as a faraday cage! > > <0005> bsc_hack.c:318 CTRL at 127.0.0.1 4249 > DB: Database initialized. > DB: Database prepared. > <0005> abis_nm.c:316 OC=SITE-MANAGER(00) INST=(ff,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:1768 OC=SITE-MANAGER(00) INST=(ff,ff,ff) Sending OPSTART > <0005> abis_nm.c:316 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) > <0005> abis_nm.c:1449 Set BTS Attr (bts=0) > <0005> abis_nm.c:1768 OC=BTS(01) INST=(00,ff,ff) Sending OPSTART > <0005> abis_nm.c:316 OC=GPRS-NSE(f0) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) > <0005> abis_nm.c:316 OC=GPRS-CELL(f1) INST=(00,ff,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) > <0005> abis_nm.c:316 OC=GPRS-NSVC(f2) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Dependency(05) > <0005> abis_nm.c:316 OC=GPRS-NSVC(f2) INST=(00,01,ff) STATE CHG: OP_STATE=Disabled AVAIL=Off line(03) > <0005> abis_nm.c:316 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) > <0005> abis_nm.c:316 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=NULL AVAIL=Power off(02) > <0005> abis_nm.c:316 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Disabled AVAIL=OK(ff) > <0005> abis_nm.c:1768 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART > <0005> abis_nm.c:316 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=NULL AVAIL=OK(ff) > <0005> abis_nm.c:316 OC=RADIO-CARRIER(02) INST=(00,00,ff) Software Activated Report > <0005> abis_nm.c:1466 Set TRX Attr (bts=0,trx=0) > <0005> abis_nm.c:1768 OC=RADIO-CARRIER(02) INST=(00,00,ff) Sending OPSTART > <0005> abis_nm.c:316 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Software Activated Report > <0005> abis_nm.c:1768 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) Sending OPSTART > <0005> abis_nm.c:2587 ip.access RSL CONNECT IP=0.0.0.0 PORT=3003 STREAM=0x00 > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=0) > <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,00) Sending OPSTART > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=1) > <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,01) Sending OPSTART > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=2) > <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,02) Sending OPSTART > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=3) > <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,03) Sending OPSTART > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=4) > <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,04) Sending OPSTART > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=5) > <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,05) Sending OPSTART > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=6) > <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,06) Sending OPSTART > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Disabled AVAIL=Dependency(05) > <0005> abis_nm.c:1661 Set Chan Attr (bts=0,trx=0,ts=7) > <0005> abis_nm.c:1768 OC=CHANNEL(03) INST=(00,00,07) Sending OPSTART > <0005> abis_nm.c:316 OC=BTS(01) INST=(00,ff,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:316 OC=RADIO-CARRIER(02) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:316 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:2429 OC=BASEBAND-TRANSCEIVER(04) INST=(00,00,ff) IPACCESS(0xe1): RSL CONNECT ACK > <0004> bsc_init.c:287 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 100 using MCC=416 MNC=77 LAC=1 CID=0 BSIC=63 > <0003> system_information.c:525 Serving cell: 100 > <0003> bsc_init.c:104 SI1: 55 06 19 00 00 00 08 00 00 00 00 00 00 00 00 00 00 00 00 e5 04 00 2b > <0003> bsc_init.c:104 SI2: 59 06 1a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff e5 04 00 > <0003> bsc_init.c:104 SI3: 49 06 1b 00 00 14 f6 77 00 01 49 03 05 27 53 40 e5 04 00 39 2b 2b 2b > <0003> bsc_init.c:104 SI4: 31 06 1c 14 f6 77 00 01 53 40 e5 04 00 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b > <0003> bsc_init.c:104 SI5: 49 06 1d 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2b 2b 2b 2b > <0003> bsc_init.c:104 SI6: 2d 06 1e 00 00 14 f6 77 00 01 27 ff 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b 2b > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,00) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,01) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,02) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,03) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,04) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,05) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,06) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0005> abis_nm.c:316 OC=CHANNEL(03) INST=(00,00,07) STATE CHG: OP_STATE=Enabled AVAIL=OK(ff) > <0000> chan_alloc.c:367 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH > <0004> abis_rsl.c:1705 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(100) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0b ta=3 > <0004> abis_rsl.c:539 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED > <0004> abis_rsl.c:1434 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE > <0000> chan_alloc.c:367 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=1 as SDCCH > <0004> abis_rsl.c:1705 (bts=0,trx=0,ts=0,ss=1) Activating ARFCN(100) SS(1) lctype SDCCH r=OTHER ra=0x1f ta=2 > <0004> abis_rsl.c:539 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=1) state NONE -> ACTIVATION REQUESTED > <0004> abis_rsl.c:1434 (bts=0,trx=0,ts=0,ss=1) CHANNEL ACTIVATE ACK > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=1) state ACTIVATION REQUESTED -> ACTIVE > <0004> abis_rsl.c:772 (bts=0,trx=0,ts=0,ss=0) RF Channel Release CMD due error 1 > <0004> abis_rsl.c:721 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR > <0004> abis_rsl.c:830 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK > <0004> abis_rsl.c:736 (bts=0,trx=0,ts=0,ss=0) is back in operation. > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE > <0004> abis_rsl.c:772 (bts=0,trx=0,ts=0,ss=1) RF Channel Release CMD due error 1 > <0004> abis_rsl.c:721 (bts=0,trx=0,ts=0,ss=1) DEACTivate SACCH CMD > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=1) state ACTIVE -> RELEASE DUE ERROR > <0004> abis_rsl.c:830 (bts=0,trx=0,ts=0,ss=1) RF CHANNEL RELEASE ACK > <0004> abis_rsl.c:736 (bts=0,trx=0,ts=0,ss=1) is back in operation. > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=0,ss=1) state RELEASE DUE ERROR -> NONE > <0000> chan_alloc.c:367 (bts=0,trx=0,ts=7,pchan=TCH/F) Allocating lchan=0 as TCH_F > <0004> abis_rsl.c:1705 (bts=0,trx=0,ts=7,ss=0) Activating ARFCN(100) SS(0) lctype TCH_F r=PAGING ra=0x37 ta=0 > <0004> abis_rsl.c:539 (bts=0,trx=0,ts=7,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVATION REQUESTED > <0004> abis_rsl.c:1434 (bts=0,trx=0,ts=7,ss=0) CHANNEL ACTIVATE ACK > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVATION REQUESTED -> ACTIVE > <0004> abis_rsl.c:772 (bts=0,trx=0,ts=7,ss=0) RF Channel Release CMD due error 1 > <0004> abis_rsl.c:721 (bts=0,trx=0,ts=7,ss=0) DEACTivate SACCH CMD > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVE -> RELEASE DUE ERROR > <0004> abis_rsl.c:830 (bts=0,trx=0,ts=7,ss=0) RF CHANNEL RELEASE ACK > <0004> abis_rsl.c:736 (bts=0,trx=0,ts=7,ss=0) is back in operation. > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state RELEASE DUE ERROR -> NONE > <0000> chan_alloc.c:367 (bts=0,trx=0,ts=7,pchan=TCH/F) Allocating lchan=0 as TCH_F > <0004> abis_rsl.c:1705 (bts=0,trx=0,ts=7,ss=0) Activating ARFCN(100) SS(0) lctype TCH_F r=CALL ra=0xc4 ta=5 > <0004> abis_rsl.c:539 (bts=0,trx=0,ts=7,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVATION REQUESTED > <0004> abis_rsl.c:1434 (bts=0,trx=0,ts=7,ss=0) CHANNEL ACTIVATE ACK > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVATION REQUESTED -> ACTIVE > <0004> abis_rsl.c:772 (bts=0,trx=0,ts=7,ss=0) RF Channel Release CMD due error 1 > <0004> abis_rsl.c:721 (bts=0,trx=0,ts=7,ss=0) DEACTivate SACCH CMD > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVE -> RELEASE DUE ERROR > <0004> abis_rsl.c:830 (bts=0,trx=0,ts=7,ss=0) RF CHANNEL RELEASE ACK > <0004> abis_rsl.c:736 (bts=0,trx=0,ts=7,ss=0) is back in operation. > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state RELEASE DUE ERROR -> NONE > <0000> chan_alloc.c:367 (bts=0,trx=0,ts=7,pchan=TCH/F) Allocating lchan=0 as TCH_F > <0004> abis_rsl.c:1705 (bts=0,trx=0,ts=7,ss=0) Activating ARFCN(100) SS(0) lctype TCH_F r=OTHER ra=0x51 ta=1 > <0004> abis_rsl.c:539 (bts=0,trx=0,ts=7,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVATION REQUESTED > <0004> abis_rsl.c:1434 (bts=0,trx=0,ts=7,ss=0) CHANNEL ACTIVATE ACK > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVATION REQUESTED -> ACTIVE > <0004> abis_rsl.c:772 (bts=0,trx=0,ts=7,ss=0) RF Channel Release CMD due error 1 > <0004> abis_rsl.c:721 (bts=0,trx=0,ts=7,ss=0) DEACTivate SACCH CMD > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state ACTIVE -> RELEASE DUE ERROR > <0004> abis_rsl.c:830 (bts=0,trx=0,ts=7,ss=0) RF CHANNEL RELEASE ACK > <0004> abis_rsl.c:736 (bts=0,trx=0,ts=7,ss=0) is back in operation. > <0004> abis_rsl.c:1105 (bts=0,trx=0,ts=7,ss=0) state RELEASE DUE ERROR -> NONE > > ************************************************************************************************************************************************ > ************************************************************************************************************************************************ > Part of osmo-bts-trx output: > > :375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1611408 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1611412 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1611412 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00 fn=1611449 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=1611449 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1611453 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1611453 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1611459 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1611459 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1611463 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1611463 ts=0 trx=0 > > 9 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613809 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00 fn=1613846 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=1613846 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613850 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613850 ts=0 trx=0 > > > 7 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616247 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1616253 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616253 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1616257 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616257 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00 fn=1616294 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=1616294 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1616298 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616298 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1616304 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616304 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1616308 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1616308 ts=0 trx=0 > <0006> scheduler_trx.c:1517 GSM clock jitter: -2556 > > > <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613856 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613856 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613860 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613860 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=BCCH chan_nr=0x80 link_id=0x00 fn=1613897 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x80 link_id=0x00 fn=1613897 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613901 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613901 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613907 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613907 ts=0 trx=0 > <0006> scheduler.c:439 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=1613911 ts=0 trx=0 > <0006> scheduler.c:375 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=1613911 ts=0 trx=0 > > > > Thanks > Abdulghafar -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Mon Sep 5 10:14:56 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 5 Sep 2016 12:14:56 +0200 Subject: chan_alloc.c help In-Reply-To: References: Message-ID: <20160905101456.GB2824@ass40.sysmocom.de> On Fri, Sep 02, 2016 at 03:18:30PM +0100, Abdulghafar Shabaneh wrote: > Now I ran the osmo-nitb, osmo-bts-trx and osmo-trx all together with the > USRP2 with FLEX900 daughter board GSM900 band, it all works well except the > mobile is not able to register on the network. I haven't looked at your error logs in detail, this is just what comes to mind: Response speed may be an issue. Hopefully the pi is fast enough, and maybe try to run osmo-bts-trx -r 1 and osmo-pcu -r 1 for real-time priority (may need sudo). Also, the timing source for the SDR may be an issue. I am told e.g. the B200 is known to be unreliable without a quality timing source, and results improve with a proper 10MHz clock connected. ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From axilirator at gmail.com Tue Sep 6 01:54:02 2016 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Tue, 6 Sep 2016 07:54:02 +0600 Subject: OsmoBTS -> libosmogsm code migration In-Reply-To: <20160808170601.GC4437@dub7> References: <20160808170601.GC4437@dub7> Message-ID: Hello everyone! I am happy to report, that the GSM 05.03 code migration from OsmoBTS is finished now. For details, please see: https://gerrit.osmocom.org/#/c/816/ With best regards, Vadim Yanitskiy. 2016-08-09 0:06 GMT+07:00 Neels Hofmeyr : > On Thu, Aug 04, 2016 at 05:50:39PM +0600, Vadim Yanitskiy wrote: > > * The 'osmo-bts/gsm_data.h', which includes 'openbsc/gsm_data_shared.h' > > as well. > > > > So, there is regarding questions: > > > > 3) Which logging category it would be better to use after migration? > > 4) What to do with the 'osmo-bts/gsm_data.h'? > > 5) I don't think, that it's a good way to require something from the > > OpenBSC sources during OsmoBTS build... How can we change it? > > I've also faced the problem twice recently that I effectively can't log > from > gsm_data_shared.c, since the logging constants (e.g. DRSL) are defined > separately for openbsc and osmo-bts (can't include both headers...). > > The first time I solved it by returning an error code and code-dup'ing the > error logging in osmo-bts and openbsc (see lchan_lookup() in > openbsc/src/libbsc/abis_rsl.c and osmo-bts/src/common/rsl.c). > > The other time I placed a compile time #warning where I'd have preferred to > post an error log (not committed yet). > > The one advantage of gsm_data_shared.c is that I feel that I can modify > that > API without breaking any libosmocore ABI. We can pretty freely drop stuff > in > there and re-use across openbsc and osmo-bts that isn't used anywhere else. > > But I find these solutions rather unsatisfactory / ugly and would +1 for > solving the gsm_data_shared.c evil-twin situation. If some of the stuff > isn't > worthy of moving to libosmocore, we'd need another tiny osmo-lib? > > ~Neels > > -- > - Neels Hofmeyr http://www.sysmocom.de/ > ======================================================================= > * sysmocom - systems for mobile communications GmbH > * Alt-Moabit 93 > * 10559 Berlin, Germany > * Sitz / Registered office: Berlin, HRB 134158 B > * Gesch?ftsf?hrer / Managing Directors: Harald Welte > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 246tnt at gmail.com Tue Sep 6 03:46:01 2016 From: 246tnt at gmail.com (Sylvain Munaut) Date: Tue, 6 Sep 2016 05:46:01 +0200 Subject: OsmoBTS -> libosmogsm code migration In-Reply-To: References: Message-ID: Hi, > With regards to convolutional coding, the main difference between GPRS > and EGPRS will be the use of tail-biting recursive codes. > > Max, can the utility generate recursive state tables? Yes Cheers, Sylvain From abdulghafar1412 at gmail.com Tue Sep 6 07:39:12 2016 From: abdulghafar1412 at gmail.com (Abdulghafar Shabaneh) Date: Tue, 6 Sep 2016 08:39:12 +0100 Subject: chan_alloc.c help In-Reply-To: <20160905101456.GB2824@ass40.sysmocom.de> References: <20160905101456.GB2824@ass40.sysmocom.de> Message-ID: Hi I tried osmo-pcu but the output was like that. I built everything again but my network hardly shows up, and with the name of the carrier for the SIM, not the name I assign !. pi at raspberrypi:~ $ osmo-pcu -r 1 No config file: 'osmo-pcu.cfg' Using default config. <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:264 Failed to connect to the osmo-bts PCU socket, delaying... '/tmp/pcu_bts' <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:264 Failed to connect to the osmo-bts PCU socket, delaying... '/tmp/pcu_bts' ^CSignal 2 received. full talloc report on 'Osmo-PCU context' (total 1 bytes in 1 blocks) pi at raspberrypi:~ $ sudo osmo-pcu -r 1 No config file: 'osmo-pcu.cfg' Using default config. <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:285 osmo-bts PCU socket has been connected <0001> pcu_l1_if.cpp:357 BTS not available pi at raspberrypi:~ $ On Mon, Sep 5, 2016 at 11:14 AM, Neels Hofmeyr wrote: > On Fri, Sep 02, 2016 at 03:18:30PM +0100, Abdulghafar Shabaneh wrote: > > Now I ran the osmo-nitb, osmo-bts-trx and osmo-trx all together with the > > USRP2 with FLEX900 daughter board GSM900 band, it all works well except > the > > mobile is not able to register on the network. > > I haven't looked at your error logs in detail, this is just what comes to > mind: > > Response speed may be an issue. Hopefully the pi is fast enough, and maybe > try to run > osmo-bts-trx -r 1 > and > osmo-pcu -r 1 > for real-time priority (may need sudo). > > Also, the timing source for the SDR may be an issue. I am told e.g. the > B200 is known to be unreliable without a quality timing source, and > results improve with a proper 10MHz clock connected. > > ~Neels > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Wed Sep 7 10:44:37 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 7 Sep 2016 12:44:37 +0200 Subject: octasic build failure / header versions Message-ID: <20160907104437.GA15536@dub7> Yesterday we had problems building the current osmo-bts-octphy with the current octphy-2g-headers. To resolve, we've reverted two commits and added a change in osmo-bts. (1) osmo-bts included a struct member not present anywhere in octphy-2g-headers. https://gerrit.osmocom.org/820 https://gerrit.osmocom.org/821 On our test setup at sysmocom, I found a version of the headers called OCTSDR-2G-02.05.00-B780-DEBUG that includes this struct member, but those headers have proprietary licensing. Also, the current version apparently is 2.07, while the one with the unknown struct header seems to be older: 2.05. So it looks like the usCentreArfcn item has been removed in a newer version, even though it looks really useful to me. It would be good to resolve this confusion, probably as soon as Max is back from vacation (Max is the author of the reverted commits). (2) In the most recent version, a #define naming has changed. In https://gerrit.osmocom.org/822 Holger asks: > Do we have any precedence of using #if for version checks? You can > use #ifdef for both of them to support old and new headers? We could use a check like #if cOCTVC1_HW_VERSION_MAJOR <=2 && cOCTVC1_HW_VERSION_MINOR < 7 [...]_IDLE[...] #else [...]_UNUSED[...] #endif but I doubt that we will want to go back to old headers. If I'm the only one in doubt, we'd have a check like above in three places in osmo-bts. Thanks for your opinions, ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed Sep 7 11:32:25 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 7 Sep 2016 13:32:25 +0200 Subject: octasic build failure / header versions In-Reply-To: <20160907104437.GA15536@dub7> References: <20160907104437.GA15536@dub7> Message-ID: <20160907113225.GA16144@dub7> On Wed, Sep 07, 2016 at 12:44:37PM +0200, Neels Hofmeyr wrote: > (1) > osmo-bts included a struct member not present anywhere in octphy-2g-headers. > > https://gerrit.osmocom.org/820 > https://gerrit.osmocom.org/821 > > On our test setup at sysmocom, I found a version of the headers called > OCTSDR-2G-02.05.00-B780-DEBUG that includes this struct member, but those > headers have proprietary licensing. Also, the current version apparently is > 2.07, while the one with the unknown struct header seems to be older: 2.05. So > it looks like the usCentreArfcn item has been removed in a newer version, even > though it looks really useful to me. > > It would be good to resolve this confusion, probably as soon as Max is back > from vacation (Max is the author of the reverted commits). I should also mention that in effect, multi-TRX support on octasic is expected to be broken at this stage. ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed Sep 7 12:43:59 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 7 Sep 2016 14:43:59 +0200 Subject: tcp port 4252 used twice Message-ID: <20160907124359.GB16144@dub7> When updating https://osmocom.org/projects/cellular-infrastructure/wiki/PortNumbers I noticed that 4252 is used both for OpenGGSN Ctrl as well as sysmobts-mgr VTY. Should we do something about that? Technically, we have VTY commands available to redirect the vty bind port, but sysmobts-mgr does not heed that VTY command yet. Related: https://gerrit.osmocom.org/754 ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From holger at freyther.de Wed Sep 7 17:28:59 2016 From: holger at freyther.de (Holger Freyther) Date: Wed, 7 Sep 2016 19:28:59 +0200 Subject: tcp port 4252 used twice In-Reply-To: <20160907124359.GB16144@dub7> References: <20160907124359.GB16144@dub7> Message-ID: <767D6864-6719-432C-82FB-126F30689E75@freyther.de> > On 07 Sep 2016, at 14:43, Neels Hofmeyr wrote: > > When updating https://osmocom.org/projects/cellular-infrastructure/wiki/PortNumbers > I noticed that 4252 is used both for OpenGGSN Ctrl as well as sysmobts-mgr VTY. > Should we do something about that? yes, please fix the OpenGGSN. We will run GGSN and sysmobts-mgr on the same device. holger From sipos.csaba at kvk.uni-obuda.hu Thu Sep 8 10:56:45 2016 From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba) Date: Thu, 8 Sep 2016 12:56:45 +0200 (CEST) Subject: PRACH fails In-Reply-To: <985635803.12728438.1473331485499.JavaMail.zimbra@kvk.uni-obuda.hu> Message-ID: <1982990945.12731307.1473332205139.JavaMail.zimbra@kvk.uni-obuda.hu> Dear Tom and List, I am in the process of updating the wiki for USRP radios, therefor I am recompiling everything Osmocom related with the latest master branches. I managed to setup the system, the CS services are working just fine (only fullrate and SMS is tested yet), but the GPRS service seems to be not working. I am using my well tested setup on 1800MHz (ARFCN 885), with duplex filters. On the Osmo-BTS end I get this message: <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access <0007> l1sap.c:957 RACH for packet access Osmo-PCU in the same time shows the following (repeatedly): Thu Sep 8 12:48:30 2016 DRLCMAC <0002> tbf.cpp:819 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) timer 3169 expired. Thu Sep 8 12:48:30 2016 DRLCMAC <0002> tbf.cpp:874 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) T3169 timeout during transsmission Thu Sep 8 12:48:30 2016 DRLCMAC <0002> tbf.cpp:893 - Assignment was on CCCH Thu Sep 8 12:48:30 2016 DRLCMAC <0002> tbf.cpp:899 - No uplink data received yet Thu Sep 8 12:48:30 2016 DRLCMAC <0002> tbf.cpp:879 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) will be freed due to timeout Thu Sep 8 12:48:30 2016 DRLCMAC <0002> tbf.cpp:334 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) free Thu Sep 8 12:48:30 2016 DRLCMAC <0002> bts.cpp:1501 PDCH(TS 6, TRX 0): Detaching TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN), 0 TBFs, USFs = 00, TFIs = 00000000. Thu Sep 8 12:48:30 2016 DRLCMAC <0002> gprs_ms.cpp:323 Detaching TBF from MS object, TLLI = 0x00000000, TBF = TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) Thu Sep 8 12:48:30 2016 DRLCMAC <0002> gprs_ms.cpp:140 Destroying MS object, TLLI = 0x00000000 Thu Sep 8 12:48:30 2016 DRLCMAC <0002> tbf.cpp:355 ********** TBF ends here ********** Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:486 MS requests UL TBF on RACH, so we provide one: Thu Sep 8 12:48:31 2016 DRLCMAC <0002> tbf.cpp:672 ********** TBF starts here ********** Thu Sep 8 12:48:31 2016 DRLCMAC <0002> tbf.cpp:674 Allocating UL TBF: MS_CLASS=0/0 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_ms.cpp:114 Creating MS object, TLLI = 0x00000000 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:413 Searching for first unallocated TFI: TRX=0 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:423 Found TFI=0. Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:525 Slot Allocation (Algorithm B) for unknown class (assuming 12) Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:560 - Rx=4 Tx=4 Sum Rx+Tx=5 Tta=2 Ttb=1 Tra=2 Trb=1 Type=1 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 0, because not enabled Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 1, because not enabled Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 2, because not enabled Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 3, because not enabled Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:579 - Possible DL/UL slots: (TS=0)"....CCCC"(TS=7) Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:940 - Selected UL slots: (TS=0)"......U."(TS=7), single Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:966 Using single slot at TS 6 for UL Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:990 - Reserved DL/UL slots: (TS=0)"......C."(TS=7) Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:1017 - Assigning UL TS 6 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:1481 PDCH(TS 6, TRX 0): Attaching TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL), 1 TBFs, USFs = 01, TFIs = 00000001. Thu Sep 8 12:48:31 2016 DRLCMAC <0002> tbf.cpp:385 - Setting Control TS 6 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> gprs_ms.cpp:267 Attaching TBF to MS object, TLLI = 0x00000000, TBF = TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL) Thu Sep 8 12:48:31 2016 DRLCMAC <0002> tbf.cpp:625 Allocated TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL): trx = 0, ul_slots = 40, dl_slots = 00 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:291 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL) changes state from NULL to FLOW Thu Sep 8 12:48:31 2016 DRLCMAC <0002> tbf.cpp:409 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) starting timer 3169. Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:530 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) [UPLINK] START Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:534 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) RX: [PCU <- BTS] RACH qbit-ta=0 ra=0x78, Fn=1011875 (27,35,7) Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:536 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) TX: START Immediate Assignment Uplink (AGCH) Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:549 - TRX=0 (885) TS=6 TA=0 TSC=7 TFI=0 USF=0 Thu Sep 8 12:48:31 2016 DRLCMAC <0002> bts.cpp:291 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) changes state from FLOW to WAIT ASSIGN Thu Sep 8 12:48:33 2016 DBSSGP <0009> gprs_bssgp_pcu.cpp:792 Sending flow control info on BVCI 2 Thu Sep 8 12:48:33 2016 DBSSGP <0009> gprs_bssgp_pcu.cpp:705 Computed BVC leak rate = 10000, num_pdch = 4, cs = CS-4 Thu Sep 8 12:48:33 2016 DBSSGP <0009> gprs_bssgp_pcu.cpp:729 Computed MS default leak rate = 10000, ms_num_pdch = 4, cs = CS-4 Thu Sep 8 12:48:33 2016 DBSSGP <0009> gprs_bssgp_pcu.cpp:758 Sending FLOW CONTROL BVC, Bmax = 100000, R = 10000, Bmax_MS = 100000, R_MS = 10000, avg_dly = 0 Thu Sep 8 12:48:33 2016 DBSSGP <0009> gprs_bssgp_pcu.cpp:385 rx BVCI_PTP gprs_bssgp_rx_ptp Thu Sep 8 12:48:33 2016 DBSSGP <0009> gprs_bssgp_pcu.cpp:245 rx BSSGP_PDUT_FLOW_CONTROL_BVC_ACK Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:819 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) timer 3169 expired. Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:874 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) T3169 timeout during transsmission Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:893 - Assignment was on CCCH Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:899 - No uplink data received yet Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:879 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) will be freed due to timeout Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:334 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) free Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:1501 PDCH(TS 6, TRX 0): Detaching TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN), 0 TBFs, USFs = 00, TFIs = 00000000. Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_ms.cpp:323 Detaching TBF from MS object, TLLI = 0x00000000, TBF = TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_ms.cpp:140 Destroying MS object, TLLI = 0x00000000 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:355 ********** TBF ends here ********** Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:486 MS requests UL TBF on RACH, so we provide one: Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:672 ********** TBF starts here ********** Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:674 Allocating UL TBF: MS_CLASS=0/0 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_ms.cpp:114 Creating MS object, TLLI = 0x00000000 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:413 Searching for first unallocated TFI: TRX=0 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:423 Found TFI=0. Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:525 Slot Allocation (Algorithm B) for unknown class (assuming 12) Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:560 - Rx=4 Tx=4 Sum Rx+Tx=5 Tta=2 Ttb=1 Tra=2 Trb=1 Type=1 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 0, because not enabled Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 1, because not enabled Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 2, because not enabled Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:157 - Skipping TS 3, because not enabled Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:579 - Possible DL/UL slots: (TS=0)"....CCCC"(TS=7) Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:940 - Selected UL slots: (TS=0)"......U."(TS=7), single Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:966 Using single slot at TS 6 for UL Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:990 - Reserved DL/UL slots: (TS=0)"......C."(TS=7) Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_rlcmac_ts_alloc.cpp:1017 - Assigning UL TS 6 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:1481 PDCH(TS 6, TRX 0): Attaching TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL), 1 TBFs, USFs = 01, TFIs = 00000001. Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:385 - Setting Control TS 6 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> gprs_ms.cpp:267 Attaching TBF to MS object, TLLI = 0x00000000, TBF = TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL) Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:625 Allocated TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL): trx = 0, ul_slots = 40, dl_slots = 00 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:291 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=NULL) changes state from NULL to FLOW Thu Sep 8 12:48:36 2016 DRLCMAC <0002> tbf.cpp:409 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) starting timer 3169. Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:530 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) [UPLINK] START Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:534 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) RX: [PCU <- BTS] RACH qbit-ta=0 ra=0x79, Fn=1013049 (27,36,11) Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:536 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) TX: START Immediate Assignment Uplink (AGCH) Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:549 - TRX=0 (885) TS=6 TA=0 TSC=7 TFI=0 USF=0 Thu Sep 8 12:48:36 2016 DRLCMAC <0002> bts.cpp:291 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=FLOW) changes state from FLOW to WAIT ASSIGN Thu Sep 8 12:48:41 2016 DRLCMAC <0002> tbf.cpp:819 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) timer 3169 expired. Thu Sep 8 12:48:41 2016 DRLCMAC <0002> tbf.cpp:874 TBF(TFI=0 TLLI=0x00000000 DIR=UL STATE=WAIT ASSIGN) T3169 timeout during transsmission The SGSN and GGSN logs are empty. The RX gain is on 5dB, the UHD version is 3.10.0-release. Only GPRS is allowed so far on 4 PDCHs. Osmo-TRX is started with default set: Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 1 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 1 EDGE support............ Disabled Reference............... Internal C0 Filler Table......... Disabled Multi-Carrier........... Disabled Diversity............... Disabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 The CS call and SMS are both working fine, the audio quality is quite good. Can someone give me a hint where this goes wrong? From what I see the PRACH is failing to succeed. Regards, Csaba From nhofmeyr at sysmocom.de Thu Sep 8 11:10:48 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 8 Sep 2016 13:10:48 +0200 Subject: tcp port 4252 used twice In-Reply-To: <767D6864-6719-432C-82FB-126F30689E75@freyther.de> References: <20160907124359.GB16144@dub7> <767D6864-6719-432C-82FB-126F30689E75@freyther.de> Message-ID: <20160908111048.GA18162@dub7> On Wed, Sep 07, 2016 at 07:28:59PM +0200, Holger Freyther wrote: > yes, please fix the OpenGGSN. We will run GGSN and sysmobts-mgr on the same device. IIUC, OSMO_CTRL_PORT_GGSN is defined in osmocom/ctrl/ports.h but openggsn doesn't actually feature a ctrl interface yet. Fixing the #define and adjusting the wiki page. https://gerrit.osmocom.org/833 https://gerrit.osmocom.org/834 ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Thu Sep 8 11:44:49 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Thu, 8 Sep 2016 13:44:49 +0200 Subject: PRACH fails In-Reply-To: <1982990945.12731307.1473332205139.JavaMail.zimbra@kvk.uni-obuda.hu> References: <985635803.12728438.1473331485499.JavaMail.zimbra@kvk.uni-obuda.hu> <1982990945.12731307.1473332205139.JavaMail.zimbra@kvk.uni-obuda.hu> Message-ID: <20160908114449.GA20556@dub7> Hi Sipos, this sounds like https://osmocom.org/issues/1756 You need to either revert f1a7b8fc6651f92a8b7f3f27b7ca05d07f4e44e0 in osmo-pcu or add this to your pcu config: pcu two-phase-access Normally, whether to use two phase access is decided on the fly, but this option enforces two-phase-access for every assignment -- and incidentally works around the unknown bug. This issue has been sitting there for some time now, and though adding the WAIT_ASSIGN state makes sense, we've still not resolved the bug hidden within. https://gerrit.osmocom.org/218 ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From sipos.csaba at kvk.uni-obuda.hu Thu Sep 8 12:21:12 2016 From: sipos.csaba at kvk.uni-obuda.hu (Sipos Csaba) Date: Thu, 8 Sep 2016 14:21:12 +0200 (CEST) Subject: PRACH fails In-Reply-To: <20160908114449.GA20556@dub7> References: <985635803.12728438.1473331485499.JavaMail.zimbra@kvk.uni-obuda.hu> <1982990945.12731307.1473332205139.JavaMail.zimbra@kvk.uni-obuda.hu> <20160908114449.GA20556@dub7> Message-ID: <1640688938.12750588.1473337272596.JavaMail.zimbra@kvk.uni-obuda.hu> Hi Neels, > pcu > two-phase-access Thanks for this, it "solved" the problem, the PDP context is active now. Will put a note on the wiki. Regards, Csaba ----- Eredeti ?zenet ----- Felad?: "Neels Hofmeyr" C?mzett: "Sipos Csaba" M?solatot kap: "OpenBSC Mailing List" Elk?ld?tt ?zenetek: Cs?t?rt?k, 2016. Szeptember 8. 13:44:49 T?rgy: Re: PRACH fails Hi Sipos, this sounds like https://osmocom.org/issues/1756 You need to either revert f1a7b8fc6651f92a8b7f3f27b7ca05d07f4e44e0 in osmo-pcu or add this to your pcu config: pcu two-phase-access Normally, whether to use two phase access is decided on the fly, but this option enforces two-phase-access for every assignment -- and incidentally works around the unknown bug. This issue has been sitting there for some time now, and though adding the WAIT_ASSIGN state makes sense, we've still not resolved the bug hidden within. https://gerrit.osmocom.org/218 ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte From laforge at gnumonks.org Fri Sep 9 01:11:04 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 9 Sep 2016 09:11:04 +0800 Subject: tcp port 4252 used twice In-Reply-To: <20160908111048.GA18162@dub7> References: <20160907124359.GB16144@dub7> <767D6864-6719-432C-82FB-126F30689E75@freyther.de> <20160908111048.GA18162@dub7> Message-ID: <20160909011104.ywrb6ml2p7lt54jr@nataraja> On Thu, Sep 08, 2016 at 01:10:48PM +0200, Neels Hofmeyr wrote: > On Wed, Sep 07, 2016 at 07:28:59PM +0200, Holger Freyther wrote: > > yes, please fix the OpenGGSN. We will run GGSN and sysmobts-mgr on the same device. > > IIUC, OSMO_CTRL_PORT_GGSN is defined in osmocom/ctrl/ports.h but openggsn > doesn't actually feature a ctrl interface yet. Fixing the #define and adjusting > the wiki page. Please also update the list of ports in the osmo-gsm-manuals.git -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Sep 9 01:14:32 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 9 Sep 2016 09:14:32 +0800 Subject: PRACH fails In-Reply-To: <1982990945.12731307.1473332205139.JavaMail.zimbra@kvk.uni-obuda.hu> References: <985635803.12728438.1473331485499.JavaMail.zimbra@kvk.uni-obuda.hu> <1982990945.12731307.1473332205139.JavaMail.zimbra@kvk.uni-obuda.hu> Message-ID: <20160909011432.mg7jtga24dmcndwb@nataraja> Dear all, not really important, but still two remarks: * GPRS related questions should preferrably go to the osmocom-net-gprs list * RACH for packet service is not equal PRACH. PRACH is a dedicated logical channel on the Um interface that _can_ be enabled (like PBCCH, PCCCH, ...) but whihc is neither supported by osmo-bts/osmo-pcu, nor used anywhere. The 3GPP removed the PBCCH/PCCCH and all related channels several years ago from the specs, as there was no operator known to use any of them. So new handsets no longer (have to) support those channels, which means it is utterly useless for a new implementation like the Osmocom one to bother to support them. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Fri Sep 9 01:18:03 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 9 Sep 2016 09:18:03 +0800 Subject: octasic build failure / header versions In-Reply-To: <20160907104437.GA15536@dub7> References: <20160907104437.GA15536@dub7> Message-ID: <20160909011803.rqc7si23mkdmji25@nataraja> On Wed, Sep 07, 2016 at 12:44:37PM +0200, Neels Hofmeyr wrote: > osmo-bts included a struct member not present anywhere in octphy-2g-headers. > > https://gerrit.osmocom.org/820 > https://gerrit.osmocom.org/821 > > On our test setup at sysmocom, I found a version of the headers called > OCTSDR-2G-02.05.00-B780-DEBUG that includes this struct member, but those > headers have proprietary licensing. Also, the current version apparently is > 2.07, while the one with the unknown struct header seems to be older: 2.05. So > it looks like the usCentreArfcn item has been removed in a newer version, even > though it looks really useful to me. > > It would be good to resolve this confusion, probably as soon as Max is back > from vacation (Max is the author of the reverted commits). The commit relates to the development of Multi-TRX support for OCTPHY. The fact that no GPL-compatible headers had been provided is probably an oversight and it would be best to simply ask Octasic to provide them. As there are the master (single-TRX) and multi-TRX PHY versions out there in parallel, it would be best if we can compile against both of them, possibly by checking for the given struct members from autoconf and then adapting accordingly. The same goes for other related new additions, like EGPRS capabilities in the PHY. > In the most recent version, a #define naming has changed. > In https://gerrit.osmocom.org/822 Holger asks: > > > Do we have any precedence of using #if for version checks? You can > > use #ifdef for both of them to support old and new headers? > > We could use a check like > > #if cOCTVC1_HW_VERSION_MAJOR <=2 && cOCTVC1_HW_VERSION_MINOR < 7 Yes, and we should. As much as our jenkins should try to compile osmo-bts against various different (at least recent) PHY header releases, both 'stable' as well as those with multi-TRX and/or EGPRS features. Reards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Fri Sep 9 03:15:18 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 9 Sep 2016 05:15:18 +0200 Subject: PRACH fails In-Reply-To: <20160909011432.mg7jtga24dmcndwb@nataraja> References: <985635803.12728438.1473331485499.JavaMail.zimbra@kvk.uni-obuda.hu> <1982990945.12731307.1473332205139.JavaMail.zimbra@kvk.uni-obuda.hu> <20160909011432.mg7jtga24dmcndwb@nataraja> Message-ID: <20160909031518.GB22877@dub7> On Fri, Sep 09, 2016 at 09:14:32AM +0800, Harald Welte wrote: > * RACH for packet service is not equal PRACH. PRACH is a dedicated > logical channel on the Um interface that _can_ be enabled (like PBCCH, > PCCCH, ...) but whihc is neither supported by osmo-bts/osmo-pcu, nor > used anywhere. The 3GPP removed the PBCCH/PCCCH and all related > channels several years ago from the specs, as there was no operator > known to use any of them. So new handsets no longer (have to) support > those channels, which means it is utterly useless for a new > implementation like the Osmocom one to bother to support them. Ah, good to know. Is PTCCH also one of those? It sounds similar, but I guess not? https://osmocom.org/issues/1796 ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Fri Sep 9 04:49:52 2016 From: laforge at gnumonks.org (Harald Welte) Date: Fri, 9 Sep 2016 12:49:52 +0800 Subject: PRACH fails In-Reply-To: <20160909031518.GB22877@dub7> References: <985635803.12728438.1473331485499.JavaMail.zimbra@kvk.uni-obuda.hu> <1982990945.12731307.1473332205139.JavaMail.zimbra@kvk.uni-obuda.hu> <20160909011432.mg7jtga24dmcndwb@nataraja> <20160909031518.GB22877@dub7> Message-ID: <20160909044952.ml43rfkrbpvufama@nataraja> On Fri, Sep 09, 2016 at 05:15:18AM +0200, Neels Hofmeyr wrote: > Is PTCCH also one of those? It sounds similar, but I guess not? > https://osmocom.org/issues/1796 No. PTCCH is not part of the packet common cotrol channel (PCCCH). PCCCH is the one that's obsoleted, and it consists of PRACH, PBCCH, PPCH, PNCH and PAGCH (similar to CCCH = RACH+BCCH+PCH+AGCH+NCH in circuit switched). See Section 6.3.2 and 7 of TS 05.02. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From keith at rhizomatica.org Fri Sep 9 13:06:31 2016 From: keith at rhizomatica.org (Keith Whyte) Date: Fri, 9 Sep 2016 15:06:31 +0200 Subject: Help Interpreting Classmark and sqlite BLOB storage Message-ID: <7a8da1d2-47dc-56ed-d234-7c7595ab1087@rhizomatica.org> Hi All, 2 (related) questions in 1 thread here: I'm looking at Chapter 10.5.1.7 of GSM 04.08, also Figure 10.5.7 there, but I am not quite getting how to interpret it in relation to either openBSC log output such as: <000d> db.c:1130 Sync Equipment IMEI=357371048322730, classmark1=33, classmark2=33 18 82 , classmark3=00 08 00 52 20 00 00 4b or equally: root at bsc:~# echo "SELECT classmark1 FROM Equipment where id='505';" | sqlite3 /var/lib/osmocom/hlr.sqlite3 | xxd 0000000: 3531 0a 51. root at bsc:~# echo "SELECT classmark2 FROM Equipment where id='505';" | sqlite3 /var/lib/osmocom/hlr.sqlite3 | xxd 0000000: 0132 1781 0a .2... root at bsc:~# echo "SELECT classmark3 FROM Equipment where id='505';" | sqlite3 /var/lib/osmocom/hlr.sqlite3 | xxd 0000000: 01ff 07ff 511f ffff 4a0a ....Q...J. Specifically, in this case, not having the mathematical theory, I don't understand how to map 01ff 07ff 511f ffff 4a0a to 00 08 00 52 20 00 00 4b It doesn't /quite/ match, but more importantly mapping to Classmark 3 Value Part Could you help me understand how to map 01ff 07ff 511f ffff 4a0a to Figure 10.5.7 BTW, I get that the BLOBs in sqlite are somehow encoded, (if that is not completely the wrong term to use) as hex_value-1, I've also noted this in the SMS table when trying to identify an sms in the sms_queue. So question part 2: what is that about? Is there an easy way I could "decode" on the command line, as in: echo "SELECT user_data FROM sms limit 1;" | sqlite3 /var/lib/osmocom/hlr.sqlite3 | some magic to display readable SMS content Any tips? Thanks! From holger at freyther.de Fri Sep 9 13:49:58 2016 From: holger at freyther.de (Holger Freyther) Date: Fri, 9 Sep 2016 15:49:58 +0200 Subject: Help Interpreting Classmark and sqlite BLOB storage In-Reply-To: <7a8da1d2-47dc-56ed-d234-7c7595ab1087@rhizomatica.org> References: <7a8da1d2-47dc-56ed-d234-7c7595ab1087@rhizomatica.org> Message-ID: > On 09 Sep 2016, at 15:06, Keith Whyte wrote: > > BTW, I get that the BLOBs in sqlite are somehow encoded, (if that is not > completely the wrong term to use) as hex_value-1, I've also noted this > in the SMS table when trying to identify an sms in the sms_queue. So > question part 2: what is that about? > Is there an easy way I could "decode" on the command line, as in: > > echo "SELECT user_data FROM sms limit 1;" | sqlite3 > /var/lib/osmocom/hlr.sqlite3 | some magic to display readable SMS content Right libdbi has encoding for "blob". tnt has written a _dbi_binary_quote in python in pysim. It might help you to write the unquote. holger From nhofmeyr at sysmocom.de Fri Sep 9 15:17:32 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Fri, 9 Sep 2016 17:17:32 +0200 Subject: tcp port 4252 used twice In-Reply-To: <20160909011104.ywrb6ml2p7lt54jr@nataraja> References: <20160907124359.GB16144@dub7> <767D6864-6719-432C-82FB-126F30689E75@freyther.de> <20160908111048.GA18162@dub7> <20160909011104.ywrb6ml2p7lt54jr@nataraja> Message-ID: <20160909151732.GB2223@dub7> On Fri, Sep 09, 2016 at 09:11:04AM +0800, Harald Welte wrote: > Please also update the list of ports in the osmo-gsm-manuals.git done. ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From keith at rhizomatica.org Fri Sep 9 17:39:21 2016 From: keith at rhizomatica.org (Keith) Date: Fri, 9 Sep 2016 19:39:21 +0200 Subject: Help Interpreting Classmark and sqlite BLOB storage In-Reply-To: References: <7a8da1d2-47dc-56ed-d234-7c7595ab1087@rhizomatica.org> Message-ID: <9bdf910c-da46-e28e-6a0b-73e16a1229e1@rhizomatica.org> On 09/09/2016 15:49, Holger Freyther wrote: > Right libdbi has encoding for "blob". tnt has written a _dbi_binary_quote in python in pysim. It might help you to write the unquote. > > holger Right, not perfect, but it'll do: def _dbi_binary_unquote(s): e = ord(s[0]) out = [] for c in s: x = (256 + ord(c) + e) % 256 if x < 256: out.append(chr(x)) return ''.join(out) Any clues on classmark analysis? Thanks. From holger at freyther.de Fri Sep 9 18:11:56 2016 From: holger at freyther.de (Holger Freyther) Date: Fri, 9 Sep 2016 20:11:56 +0200 Subject: Help Interpreting Classmark and sqlite BLOB storage In-Reply-To: <9bdf910c-da46-e28e-6a0b-73e16a1229e1@rhizomatica.org> References: <7a8da1d2-47dc-56ed-d234-7c7595ab1087@rhizomatica.org> <9bdf910c-da46-e28e-6a0b-73e16a1229e1@rhizomatica.org> Message-ID: <1D98B95B-D1E7-4B65-9B2D-7B8B904807C6@freyther.de> > On 09 Sep 2016, at 19:39, Keith wrote: > > > Any clues on classmark analysis? As in general approach? Take the wireshark code and feed it your data? If you want to do analysis in python you could look at "libmich" and see how good their bit parsing infrastructure is? holger From axilirator at gmail.com Sun Sep 11 03:09:51 2016 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 11 Sep 2016 09:09:51 +0600 Subject: GSM 05.03 code re-licensing Message-ID: Hello everyone! Right now I am moving some code from OsmoBTS to libosmocore, exactly OsmoBTS/src/osmo-bts-trx/gsm0503*. And there is a licensing conflict, because this code licensed under AGPLv3+, but libosmocore code is GPLv2+. So, this is why I am contacting all authors/copyright holders. The question is: does everyone agree to re-license the code under GPLv2-or-later and move it code to libosmocore? Thanks in advance! With best regards, Vadim Yanitskiy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Sun Sep 11 03:43:58 2016 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Sun, 11 Sep 2016 09:43:58 +0600 Subject: OsmoBTS -> libosmogsm code migration In-Reply-To: References: Message-ID: Dear all, There is a problem, related to GSM 05.03 code migration. Please, have a look: https://gerrit.osmocom.org/#/c/841/1/src/gsm/Makefile.am The problem is that the gsm0503_coding.c has some dependences from libosmocodec, they are: - src/codec/gsm610.c - src/codec/gsm620.c - src/codec/gsm660.c And I have some doubts how to link them properly. As we already discussed with Neels, there are the following possible ways: - We can copy those files from ../codec/ during compilation, and remove them after make (dist)clean. This approach you can see implemented right now. - We can link the libosmocodec to the libgsmint or libosmogsm: > - libgsmint_la_LIBADD = ../libosmocore.la > + libgsmint_la_LIBADD = ../libosmocore.la ../codec/libosmocodec.la - Merge libosmocodec into libosmogsm. Every mentioned approach has it's own disadvantages. Maybe there is another way to solve the problem? Any opinions are welcome! With best regards, Vadim Yanitskiy. 2016-09-06 10:46 GMT+07:00 Sylvain Munaut <246tnt at gmail.com>: > Hi, > > > With regards to convolutional coding, the main difference between GPRS > > and EGPRS will be the use of tail-biting recursive codes. > > > > Max, can the utility generate recursive state tables? > > Yes > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sun Sep 11 04:12:05 2016 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 11 Sep 2016 12:12:05 +0800 Subject: OsmoBTS -> libosmogsm code migration In-Reply-To: References: Message-ID: <20160911041205.52j4ql5kolbho7ln@nataraja> Hi Vadim, On Sun, Sep 11, 2016 at 09:43:58AM +0600, Vadim Yanitskiy wrote: > There is a problem, related to GSM 05.03 code migration. > Please, have a look: > > https://gerrit.osmocom.org/#/c/841/1/src/gsm/Makefile.am > > The problem is that the gsm0503_coding.c has some dependences > from libosmocodec, they are: > > ?- src/codec/gsm610.c > ?- src/codec/gsm620.c > ?- src/codec/gsm660.c > > And I have some doubts how to link them properly. As we already > discussed with Neels, there are the following possible ways [...] I think there's one option that I would prefer: Having a new library, like libosmogsmphy (or libosmogsm-phy or libosmogsm_phy?) which contains the gsm0503 code and has dependencies to libosmocore and libosmocodec. This library could then either be inside libosmocore.git (if we can agree to re-license it as GPLv2), or we'd have to maintain it in a separate repository (if we have to keep it AGPL). This separation is not legally mandator and has no legal significance, it is juts merely not to confuse the user to obtain libosmocore.git which contained a mix of different licenses. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Sun Sep 11 04:08:46 2016 From: laforge at gnumonks.org (Harald Welte) Date: Sun, 11 Sep 2016 12:08:46 +0800 Subject: GSM 05.03 code re-licensing In-Reply-To: References: Message-ID: <20160911040846.qch5akr7262toq3p@nataraja> To add some more context for those not following the discussion on gerrit: There are other projects like OsmocomBB or gprsdecode which would benefit from using one shared implementation of all the related gsm 05.03 code. It would be great if we could eliminate various (partially incomplete) implementations of the same functionality and move that into a shared library. The idea so far was to move it into libosmocore.git, but that (as Vadim points out) is not possible unless we'd want to force every application to be AGPLv3-or-later. So far our policy has been that libosmocore.git code (libosmogsm/libosmocore/libosmovty) is GPLv2-or-later. If we cannot reach agreement on this question, it might be worth considering a new AGPLv3+ library for the code, independent of libosmogsm. So "normal" libosmocore-using applications can be GPLv2-or-later, while only those specifically needing the gsm0503 code would have to link in this new AGPLv3+ library. I'm not sure if it would be that bad. Some general backgorund on the original motivations on the use of GPL vs. AGPL in the Osmocom GSM related projects: >From my point of view, AGPL makes sense in contexts where the code is likely used by a mobile operator. We want to prevent such an operator from heavily improving our code without having to release the results back to the community. As a GSM operator does not distribute (in a copyright sense) the actual (e.g. BTS/BSC) code, GPL wouldn't be strong enough here. For projects like OsmocomBB or gprsdecode, the normal use case is to be used by an end-user. So if anybody was to put a modified version into production, it would involve the distribution of the related software to the end-user (e.g. in a phone firmware), and that would be distribution in terms of copyright => GPL is sufficient. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From nhofmeyr at sysmocom.de Mon Sep 12 13:05:11 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 12 Sep 2016 15:05:11 +0200 Subject: OsmoBTS -> libosmogsm code migration In-Reply-To: <20160911041205.52j4ql5kolbho7ln@nataraja> References: <20160911041205.52j4ql5kolbho7ln@nataraja> Message-ID: <20160912130511.GC1562@dub7> On Sun, Sep 11, 2016 at 12:12:05PM +0800, Harald Welte wrote: > I think there's one option that I would prefer: Having a new library, Since you are basically the most proficient on the topic and with the licensing issues discussed, this looks like the way to go. https://lists.osmocom.org/pipermail/openbsc/2016-September/009673.html > This separation is not legally mandator and has no legal significance, it is > juts merely not to confuse the user to obtain libosmocore.git which contained > a mix of different licenses. If one would like to avoid one of the two licenses, it would be cumbersome to have to install and then purge the part that has the wrong license. So it appears to me having a separate git makes sense. However, will there be tight dependencies between libosmocore and the new lib? Where exactly will be the separation between libosmocore and the new lib? > libosmogsmphy (or libosmogsm-phy or libosmogsm_phy?) We so far have only dashes in our git names, so not libosmogsm_phy. With libosmogsm as part of libosmocore, I would expect "libosmogsm-phy" to also be part of libosmocore. All newer libs have libosmo-*, so I'd bikeshed as libosmo-gsmphy From my meagre understanding of the topic I'd have chosen libosmo-gsmcodec, but I obviously trust that your choice for "phy" is sound. So then, we need a new git.osmocom.org as well as gerrit repository, right? I can add a gerrit project, but not a git.osmocom.org one, and am not familiar with the replication process between the two... ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From 246tnt at gmail.com Mon Sep 12 14:48:12 2016 From: 246tnt at gmail.com (Sylvain Munaut) Date: Mon, 12 Sep 2016 08:48:12 -0600 Subject: OsmoBTS -> libosmogsm code migration In-Reply-To: <20160911041205.52j4ql5kolbho7ln@nataraja> References: <20160911041205.52j4ql5kolbho7ln@nataraja> Message-ID: Hi, > This library could then either be inside libosmocore.git (if we can > agree to re-license it as GPLv2), or we'd have to maintain it in a > separate repository (if we have to keep it AGPL). I'd definitely try to re-license to GPLv2+ Just my 2ct. Cheers, Sylvain From axilirator at gmail.com Mon Sep 12 14:58:59 2016 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 12 Sep 2016 20:58:59 +0600 Subject: OsmoBTS -> libosmogsm code migration In-Reply-To: References: <20160911041205.52j4ql5kolbho7ln@nataraja> Message-ID: Hi, > I'd definitely try to re-license to GPLv2+ +1 Let's wait for copyright holders. With best regards, Vadim Yanitskiy. 2016-09-12 21:48 GMT+07:00 Sylvain Munaut <246tnt at gmail.com>: > Hi, > > > This library could then either be inside libosmocore.git (if we can > > agree to re-license it as GPLv2), or we'd have to maintain it in a > > separate repository (if we have to keep it AGPL). > > I'd definitely try to re-license to GPLv2+ > > Just my 2ct. > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: From axilirator at gmail.com Mon Sep 12 16:56:11 2016 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 12 Sep 2016 22:56:11 +0600 Subject: OsmoBTS -> libosmogsm code migration In-Reply-To: <20160911041205.52j4ql5kolbho7ln@nataraja> References: <20160911041205.52j4ql5kolbho7ln@nataraja> Message-ID: Hi Harald, > I think there's one option that I would prefer: Having a new library Ok, one may be a separate library in separate repo, or may be included into libosmocore as a sub-library, if re-licensing would be successful. Let's go this way. > like libosmogsmphy (or libosmogsm-phy or libosmogsm_phy?) which contains > the gsm0503 code and has dependencies to libosmocore and libosmocodec. IMHO, 'phy' may sound a little bit confusing. I would prefer something like 'libosmo-coding' or 'libosmocoding', without 'gsm' prefix, because there are GPRS and EDGE too. Also, this may be a potential place for other transcoding things, unrelated to GSM at all. We are talking about channel coging, right? :) With best regards, Vadim Yanitskiy. 2016-09-11 11:12 GMT+07:00 Harald Welte : > Hi Vadim, > > On Sun, Sep 11, 2016 at 09:43:58AM +0600, Vadim Yanitskiy wrote: > > > There is a problem, related to GSM 05.03 code migration. > > Please, have a look: > > > > https://gerrit.osmocom.org/#/c/841/1/src/gsm/Makefile.am > > > > The problem is that the gsm0503_coding.c has some dependences > > from libosmocodec, they are: > > > > - src/codec/gsm610.c > > - src/codec/gsm620.c > > - src/codec/gsm660.c > > > > And I have some doubts how to link them properly. As we already > > discussed with Neels, there are the following possible ways [...] > > I think there's one option that I would prefer: Having a new library, > like libosmogsmphy (or libosmogsm-phy or libosmogsm_phy?) which contains > the gsm0503 code and has dependencies to libosmocore and libosmocodec. > > This library could then either be inside libosmocore.git (if we can > agree to re-license it as GPLv2), or we'd have to maintain it in a > separate repository (if we have to keep it AGPL). This separation is > not legally mandator and has no legal significance, it is juts merely > not to confuse the user to obtain libosmocore.git which contained a mix > of different licenses. > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > ============================================================ > ================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom.tsou at ettus.com Tue Sep 13 22:54:47 2016 From: tom.tsou at ettus.com (Tom Tsou) Date: Tue, 13 Sep 2016 17:54:47 -0500 Subject: GSM 05.03 code re-licensing In-Reply-To: References: Message-ID: Harald, Thanks for the context and background information. On Sat, Sep 10, 2016 at 10:09 PM, Vadim Yanitskiy wrote: > Right now I am moving some code from OsmoBTS to libosmocore, > exactly OsmoBTS/src/osmo-bts-trx/gsm0503*. And there is a > licensing conflict, because this code licensed under AGPLv3+, > but libosmocore code is GPLv2+. > > So, this is why I am contacting all authors/copyright holders. > The question is: does everyone agree to re-license the code > under GPLv2-or-later and move it code to libosmocore? I agree with the current consensus to re-license GSM 05.03 code from AGPLv3 to GPLv2+ for inclusion into libosmocore. -TT From nhofmeyr at sysmocom.de Tue Sep 13 23:13:36 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 14 Sep 2016 01:13:36 +0200 Subject: libosmo-abis[master]: osmo_ortp.c: fix order of set_connected_mode and set_remote_... References: Message-ID: <20160913231336.GB1405@dub7> On Tue, Sep 13, 2016 at 04:39:38PM +0000, Max wrote: > To view, visit https://gerrit.osmocom.org/815 > > This is revert of 8c119f7a0510b75e7fa1b96a37f2a6650e13824f - would be better if it were marked as such. whoa, I wasn't aware of this. It is a patch from the Quickstart Guide for the new litecell15 board. Well, since it's already merged, I guess we won't mark it as a revert then, sorry about that. I've also posted a comment at OS#1661 https://osmocom.org/issues/1661 ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Tue Sep 13 23:17:11 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 14 Sep 2016 01:17:11 +0200 Subject: libosmo-abis[master]: osmo_ortp.c: fix order of set_connected_mode and set_remote_... In-Reply-To: <20160913231336.GB1405@dub7> References: <20160913231336.GB1405@dub7> Message-ID: <20160913231711.GA3122@dub7> [same mail, but fixed 'To:' header] On Tue, Sep 13, 2016 at 04:39:38PM +0000, Max wrote: > To view, visit https://gerrit.osmocom.org/815 > > This is revert of 8c119f7a0510b75e7fa1b96a37f2a6650e13824f - would be better if it were marked as such. whoa, I wasn't aware of this. It is a patch from the Quickstart Guide for the new litecell15 board. Well, since it's already merged, I guess we won't mark it as a revert then, sorry about that. I've also posted a comment at OS#1661 https://osmocom.org/issues/1661 ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From Mrinal.Mishra at radisys.com Wed Sep 14 06:44:19 2016 From: Mrinal.Mishra at radisys.com (Mrinal Mishra) Date: Wed, 14 Sep 2016 06:44:19 +0000 Subject: MS Initial Registration failure observed in osmo-trx setup Message-ID: Hello All, We are trying to bring up osmo-trx setup in Ettus USRP B200 Board for Testing CS and PS call . When we tried to do the initial Registration for UE it is failing. Could you please help to point out what could be the issue and how to resolve this. Please find below the observation and log snippet for reference: After MS power Up Network is getting detected on the MS , Rach is received at BTS , Channel Activation is successful at A-bis interface and later Immediate Assignment is seen in the log. After Immediate assignment no further message is observed in Uplink/Downlink and later BSC is releasing the SDCCH/SACCH channel as observed from the log. BTS LOG Snippet: OsmoBTS# <0000> rsl.c:2209 (bts=0,trx=0,ts=0,ss=4) Fwd RLL msg CHAN_RQD from LAPDm to A-bis <0000> rsl.c:2290 (bts=0,trx=0,ts=0,ss=0) Rx RSL CHAN_ACTIV <0000> rsl.c:926 chan_nr=0x20 type=0x00 mode=0x00 <0006> scheduler.c:1344 Activating SDCCH/4(0) on trx=0 ts=0 <0006> scheduler.c:1344 Activating SACCH/4(0) on trx=0 ts=0 <0006> scheduler.c:1393 Set mode 3, 0, handover 0 on SDCCH/4(0) of trx=0 ts=0 <0006> scheduler.c:1458 Set a5/0 uplink for SDCCH/4(0) on trx=0 ts=0 <0006> scheduler.c:1458 Set a5/0 uplink for SACCH/4(0) on trx=0 ts=0 <0006> scheduler.c:1458 Set a5/0 downlink for SDCCH/4(0) on trx=0 ts=0 <0006> scheduler.c:1458 Set a5/0 downlink for SACCH/4(0) on trx=0 ts=0 <0000> rsl.c:559 (bts=0,trx=0,ts=0,ss=0) Tx CHAN ACT ACK <000b> trx_if.c:485 Tx burst length 0 invalid <0000> rsl.c:2236 (bts=0,trx=0,ts=0,ss=0) Rx RSL IMM_ASS_CMD <000b> trx_if.c:485 Tx burst length 0 invalid <000b> trx_if.c:485 Tx burst length 0 invalid <000b> trx_if.c:485 Tx burst length 0 invalid <0006> scheduler_trx.c:867 Received incomplete data frame at fn=0 (0/102) for SDCCH/4(0) <0006> scheduler_trx.c:867 Received incomplete data frame at fn=0 (0/102) for SACCH/4(0) <0000> rsl.c:2290 (bts=0,trx=0,ts=0,ss=0) Rx RSL DEACTIVATE_SACCH <0006> scheduler.c:1344 Deactivating SACCH/4(0) on trx=0 ts=0 <0000> rsl.c:2290 (bts=0,trx=0,ts=0,ss=0) Rx RSL RF_CHAN_REL <0006> scheduler.c:1344 Deactivating SDCCH/4(0) on trx=0 ts=0 <0000> rsl.c:519 (bts=0,trx=0,ts=0,ss=0) Tx RF CHAN REL ACK <0006> scheduler_trx.c:867 Received incomplete data frame at fn=1421484 (12/104) for PTCCH <0006> scheduler_trx.c:867 Received incomplete data frame at fn=1421484 (12/104) for PTCCH <0000> rsl.c:2209 (bts=0,trx=0,ts=0,ss=4) Fwd RLL msg CHAN_RQD from LAPDm to A-bis <0000> rsl.c:2290 (bts=0,trx=0,ts=2,ss=0) Rx RSL CHAN_ACTIV <0000> rsl.c:926 chan_nr=0x0a type=0x00 mode=0x00 <0006> scheduler.c:1344 Activating TCH/F on trx=0 ts=2 <0006> scheduler.c:1344 Activating SACCH/TF on trx=0 ts=2 <0006> scheduler.c:1393 Set mode 3, 0, handover 0 on TCH/F of trx=0 ts=2 <0006> scheduler.c:1393 Set mode 3, 0, handover 0 on PDTCH of trx=0 ts=2 <0006> scheduler.c:1393 Set mode 3, 0, handover 0 on PTCCH of trx=0 ts=2 <0006> scheduler.c:1458 Set a5/0 uplink for TCH/F on trx=0 ts=2 <0006> scheduler.c:1458 Set a5/0 uplink for SACCH/TF on trx=0 ts=2 <0006> scheduler.c:1458 Set a5/0 downlink for TCH/F on trx=0 ts=2 <0006> scheduler.c:1458 Set a5/0 downlink for SACCH/TF on trx=0 ts=2 <0000> rsl.c:559 (bts=0,trx=0,ts=2,ss=0) Tx CHAN ACT ACK <0000> rsl.c:2236 (bts=0,trx=0,ts=0,ss=0) Rx RSL IMM_ASS_CMD <0006> scheduler.c:267 Prim for trx=0 ts=2 at fn=1085114 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=1436721) <0006> scheduler_trx.c:1054 Received incomplete TCH frame ending at fn=1436997 (29/104) for TCH/F <0006> gsm0503_coding.c:1690 tch_fr_decode(): error decoding FACCH frame (399/456 bits) <0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1436997 for TCH/F <0006> gsm0503_coding.c:1690 tch_fr_decode(): error decoding FACCH frame (286/456 bits) <0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1437213 for TCH/F <0006> gsm0503_coding.c:1706 tch_fr_decode(): error checking CRC8 for the FR part of an FR frame <0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1438301 for TCH/F <0006> scheduler_trx.c:1054 Received incomplete TCH frame ending at fn=1438522 (98/104) for TCH/F <0006> gsm0503_coding.c:1690 tch_fr_decode(): error decoding FACCH frame (159/456 bits) <0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1438522 for TCH/F <0006> scheduler_trx.c:1054 Received incomplete TCH frame ending at fn=1438652 (20/104) for TCH/F <0006> gsm0503_coding.c:1706 tch_fr_decode(): error checking CRC8 for the FR part of an FR frame <0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1438652 for TCH/F <0000> rsl.c:2290 (bts=0,trx=0,ts=2,ss=0) Rx RSL DEACTIVATE_SACCH <0006> scheduler.c:1344 Deactivating SACCH/TF on trx=0 ts=2 <0000> rsl.c:2290 (bts=0,trx=0,ts=2,ss=0) Rx RSL RF_CHAN_REL <0006> scheduler.c:1344 Deactivating TCH/F on trx=0 ts=2 <0000> rsl.c:519 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK <0006> scheduler_trx.c:867 Received incomplete data frame at fn=1462772 (12/104) for PTCCH BSC log Snippet : OpenBSC# <0000> chan_alloc.c:342 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH <0004> abis_rsl.c:1727 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(990) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0d ta=0 <0004> abis_rsl.c:536 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1456 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:806 (bts=0,trx=0,ts=0,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:718 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:863 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:767 (bts=0,trx=0,ts=0,ss=0) is back in operation. <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE <0000> chan_alloc.c:342 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH <0004> abis_rsl.c:1727 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(990) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0b ta=0 <0004> abis_rsl.c:536 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1456 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:806 (bts=0,trx=0,ts=0,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:718 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:863 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:767 (bts=0,trx=0,ts=0,ss=0) is back in operation. <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE <0000> chan_alloc.c:342 (bts=0,trx=0,ts=2,pchan=TCH/F) Allocating lchan=0 as TCH_F <0004> abis_rsl.c:1727 (bts=0,trx=0,ts=2,ss=0) Activating ARFCN(990) SS(0) lctype TCH_F r=OTHER ra=0xe7 ta=0 <0004> abis_rsl.c:536 (bts=0,trx=0,ts=2,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1456 (bts=0,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:806 (bts=0,trx=0,ts=2,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:718 (bts=0,trx=0,ts=2,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:863 (bts=0,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:767 (bts=0,trx=0,ts=2,ss=0) is back in operation. <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state RELEASE DUE ERROR -> NONE Note : We are using internal clock of osmo-trx no external Clock is connected. Thanks and Regards, Mrinal -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.0jacob0 at gmail.com Wed Sep 14 10:17:12 2016 From: sami.0jacob0 at gmail.com (sami) Date: Wed, 14 Sep 2016 13:17:12 +0300 Subject: MS Initial Registration failure observed in osmo-trx setup In-Reply-To: References: Message-ID: <815661E7-8806-4975-B4BE-8BE2A3B04E4E@gmail.com> Hi, I had the same problem. Most probably this is due to the UHD version you are using, if you use older than version 3.9 you should be OK. On Sep 14, 2016, at 9:44 AM, Mrinal Mishra wrote: > Hello All, > > We are trying to bring up osmo-trx setup in Ettus USRP B200 Board for Testing CS and PS call . When we tried to do the initial Registration for UE it is failing. > Could you please help to point out what could be the issue and how to resolve this. > > Please find below the observation and log snippet for reference: > > After MS power Up Network is getting detected on the MS , Rach is received at BTS , Channel Activation is successful at A-bis interface and later Immediate Assignment is seen in the log. > After Immediate assignment no further message is observed in Uplink/Downlink and later BSC is releasing the SDCCH/SACCH channel as observed from the log. > > > BTS LOG Snippet: > > OsmoBTS# <0000> rsl.c:2209 (bts=0,trx=0,ts=0,ss=4) Fwd RLL msg CHAN_RQD from LAPDm to A-bis > <0000> rsl.c:2290 (bts=0,trx=0,ts=0,ss=0) Rx RSL CHAN_ACTIV > <0000> rsl.c:926 chan_nr=0x20 type=0x00 mode=0x00 > <0006> scheduler.c:1344 Activating SDCCH/4(0) on trx=0 ts=0 > <0006> scheduler.c:1344 Activating SACCH/4(0) on trx=0 ts=0 > <0006> scheduler.c:1393 Set mode 3, 0, handover 0 on SDCCH/4(0) of trx=0 ts=0 > <0006> scheduler.c:1458 Set a5/0 uplink for SDCCH/4(0) on trx=0 ts=0 > <0006> scheduler.c:1458 Set a5/0 uplink for SACCH/4(0) on trx=0 ts=0 > <0006> scheduler.c:1458 Set a5/0 downlink for SDCCH/4(0) on trx=0 ts=0 > <0006> scheduler.c:1458 Set a5/0 downlink for SACCH/4(0) on trx=0 ts=0 > <0000> rsl.c:559 (bts=0,trx=0,ts=0,ss=0) Tx CHAN ACT ACK > <000b> trx_if.c:485 Tx burst length 0 invalid > <0000> rsl.c:2236 (bts=0,trx=0,ts=0,ss=0) Rx RSL IMM_ASS_CMD > <000b> trx_if.c:485 Tx burst length 0 invalid > <000b> trx_if.c:485 Tx burst length 0 invalid > <000b> trx_if.c:485 Tx burst length 0 invalid > <0006> scheduler_trx.c:867 Received incomplete data frame at fn=0 (0/102) for SDCCH/4(0) > <0006> scheduler_trx.c:867 Received incomplete data frame at fn=0 (0/102) for SACCH/4(0) > <0000> rsl.c:2290 (bts=0,trx=0,ts=0,ss=0) Rx RSL DEACTIVATE_SACCH > <0006> scheduler.c:1344 Deactivating SACCH/4(0) on trx=0 ts=0 > <0000> rsl.c:2290 (bts=0,trx=0,ts=0,ss=0) Rx RSL RF_CHAN_REL > <0006> scheduler.c:1344 Deactivating SDCCH/4(0) on trx=0 ts=0 > <0000> rsl.c:519 (bts=0,trx=0,ts=0,ss=0) Tx RF CHAN REL ACK > <0006> scheduler_trx.c:867 Received incomplete data frame at fn=1421484 (12/104) for PTCCH > <0006> scheduler_trx.c:867 Received incomplete data frame at fn=1421484 (12/104) for PTCCH > <0000> rsl.c:2209 (bts=0,trx=0,ts=0,ss=4) Fwd RLL msg CHAN_RQD from LAPDm to A-bis > <0000> rsl.c:2290 (bts=0,trx=0,ts=2,ss=0) Rx RSL CHAN_ACTIV > <0000> rsl.c:926 chan_nr=0x0a type=0x00 mode=0x00 > <0006> scheduler.c:1344 Activating TCH/F on trx=0 ts=2 > <0006> scheduler.c:1344 Activating SACCH/TF on trx=0 ts=2 > <0006> scheduler.c:1393 Set mode 3, 0, handover 0 on TCH/F of trx=0 ts=2 > <0006> scheduler.c:1393 Set mode 3, 0, handover 0 on PDTCH of trx=0 ts=2 > <0006> scheduler.c:1393 Set mode 3, 0, handover 0 on PTCCH of trx=0 ts=2 > <0006> scheduler.c:1458 Set a5/0 uplink for TCH/F on trx=0 ts=2 > <0006> scheduler.c:1458 Set a5/0 uplink for SACCH/TF on trx=0 ts=2 > <0006> scheduler.c:1458 Set a5/0 downlink for TCH/F on trx=0 ts=2 > <0006> scheduler.c:1458 Set a5/0 downlink for SACCH/TF on trx=0 ts=2 > <0000> rsl.c:559 (bts=0,trx=0,ts=2,ss=0) Tx CHAN ACT ACK > <0000> rsl.c:2236 (bts=0,trx=0,ts=0,ss=0) Rx RSL IMM_ASS_CMD > <0006> scheduler.c:267 Prim for trx=0 ts=2 at fn=1085114 is out of range, or channel already disabled. If this happens in conjunction with PCU, increase 'rts-advance' by 5. (current fn=1436721) > <0006> scheduler_trx.c:1054 Received incomplete TCH frame ending at fn=1436997 (29/104) for TCH/F > <0006> gsm0503_coding.c:1690 tch_fr_decode(): error decoding FACCH frame (399/456 bits) > <0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1436997 for TCH/F > <0006> gsm0503_coding.c:1690 tch_fr_decode(): error decoding FACCH frame (286/456 bits) > <0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1437213 for TCH/F > <0006> gsm0503_coding.c:1706 tch_fr_decode(): error checking CRC8 for the FR part of an FR frame > <0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1438301 for TCH/F > <0006> scheduler_trx.c:1054 Received incomplete TCH frame ending at fn=1438522 (98/104) for TCH/F > <0006> gsm0503_coding.c:1690 tch_fr_decode(): error decoding FACCH frame (159/456 bits) > <0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1438522 for TCH/F > <0006> scheduler_trx.c:1054 Received incomplete TCH frame ending at fn=1438652 (20/104) for TCH/F > <0006> gsm0503_coding.c:1706 tch_fr_decode(): error checking CRC8 for the FR part of an FR frame > <0006> scheduler_trx.c:1104 Received bad TCH frame ending at fn=1438652 for TCH/F > <0000> rsl.c:2290 (bts=0,trx=0,ts=2,ss=0) Rx RSL DEACTIVATE_SACCH > <0006> scheduler.c:1344 Deactivating SACCH/TF on trx=0 ts=2 > <0000> rsl.c:2290 (bts=0,trx=0,ts=2,ss=0) Rx RSL RF_CHAN_REL > <0006> scheduler.c:1344 Deactivating TCH/F on trx=0 ts=2 > <0000> rsl.c:519 (bts=0,trx=0,ts=2,ss=0) Tx RF CHAN REL ACK > <0006> scheduler_trx.c:867 Received incomplete data frame at fn=1462772 (12/104) for PTCCH > > BSC log Snippet : > > OpenBSC# <0000> chan_alloc.c:342 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH > <0004> abis_rsl.c:1727 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(990) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0d ta=0 > <0004> abis_rsl.c:536 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL > <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED > <0004> abis_rsl.c:1456 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK > <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE > <0004> abis_rsl.c:806 (bts=0,trx=0,ts=0,ss=0) RF Channel Release CMD due error 1 > <0004> abis_rsl.c:718 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD > <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR > <0004> abis_rsl.c:863 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK > <0004> abis_rsl.c:767 (bts=0,trx=0,ts=0,ss=0) is back in operation. > <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE > <0000> chan_alloc.c:342 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Allocating lchan=0 as SDCCH > <0004> abis_rsl.c:1727 (bts=0,trx=0,ts=0,ss=0) Activating ARFCN(990) SS(0) lctype SDCCH r=LOCATION_UPDATE ra=0x0b ta=0 > <0004> abis_rsl.c:536 (bts=0,trx=0,ts=0,pchan=CCCH+SDCCH4) Tx RSL Channel Activate with act_type=INITIAL > <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state NONE -> ACTIVATION REQUESTED > <0004> abis_rsl.c:1456 (bts=0,trx=0,ts=0,ss=0) CHANNEL ACTIVATE ACK > <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVATION REQUESTED -> ACTIVE > <0004> abis_rsl.c:806 (bts=0,trx=0,ts=0,ss=0) RF Channel Release CMD due error 1 > <0004> abis_rsl.c:718 (bts=0,trx=0,ts=0,ss=0) DEACTivate SACCH CMD > <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state ACTIVE -> RELEASE DUE ERROR > <0004> abis_rsl.c:863 (bts=0,trx=0,ts=0,ss=0) RF CHANNEL RELEASE ACK > <0004> abis_rsl.c:767 (bts=0,trx=0,ts=0,ss=0) is back in operation. > <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=0,ss=0) state RELEASE DUE ERROR -> NONE > <0000> chan_alloc.c:342 (bts=0,trx=0,ts=2,pchan=TCH/F) Allocating lchan=0 as TCH_F > <0004> abis_rsl.c:1727 (bts=0,trx=0,ts=2,ss=0) Activating ARFCN(990) SS(0) lctype TCH_F r=OTHER ra=0xe7 ta=0 > <0004> abis_rsl.c:536 (bts=0,trx=0,ts=2,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL > <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state NONE -> ACTIVATION REQUESTED > <0004> abis_rsl.c:1456 (bts=0,trx=0,ts=2,ss=0) CHANNEL ACTIVATE ACK > <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state ACTIVATION REQUESTED -> ACTIVE > <0004> abis_rsl.c:806 (bts=0,trx=0,ts=2,ss=0) RF Channel Release CMD due error 1 > <0004> abis_rsl.c:718 (bts=0,trx=0,ts=2,ss=0) DEACTivate SACCH CMD > <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state ACTIVE -> RELEASE DUE ERROR > <0004> abis_rsl.c:863 (bts=0,trx=0,ts=2,ss=0) RF CHANNEL RELEASE ACK > <0004> abis_rsl.c:767 (bts=0,trx=0,ts=2,ss=0) is back in operation. > <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=2,ss=0) state RELEASE DUE ERROR -> NONE > > > Note : We are using internal clock of osmo-trx no external Clock is connected. > > Thanks and Regards, > Mrinal -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mrinal.Mishra at radisys.com Wed Sep 14 11:58:00 2016 From: Mrinal.Mishra at radisys.com (Mrinal Mishra) Date: Wed, 14 Sep 2016 11:58:00 +0000 Subject: MS Initial Registration failure observed in osmo-trx setup In-Reply-To: <815661E7-8806-4975-B4BE-8BE2A3B04E4E@gmail.com> References: <815661E7-8806-4975-B4BE-8BE2A3B04E4E@gmail.com> Message-ID: From: sami [mailto:sami.0jacob0 at gmail.com] > I had the same problem. Most probably this is due to the UHD version you are using, if you use older than version 3.9 you should be OK. Thanks for your input. This is the output from our setup mrinal at tenet-GA-MA69VM-S2:~$uhd_find_devices linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.011.000.git-47-g3e352429 Is this the thing which you were referring. Please let us know if this UHD version is fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.0jacob0 at gmail.com Wed Sep 14 13:05:47 2016 From: sami.0jacob0 at gmail.com (sami) Date: Wed, 14 Sep 2016 16:05:47 +0300 Subject: MS Initial Registration failure observed in osmo-trx setup In-Reply-To: References: <815661E7-8806-4975-B4BE-8BE2A3B04E4E@gmail.com> Message-ID: this is 3.11, try 3.7 or 3.8. On Sep 14, 2016, at 2:58 PM, Mrinal Mishra wrote: > From: sami [mailto:sami.0jacob0 at gmail.com] > > I had the same problem. Most probably this is due to the UHD version you are using, if you use older than version 3.9 you should be OK. > Thanks for your input. This is the output from our setup > mrinal at tenet-GA-MA69VM-S2:~$uhd_find_devices > linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.011.000.git-47-g3e352429 > Is this the thing which you were referring. Please let us know if this UHD version is fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.0jacob0 at gmail.com Wed Sep 14 13:07:46 2016 From: sami.0jacob0 at gmail.com (sami) Date: Wed, 14 Sep 2016 16:07:46 +0300 Subject: MS Initial Registration failure observed in osmo-trx setup In-Reply-To: References: <815661E7-8806-4975-B4BE-8BE2A3B04E4E@gmail.com> Message-ID: you should download and install from here: https://github.com/EttusResearch/uhd/releases On Sep 14, 2016, at 2:58 PM, Mrinal Mishra wrote: > From: sami [mailto:sami.0jacob0 at gmail.com] > > I had the same problem. Most probably this is due to the UHD version you are using, if you use older than version 3.9 you should be OK. > Thanks for your input. This is the output from our setup > mrinal at tenet-GA-MA69VM-S2:~$uhd_find_devices > linux; GNU C++ version 4.8.4; Boost_105400; UHD_003.011.000.git-47-g3e352429 > Is this the thing which you were referring. Please let us know if this UHD version is fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexander.Chemeris at fairwaves.co Wed Sep 14 14:16:42 2016 From: Alexander.Chemeris at fairwaves.co (Alexander Chemeris) Date: Wed, 14 Sep 2016 17:16:42 +0300 Subject: GSM 05.03 code re-licensing In-Reply-To: References: Message-ID: Harald, the background information is very helpful. I'm ok with re-licensing to GPLv2. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co On Sep 13, 2016 4:54 PM, "Tom Tsou" wrote: > Harald, > > Thanks for the context and background information. > > On Sat, Sep 10, 2016 at 10:09 PM, Vadim Yanitskiy > wrote: > > Right now I am moving some code from OsmoBTS to libosmocore, > > exactly OsmoBTS/src/osmo-bts-trx/gsm0503*. And there is a > > licensing conflict, because this code licensed under AGPLv3+, > > but libosmocore code is GPLv2+. > > > > So, this is why I am contacting all authors/copyright holders. > > The question is: does everyone agree to re-license the code > > under GPLv2-or-later and move it code to libosmocore? > > I agree with the current consensus to re-license GSM 05.03 code from > AGPLv3 to GPLv2+ for inclusion into libosmocore. > > -TT > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mayuri.tendulkar at gmail.com Thu Sep 15 05:02:09 2016 From: mayuri.tendulkar at gmail.com (Mayuri Tendulkar) Date: Thu, 15 Sep 2016 10:32:09 +0530 Subject: Query regarding Loopback support in Osmobts Message-ID: Hi We are looking for a feature at L1 Physical layer loopback in Osmo-bts-trx. Is this feature available and how it can be tested? Regards Mayuri -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhananjay.cse at gmail.com Fri Sep 16 10:48:58 2016 From: dhananjay.cse at gmail.com (Dhananjay kumar) Date: Fri, 16 Sep 2016 16:18:58 +0530 Subject: Loopback call on osmo-bts Message-ID: Hi all, I am trying to make loopback call on osmo-bts VTY interface using ettus B200/B210 hw. in vty.c file i can see options available for loopback call , but loopback call is not started once triggered from osmobts VTY interface. Can some one help ? DEFUN(bts_t_t_l_loopback, bts_t_t_l_loopback_cmd, "bts <0-0> trx <0-0> ts <0-7> lchan <0-1> loopback", BTS_T_T_L_STR "Set loopback\n") -- Thanks & Regards Dhananjay 9686184214 Luck is what happens when preparation meets opportunity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nhofmeyr at sysmocom.de Mon Sep 19 15:16:36 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Mon, 19 Sep 2016 17:16:36 +0200 Subject: New Defects reported by Coverity Scan for Osmocom In-Reply-To: <57dfe1f59c246_4b6c69533446286@ss1435.mail> References: <57dfe1f59c246_4b6c69533446286@ss1435.mail> Message-ID: <20160919151636.GA9967@dub7> On Mon, Sep 19, 2016 at 06:02:45AM -0700, scan-admin at coverity.com wrote: > > Hi, > > Please find the latest report on new defect(s) introduced to Osmocom found with Coverity Scan. > > 5 new defect(s) introduced to Osmocom found with Coverity Scan. > 6 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. > > New defect(s) Reported-by: Coverity Scan > Showing 5 of 5 defect(s) > > > ** CID 148210: Error handling issues (NEGATIVE_RETURNS) > /source-iuh/openbsc/openbsc/src/gprs/gprs_llc.c: 273 in rx_llc_xid() > > > ________________________________________________________________________________________________________ > *** CID 148210: Error handling issues (NEGATIVE_RETURNS) > /source-iuh/openbsc/openbsc/src/gprs/gprs_llc.c: 273 in rx_llc_xid() > 267 > 268 response_len = > 269 gprs_llc_process_xid_ind(gph->data, gph->data_len, > 270 response, sizeof(response), > 271 lle); > 272 xid = msgb_put(resp, response_len); > >>> CID 148210: Error handling issues (NEGATIVE_RETURNS) > >>> "response_len" is passed to a parameter that cannot be negative. @dexter ^ check that response_len > 0 > 273 memcpy(xid, response, response_len); > 274 > 275 gprs_llc_tx_xid(lle, resp, 0); > 276 } else { > 277 LOGP(DLLC, LOGL_NOTICE, > 278 "Received XID confirmation from phone.\n"); > > ** CID 148209: Control flow issues (MISSING_BREAK) > /source-iuh/openbsc/openbsc/src/libmsc/db.c: 414 in check_db_revision() > > > ________________________________________________________________________________________________________ > *** CID 148209: Control flow issues (MISSING_BREAK) > /source-iuh/openbsc/openbsc/src/libmsc/db.c: 414 in check_db_revision() > 408 > 409 /* Incremental migration waterfall */ > 410 switch (db_rev) { > 411 case 2: > 412 if (update_db_revision_2()) > 413 goto error; > >>> CID 148209: Control flow issues (MISSING_BREAK) > >>> The above case falls through to this one. add: /* fall through */ ? > 414 case 3: > 415 if (update_db_revision_3()) > 416 goto error; > 417 > 418 /* The end of waterfall */ > 419 break; > > ** CID 148208: Control flow issues (DEADCODE) > /source-iuh/openbsc/openbsc/src/osmo-bsc/osmo_bsc_ctrl.c: 408 in set_net_timezone() > > > ________________________________________________________________________________________________________ > *** CID 148208: Control flow issues (DEADCODE) > >>> CID 148208: Control flow issues (DEADCODE) > >>> Execution cannot reach the expression "0L" inside this statement: "tz->hr = (hourstr ? atol(ho...". The website has more detail: " > static int set_net_timezone(struct ctrl_cmd *cmd, void *data) > 386{ > 387 char *saveptr, *hourstr, *minstr, *dststr, *tmp = 0; > 388 int override; > 389 struct gsm_network *net = (struct gsm_network*)cmd->node; > 390 > 391 tmp = talloc_strdup(cmd, cmd->value); > 392 if (!tmp) > 393 goto oom; > 394 > 395 hourstr = strtok_r(tmp, ",", &saveptr); > 396 minstr = strtok_r(NULL, ",", &saveptr); > 397 dststr = strtok_r(NULL, ",", &saveptr); > 398 > 399 override = 0; > 400 cond_notnull: Condition hourstr != NULL, taking true branch. Now the value of hourstr is not NULL. > 401 if (hourstr != NULL) > 402 override = strcasecmp(hourstr, "off") != 0; > 403 > 404 struct gsm_tz *tz = &net->tz; > 405 tz->override = override; > 406 > 407 if (override) { notnull: At condition hourstr, the value of hourstr cannot be NULL. dead_error_condition: The condition hourstr must be true. CID 148208 (#1 of 1): Logically dead code (DEADCODE)dead_error_line: Execution cannot reach the expression 0L inside this statement: tz->hr = (hourstr ? atol(ho.... > 408 tz->hr = hourstr ? atol(hourstr) : 0; > 409 tz->mn = minstr ? atol(minstr) : 0; > 410 tz->dst = dststr ? atol(dststr) : 0; > 411 } > 412 > 413 talloc_free(tmp); > 414 tmp = NULL; > 415 > 416 return get_net_timezone(cmd, data); > 417 > 418oom: > 419 cmd->reply = "OOM"; > 420 return CTRL_CMD_ERROR; > 421} " So override == 0 by default. override will only be set if hourstr != NULL. So inside 'if (override)', hourstr will always be != NULL, and the first '?' is superfluous. This exists since the function was added in 2013. > ________________________________________________________________________________________________________ > *** CID 148207: Control flow issues (MISSING_BREAK) > /source-iuh/openbsc/openbsc/src/libbsc/abis_rsl.c: 415 in channel_mode_from_lchan() > 409 default: > 410 LOGP(DRSL, LOGL_ERROR, > 411 "unsupported lchan->csd_mode %u\n", > 412 lchan->csd_mode); > 413 return -EINVAL; > 414 } > >>> CID 148207: Control flow issues (MISSING_BREAK) > >>> The above case falls through to this one. This missing 'break' is an error introduced in e4227988665cae6e44fc0f77c2463aae759f15ca "RSL: Add basic support for CSD transparent mode" > 415 default: > 416 LOGP(DRSL, LOGL_ERROR, > 417 "unsupported lchan->tch_mode %u\n", > 418 lchan->tch_mode); > 419 return -EINVAL; > 420 } > > ** CID 148206: Security best practices violations (DC.WEAK_CRYPTO) > /source-iuh/openbsc/openbsc/src/gprs/gprs_gmm.c: 560 in gsm48_tx_gmm_auth_ciph_req() > > > ________________________________________________________________________________________________________ > *** CID 148206: Security best practices violations (DC.WEAK_CRYPTO) > /source-iuh/openbsc/openbsc/src/gprs/gprs_gmm.c: 560 in gsm48_tx_gmm_auth_ciph_req() > 554 /* 10.5.5.7: */ > 555 acreq->force_stby = force_standby; > 556 /* 3GPP TS 24.008 10.5.5.19: */ > 557 if (RAND_bytes(&rbyte, 1) != 1) { > 558 LOGP(DMM, LOGL_NOTICE, "RAND_bytes failed for A&C ref, falling " > 559 "back to rand()\n"); > >>> CID 148206: Security best practices violations (DC.WEAK_CRYPTO) > >>> "rand" should not be used for security related applications, as linear congruential algorithms are too easy to break. well spotted, coverity :) Do they actually analyse whether that it is security related code? rand() is only the fallback for RAND_bytes(). ~Neels > 560 acreq->ac_ref_nr = rand(); > 561 } else > 562 acreq->ac_ref_nr = rbyte; > 563 mm->ac_ref_nr_used = acreq->ac_ref_nr; > 564 > 565 /* Only if authentication is requested we need to set RAND + CKSN */ > > > ________________________________________________________________________________________________________ > To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRZRgA0iChuO-2FGX0POK2RKsukBc1qHTwF2SHZpn6wOsolg-3D-3D_NeAJonveXivhzKyNx2umY31POArq17SmfipFEiTlbGEUEBBX9q2-2Ffp-2F8rVN3pZZhaIIJzuvyja9oX7zLeVod5CBloE2bNBsLMdq8vm8DwA4jz1vMIXKsvdJCo2dRiN0dLrWaTsM2iRtEWvVozsL8UDeM9yM6-2F2BIGt-2B16Y9D-2BQ8BbCg6SoNlU9hQz94ehIdlkNJbMmEwt26bsVaXK41zwg-3D-3D > > To manage Coverity Scan email notifications for "nhofmeyr at sysmocom.de", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V05UPxvVjWch-2Bd2MGckcRbVDbis712qZDP-2FA8y06Nq4VngPiVJb2v7ebXRF7QR8XkZ9r0tTrYp-2F0MW-2FEWllzpkyCC83LXF7q-2FHm2-2BquI0NN6y2ZgcVxPTvklWSJL2RR9R8Aq2Y2qnMdw30sEcvVsU8-3D_NeAJonveXivhzKyNx2umY31POArq17SmfipFEiTlbGEUEBBX9q2-2Ffp-2F8rVN3pZZhXX1scEo5tl4BXS4c8ZAYMpsh3qS3-2B6s0GpetAuas0BozvqlhP3mPN-2FpUsNIgsEs4-2FKN-2FWK3a4sXMQ-2FlZAsLPAq6wElxzIyBZHzt67dR8y8NfBpESjEzS5WBqF8WaJwKLMLGTnP4R4pKt5nYl889UXg-3D-3D > -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Tue Sep 20 10:01:57 2016 From: msuraev at sysmocom.de (Max) Date: Tue, 20 Sep 2016 12:01:57 +0200 Subject: libosmo-abis question Message-ID: <1008ef15-8aaf-e9e0-fcbd-fb53d14722ac@sysmocom.de> Hi. Coverity have noticed weird piece of code in libosmo-abis osmo_rtp_socket_fdreg(): ... rs->rtp_bfd.when = rs->rtcp_bfd.when = BSC_FD_READ; rs->rtp_bfd.when = rs->rtcp_bfd.when = 0; ... It's on the border between 2 commits so it's likely merge artifact. Which value is the right one? Or should it be rtcp_bfd? -- Max Suraev 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 From dhananjay.cse at gmail.com Tue Sep 20 10:35:40 2016 From: dhananjay.cse at gmail.com (Dhananjay kumar) Date: Tue, 20 Sep 2016 16:05:40 +0530 Subject: Query on run time control of network with VTY Message-ID: Hi, While ruining osmo-bts and osmo-trx via VTY we tried to change parameter like Band ,ARFCN MS max power. We observed that once ARFCN is changed on VTY TRX does not switch to new ARFCN. Same behavior has been observed with Band and MS-Max-Power and RF-Locked 0/1 parameter. Request someone who is running osmo-stack has controlled network ,please reply or any document/pointer is appreciated. BR Dhananjay -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Tue Sep 20 14:05:10 2016 From: holger at freyther.de (Holger Freyther) Date: Tue, 20 Sep 2016 16:05:10 +0200 Subject: Query on run time control of network with VTY In-Reply-To: References: Message-ID: > On 20 Sep 2016, at 12:35, Dhananjay kumar wrote: > Dear Dhananjay, > While ruining osmo-bts and osmo-trx via VTY we tried to change parameter like Band ,ARFCN MS max power. > > We observed that once ARFCN is changed on VTY TRX does not switch to new ARFCN. > Same behavior has been observed with Band and MS-Max-Power and RF-Locked 0/1 parameter. > > Request someone who is running osmo-stack has controlled network ,please reply or any document/pointer is appreciated. few VTY parameters are applied right-away. We have: * Some parameters are applied on restart only (e.g. channel combination of a BTS) * Some on new BTS connection (e.g. arfcn) * Some on next MS connection It would be nice if you could help us by first documenting when/which change is applied and maybe help on creating a concept for consistent handling. E.g. a lot of other equipment requires to bring a system into a "lock" state, do the modification, unlock (the time things will be applied). holger From hwelte at sysmocom.de Tue Sep 20 14:31:18 2016 From: hwelte at sysmocom.de (Harald Welte) Date: Tue, 20 Sep 2016 22:31:18 +0800 Subject: libosmo-abis question In-Reply-To: <1008ef15-8aaf-e9e0-fcbd-fb53d14722ac@sysmocom.de> References: <1008ef15-8aaf-e9e0-fcbd-fb53d14722ac@sysmocom.de> Message-ID: <20160920143118.nmiqmmfa2tvydxtj@nataraja> Hi Max, On Tue, Sep 20, 2016 at 12:01:57PM +0200, Max wrote: > rs->rtp_bfd.when = rs->rtcp_bfd.when = BSC_FD_READ; > rs->rtp_bfd.when = rs->rtcp_bfd.when = 0; > > It's on the border between 2 commits so it's likely merge artifact. > Which value is the right one? Or should it be rtcp_bfd? I think both BSC_FD_READ as well as 0 should work, see the comment in osmo_rtcp_fd_cb(). So either the RTCP data will be read/received inside rtp_session_recvm_with_ts() (rtcp_bfd.when == 0), or it will be explicitly processed by the call to rtp_session_rtcp_recv() from osmo_rtcp_fd_cb() in the rtcp_bfd.when == BSC_FD_READ case. The explicit call might be the better/nicer way, so I'd go for BSC_FD_READ, unless we experience problems with that. -- - Harald Welte 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 From msuraev at sysmocom.de Tue Sep 20 16:52:07 2016 From: msuraev at sysmocom.de (Max) Date: Tue, 20 Sep 2016 18:52:07 +0200 Subject: RFC: use AddressSanitizer by default in gerrit Message-ID: Hi. When gerrit check the patch it only cares about "make check" result. There's also a way to use AddressSanitizer for a given branch via http://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/ I've just sent patch which fixes latest missing bit in libosmocore which enables running AddressSanitizer with "make check" - see gerrit #863. When this is merged we can enable AddressSanitizer for the "make check" used by gerrit to verify patch submissions. What do you think? Note: we can't enable it yet for OpenBSC but all the libraries seems to be fine. -- Max Suraev 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 From dhananjay.cse at gmail.com Wed Sep 21 12:17:34 2016 From: dhananjay.cse at gmail.com (Dhananjay kumar) Date: Wed, 21 Sep 2016 17:47:34 +0530 Subject: Query on run time control of network with VTY In-Reply-To: References: Message-ID: Dear Holger, Many thanks for your mail. Based on your suggestion we did experiment on B210 with osmo-stack for run-time network parameter control from VTY. - Parameter change related to MS takes effects when New MS is latches to Network. Example : MS_Max_Power - Parameter change related to TRX takes effects when TRX is re-started. Example : RF_Lock 0 - Parameter change related to BTS takes effects when BTS and TRX is restared. Example : Band/ARFCN One more query regarding loop-back call : "bts <0-0> trx <0-0> ts <0-7> lchan <0-1> loopback", we tried this command to start loop-back call once MS is registered to the network. But we are not seeing any loop-back call happening in nitb and osmo-bts logs. Could you please let us know more on this loop-back call. How we can use this ? BR Dhananjay On Tue, Sep 20, 2016 at 7:35 PM, Holger Freyther wrote: > > > On 20 Sep 2016, at 12:35, Dhananjay kumar > wrote: > > > > Dear Dhananjay, > > > While ruining osmo-bts and osmo-trx via VTY we tried to change > parameter like Band ,ARFCN MS max power. > > > > We observed that once ARFCN is changed on VTY TRX does not switch to new > ARFCN. > > Same behavior has been observed with Band and MS-Max-Power and RF-Locked > 0/1 parameter. > > > > Request someone who is running osmo-stack has controlled network ,please > reply or any document/pointer is appreciated. > > > few VTY parameters are applied right-away. We have: > > * Some parameters are applied on restart only (e.g. channel combination of > a BTS) > * Some on new BTS connection (e.g. arfcn) > * Some on next MS connection > > It would be nice if you could help us by first documenting when/which > change is applied and maybe help on creating a concept for consistent > handling. E.g. a lot of other equipment requires to bring a system into a > "lock" state, do the modification, unlock (the time things will be applied). > > > holger -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Wed Sep 21 12:19:49 2016 From: holger at freyther.de (Holger Freyther) Date: Wed, 21 Sep 2016 14:19:49 +0200 Subject: Query on run time control of network with VTY In-Reply-To: References: Message-ID: > On 21 Sep 2016, at 14:17, Dhananjay kumar wrote: > > Dear Holger, Hi! > Many thanks for your mail. > Based on your suggestion we did experiment on B210 with osmo-stack for run-time network parameter control from VTY. > > ? Parameter change related to MS takes effects when New MS is latches to Network. Example : MS_Max_Power > ? Parameter change related to TRX takes effects when TRX is re-started. Example : RF_Lock 0 > ? Parameter change related to BTS takes effects when BTS and TRX is restared. Example : Band/ARFCN > One more query regarding loop-back call : > "bts <0-0> trx <0-0> ts <0-7> lchan <0-1> loopback", > please consider contributing this to our manual. Together the software is moving forward. thank you holger From nhofmeyr at sysmocom.de Wed Sep 21 14:25:00 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 21 Sep 2016 16:25:00 +0200 Subject: coverity for osmocom projects Message-ID: <20160921142500.GB1463@dub7> Today, I've taken a quick look at the coverity stuff, because so far I've only seen coverity reports on the Iu code. I see now that actually all of the other osmocom components are also tested by coverity. So far I'm only seeing the "Osmocom" coverity project, which contains only the iu build. In fact that's a bit of a misnomer -- I assumed that "Osmocom" would contain all of the osmos, it should be more like 'Osmocom-3G' or 'Osmocom-Iu'. The other osmos are in coverity projects named "libosmocore", "osmo-bts", etc: https://scan.coverity.com/projects?utf8=%E2%9C%93&search=osmo I see there are "add me to project" buttons e.g. here https://scan.coverity.com/projects/libosmocore so I'm trying that now. Wouldn't it make sense to redirect all the coverity reports to a mailing list? Probably best would be a new mailing list, to avoid noise on openbsc@, like the gerrit-log@ list. Are these coverity reports a matter of secrecy, to avoid publishing security holes before we fixed them, in which case the coverity mailing list should be invite-only? ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed Sep 21 14:29:15 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 21 Sep 2016 16:29:15 +0200 Subject: coverity for osmocom projects In-Reply-To: <20160921142500.GB1463@dub7> References: <20160921142500.GB1463@dub7> Message-ID: <20160921142915.GC1463@dub7> On Wed, Sep 21, 2016 at 04:25:00PM +0200, Neels Hofmeyr wrote: > I see there are "add me to project" buttons e.g. here > https://scan.coverity.com/projects/libosmocore > so I'm trying that now. It seems at most 3 are allowed to be pending :/ ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From msuraev at sysmocom.de Wed Sep 21 14:41:12 2016 From: msuraev at sysmocom.de (Max) Date: Wed, 21 Sep 2016 16:41:12 +0200 Subject: coverity for osmocom projects In-Reply-To: <20160921142500.GB1463@dub7> References: <20160921142500.GB1463@dub7> Message-ID: <797609fd-f8f1-6fd4-1b0e-e8b16628d094@sysmocom.de> Curiously, I see that there are no successful builds for osmo-trx with the advice to contact project owner. Who's that in case of osmo-trx and why builds are failing? -- Max Suraev 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 From nhofmeyr at sysmocom.de Wed Sep 21 15:16:27 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 21 Sep 2016 17:16:27 +0200 Subject: bts lchan loopback vty command -- was: Query on run time control of network with VTY In-Reply-To: References: Message-ID: <20160921151627.GE1463@dub7> On Wed, Sep 21, 2016 at 05:47:34PM +0530, Dhananjay kumar wrote: > One more query regarding loop-back call : > "bts <0-0> trx <0-0> ts <0-7> lchan <0-1> loopback", > > we tried this command to start loop-back call once MS is registered to the > network. > But we are not seeing any loop-back call happening in nitb and osmo-bts > logs. This command only sets a loopback flag on a given lchan and does not actually initiate a call. IIUC after setting the loopback, the loopback should happen when you make a voice call using that time slot and lchan. It might make more sense to start a call and set the loopback on the lchan while the call is active. So this does not replace the other MS. From the code it seems the loopback flag is not cleared before / after a voice call, so it looks like the given lchan will remain a loopback for any number of calls (that end up on that lchan). I'm not 100% sure though, only skimmed the code briefly, I've never used this before. ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed Sep 21 21:01:01 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 21 Sep 2016 23:01:01 +0200 Subject: coverity for osmocom projects In-Reply-To: <797609fd-f8f1-6fd4-1b0e-e8b16628d094@sysmocom.de> References: <20160921142500.GB1463@dub7> <797609fd-f8f1-6fd4-1b0e-e8b16628d094@sysmocom.de> Message-ID: <20160921210101.GA1210@dub7> On Wed, Sep 21, 2016 at 04:41:12PM +0200, Max wrote: > Curiously, I see that there are no successful builds for osmo-trx with > the advice to contact project owner. Who's that in case of osmo-trx and > why builds are failing? The reason is very simple -- it is completely omitted from the coverity build scripts :) I could try to add it... ~Neels -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From nhofmeyr at sysmocom.de Wed Sep 21 21:21:45 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Wed, 21 Sep 2016 23:21:45 +0200 Subject: coverity for osmocom projects In-Reply-To: <20160921210101.GA1210@dub7> References: <20160921142500.GB1463@dub7> <797609fd-f8f1-6fd4-1b0e-e8b16628d094@sysmocom.de> <20160921210101.GA1210@dub7> Message-ID: <20160921212145.GB1210@dub7> On Wed, Sep 21, 2016 at 11:01:01PM +0200, Neels Hofmeyr wrote: > On Wed, Sep 21, 2016 at 04:41:12PM +0200, Max wrote: > > Curiously, I see that there are no successful builds for osmo-trx with > > the advice to contact project owner. Who's that in case of osmo-trx and > > why builds are failing? > > I could try to add it... After apt-get install --no-install-recommends libuhd-dev uhd-host libusb-1.0-0-dev libboost-dev I have successfully built osmo-trx on our build machine. So, Holger, if you felt so inclined: put the upload_trx function from coverity_test_osmo_trx.sh into coverity_all.sh and uncomment + put the proper coverity token in it, that should enable osmo-trx on coverity. And then rm coverity_test_osmo_trx.sh... ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From holger at freyther.de Thu Sep 22 20:03:54 2016 From: holger at freyther.de (Holger Freyther) Date: Thu, 22 Sep 2016 22:03:54 +0200 Subject: coverity for osmocom projects In-Reply-To: <20160921212145.GB1210@dub7> References: <20160921142500.GB1463@dub7> <797609fd-f8f1-6fd4-1b0e-e8b16628d094@sysmocom.de> <20160921210101.GA1210@dub7> <20160921212145.GB1210@dub7> Message-ID: <206BB87C-28C8-4115-890D-4735AF8B79D7@freyther.de> > On 21 Sep 2016, at 23:21, Neels Hofmeyr wrote: > > On Wed, Sep 21, 2016 at 11:01:01PM +0200, Neels Hofmeyr wrote: >> On Wed, Sep 21, 2016 at 04:41:12PM +0200, Max wrote: >>> Curiously, I see that there are no successful builds for osmo-trx with >>> the advice to contact project owner. Who's that in case of osmo-trx and >>> why builds are failing? >> >> I could try to add it... > > After > apt-get install --no-install-recommends libuhd-dev uhd-host libusb-1.0-0-dev libboost-dev > I have successfully built osmo-trx on our build machine. > > So, Holger, if you felt so inclined: put the upload_trx function from > coverity_test_osmo_trx.sh into coverity_all.sh and uncomment + put the proper > coverity token in it, that should enable osmo-trx on coverity. just go ahead and enable it. Let's copy the build scripts into the osmo-ci repository as well. Maybe we find another way to pass in the secret token (read from a file?) thank you holger From fanx07 at gmail.com Fri Sep 23 09:22:51 2016 From: fanx07 at gmail.com (Anonim Stefan) Date: Fri, 23 Sep 2016 12:22:51 +0300 Subject: osmo-sip-connector issue Message-ID: Hi, I am using osmo-nitb + osmo-sip-connector and I am sending INVITE to it, as in the attached trace. The connector replies with 0.0.0.0 RTP IP and 0/unknown codec and then ends the call. I am seeing the following log: " Sep 23 09:08:00 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> mncc.c:334 call(1073741832) can not be found Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0002> app.c:104 Unknown ptmsg(0). call broken Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> mncc.c:312 leg(5001) rtp connect failed Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> sip.c:245 Ending leg(0x91ec30) in con Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> mncc.c:304 leg(1073741832) can not be found Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> sip.c:186 leg(0x91ec30) got bye, releasing. " This issue happens *after* *recently* *updated* *packages* to: " ii osmocom-nitb 0.15.1.20160922 amd64 GSM Network-in-a-Box, implements BSC, MSC, SMSC, HLR, VLR ii osmo-sip-connector 1.20160922 amd64 MNCC to SIP bridge for osmo-nitb " On the osmo-nitb side I am seeing logs [1]. I suspect a bug in the osmo-sip-connector code. Can someone confirm this? [1] http://pastebin.com/giG0HHha -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-sip-connector.pcap Type: application/vnd.tcpdump.pcap Size: 6880 bytes Desc: not available URL: From holger at freyther.de Fri Sep 23 14:36:34 2016 From: holger at freyther.de (Holger Freyther) Date: Fri, 23 Sep 2016 16:36:34 +0200 Subject: osmo-sip-connector issue In-Reply-To: References: Message-ID: > On 23 Sep 2016, at 11:22, Anonim Stefan wrote: > > Hi, > > I am using osmo-nitb + osmo-sip-connector and I am sending INVITE to it, as in the attached trace. The connector replies with 0.0.0.0 RTP IP and 0/unknown codec and then ends the call. I am seeing the following log: > " > Sep 23 09:08:00 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> mncc.c:334 call(1073741832) can not be found > Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0002> app.c:104 Unknown ptmsg(0). call broken > Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> mncc.c:312 leg(5001) rtp connect failed > Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> sip.c:245 Ending leg(0x91ec30) in con > Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> mncc.c:304 leg(1073741832) can not be found > Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> sip.c:186 leg(0x91ec30) got bye, releasing. > " > > This issue happens after recently updated packages to: did it work before? It seems the phone is paged, a channel is opened, the RTP socket is opened but then the call 1073741832 is unknown. Could you check the dpkg.log to see from when to when you upgraded? So one call is not known and the other ends with an unknown codec type (where the call is accepted and then terminated as a result). From fanx07 at gmail.com Fri Sep 23 15:03:35 2016 From: fanx07 at gmail.com (Anonim Stefan) Date: Fri, 23 Sep 2016 18:03:35 +0300 Subject: osmo-sip-connector issue In-Reply-To: References: Message-ID: Hi, Yes, the same scenario worked before. Previous version I had was a pretty old one: osmocom-nitb:amd64 0.15.1.20160622 Thanks, Stefan On Fri, Sep 23, 2016 at 5:36 PM, Holger Freyther wrote: > > > On 23 Sep 2016, at 11:22, Anonim Stefan wrote: > > > > Hi, > > > > I am using osmo-nitb + osmo-sip-connector and I am sending INVITE to it, > as in the attached trace. The connector replies with 0.0.0.0 RTP IP and > 0/unknown codec and then ends the call. I am seeing the following log: > > > > " > > Sep 23 09:08:00 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> > mncc.c:334 call(1073741832) can not be found > > Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0002> > app.c:104 Unknown ptmsg(0). call broken > > Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> > mncc.c:312 leg(5001) rtp connect failed > > Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> > sip.c:245 Ending leg(0x91ec30) in con > > Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0001> > mncc.c:304 leg(1073741832) can not be found > > Sep 23 09:08:02 openbsc1 osmo-sip-connector[1723]: #033[0;m<0000> > sip.c:186 leg(0x91ec30) got bye, releasing. > > " > > > > This issue happens after recently updated packages to: > > did it work before? It seems the phone is paged, a channel is opened, the > RTP socket is opened but then the call 1073741832 is unknown. Could you > check the dpkg.log to see from when to when you upgraded? > > So one call is not known and the other ends with an unknown codec type > (where the call is accepted and then terminated as a result). > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Sat Sep 24 12:31:59 2016 From: laforge at gnumonks.org (Harald Welte) Date: Sat, 24 Sep 2016 20:31:59 +0800 Subject: Moving from trac to a single redmine In-Reply-To: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> Message-ID: <20160924123159.sdqpnz5yksr6njcr@nataraja> Dear all, It's been more than half a year that we transitioned the Osmocom projects from the various trac instances to redmine. Still, a lot of people end up on the old redmine pages. How do I know? Because of the amount of personal e-mail I receive from people asking for accounts or for modification of the content there. [This is of course just the indicator, I don't mind those mails]. But what worries me is that people are looking at outdated information in the old trac without even knowing. How do we proceed about that? I'm not quite clear. The first step could be to add some kind of banner to the old trac installations, indicating at the header / footer of every page (or even as a floating block visible at all times) that this is old, outdated content that is scheduled to be removed at a certain date, and indicating the top-level page for the specific project in the osmocom.org redmine as an updated source. After that grace period has passed, we should probably make all the old trac pages redirect to the entry-page of the project in redmine. Trying to link to the respective new page in each individual wiki would be overly complicated and take a lot of time, unless somebody masocistic enough would volunteer for creating such a list. It can probably be auto-generated to some extent, but then each individual item would need to be manually verified and fixed up, if needed. Do you have other ideas on how to proceed in a better way? Do we have any volunters about any of the above? I'm quite sure it wouldbe easy to provide volunteers witha copy of the existing trac databases or any other information that might be needed. Thanks in advance for any assistance, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From holger at freyther.de Sat Sep 24 12:57:57 2016 From: holger at freyther.de (Holger Freyther) Date: Sat, 24 Sep 2016 14:57:57 +0200 Subject: Moving from trac to a single redmine In-Reply-To: <20160924123159.sdqpnz5yksr6njcr@nataraja> References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> <20160924123159.sdqpnz5yksr6njcr@nataraja> Message-ID: <32B40E35-7B65-4478-ADCE-CD7771DDCA7B@freyther.de> > On 24 Sep 2016, at 14:31, Harald Welte wrote: > > Dear all, > > Still, a lot of people end up on the old redmine pages. How do I know? > Because of the amount of personal e-mail I receive from people asking > for accounts or for modification of the content there. eek. > > How do we proceed about that? I'm not quite clear. The first step > could be to add some kind of banner to the old trac installations, > indicating at the header / footer of every page (or even as a floating > block visible at all times) that this is old, outdated content that is > scheduled to be removed at a certain date, and indicating the top-level > page for the specific project in the osmocom.org redmine as an updated > source. After that grace period has passed, we should probably make all > the old trac pages redirect to the entry-page of the project in redmine. > > Trying to link to the respective new page in each individual wiki would > be overly complicated and take a lot of time, unless somebody masocistic > enough would volunteer for creating such a list. It can probably be > auto-generated to some extent, but then each individual item would need > to be manually verified and fixed up, if needed. > > Do you have other ideas on how to proceed in a better way? * banner to say to look at our redmine * disallow search engines to index trac (if that is still allowed) * not modify trac sites but use redirect of nginx > Do we have any volunters about any of the above? I'm quite sure it > wouldbe easy to provide volunteers witha copy of the existing trac > databases or any other information that might be needed. We can provide the access logs (all IP addresses point to the frontend server so we only show user agent that might be private). holger From 246tnt at gmail.com Sat Sep 24 14:01:52 2016 From: 246tnt at gmail.com (Sylvain Munaut) Date: Sat, 24 Sep 2016 08:01:52 -0600 Subject: Moving from trac to a single redmine In-Reply-To: <32B40E35-7B65-4478-ADCE-CD7771DDCA7B@freyther.de> References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> <20160924123159.sdqpnz5yksr6njcr@nataraja> <32B40E35-7B65-4478-ADCE-CD7771DDCA7B@freyther.de> Message-ID: Hi, > * not modify trac sites but use redirect of nginx I've just put this in place for 'openbsc.osmocom.org' : rewrite ^/trac/wiki/(.*)/(.*)$ $scheme://osmocom.org/projects/openbsc/wiki/$1$2 redirect; rewrite ^/trac/wiki(.*)$ $scheme://osmocom.org/projects/openbsc/wiki$1 redirect; This seems to work fairly well. I'm sure there are some exceptions to those regexps, but I couldn't find any immediately. If we uncover them we can try to tweak them or just handle them manually. I've set them to temporary (302) redirects for now. Once we're a little more confident that this works well, this can be changed to 301s and extended to all the other old domains. If you find any case where those fails, please report. Cheers, Sylvain From nhofmeyr at sysmocom.de Sun Sep 25 15:54:10 2016 From: nhofmeyr at sysmocom.de (Neels Hofmeyr) Date: Sun, 25 Sep 2016 17:54:10 +0200 Subject: Moving from trac to a single redmine In-Reply-To: References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> <20160924123159.sdqpnz5yksr6njcr@nataraja> <32B40E35-7B65-4478-ADCE-CD7771DDCA7B@freyther.de> Message-ID: <20160925155410.GA1868@dub7> On Sat, Sep 24, 2016 at 08:01:52AM -0600, Sylvain Munaut wrote: > I've just put this in place for 'openbsc.osmocom.org' : > > rewrite ^/trac/wiki/(.*)/(.*)$ > $scheme://osmocom.org/projects/openbsc/wiki/$1$2 redirect; > rewrite ^/trac/wiki(.*)$ $scheme://osmocom.org/projects/openbsc/wiki$1 redirect; But so far the idea is to keep the trac online and browsable, right? It didn't sound like the grace period before switching off trac has already passed. And I think we already have one complaint of missing content :) ~Neels -- - Neels Hofmeyr http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Gesch?ftsf?hrer / Managing Directors: Harald Welte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From laforge at gnumonks.org Mon Sep 26 01:11:08 2016 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 26 Sep 2016 09:11:08 +0800 Subject: Moving from trac to a single redmine In-Reply-To: <20160925155410.GA1868@dub7> References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> <20160924123159.sdqpnz5yksr6njcr@nataraja> <32B40E35-7B65-4478-ADCE-CD7771DDCA7B@freyther.de> <20160925155410.GA1868@dub7> Message-ID: <20160926011108.mxmktwgpty2ognob@nataraja> On Sun, Sep 25, 2016 at 05:54:10PM +0200, Neels Hofmeyr wrote: > On Sat, Sep 24, 2016 at 08:01:52AM -0600, Sylvain Munaut wrote: > > I've just put this in place for 'openbsc.osmocom.org' : > > > > rewrite ^/trac/wiki/(.*)/(.*)$ > > $scheme://osmocom.org/projects/openbsc/wiki/$1$2 redirect; > > rewrite ^/trac/wiki(.*)$ $scheme://osmocom.org/projects/openbsc/wiki$1 redirect; > > But so far the idea is to keep the trac online and browsable, right? the main problem is that search engines still primarily seem to index + link to the old trac instances. So we were keeping that alive for some time. However, as the content is going out of date, and people still show an interest in editing the old content, I think we need to switch the trac off soon and replace it with links to the redmine, even if it just links to the redmine entry page of that project. -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From laforge at gnumonks.org Mon Sep 26 04:05:04 2016 From: laforge at gnumonks.org (Harald Welte) Date: Mon, 26 Sep 2016 12:05:04 +0800 Subject: OsmoBTS -> libosmogsm code migration In-Reply-To: References: <20160911041205.52j4ql5kolbho7ln@nataraja> Message-ID: <20160926040504.tgh7vvd3yzbxrvvb@nataraja> Hi Vadim, sorry for the late foll-wup. On Mon, Sep 12, 2016 at 10:56:11PM +0600, Vadim Yanitskiy wrote: > > I think there's one option that I would prefer: Having a new library > > Ok, one may be a separate library in separate repo, or may be included > into libosmocore as a sub-library, if re-licensing would be successful. > Let's go this way. As re-licensing is approved by all authors meahwile, a sub-library inside libosmocore.git seems the solution. > > like libosmogsmphy (or libosmogsm-phy or libosmogsm_phy?) which contains > > the gsm0503 code and has dependencies to libosmocore and libosmocodec. > > IMHO, 'phy' may sound a little bit confusing. I would prefer something > like 'libosmo-coding' or 'libosmocoding', without 'gsm' prefix, because > there are GPRS and EDGE too. I wanted the 'gsm' to indicate 2G. Most people speak of "GSM" when they actually mean GSM+GPRS+EGPRS, i.e. second-generation technologies. > Also, this may be a potential place for other transcoding things, > unrelated to GSM at all. We are talking about channel coging, right? > :) I would assume most projects would be interested in the coding of one specific technology, and not all of them at the same time. Yes, there might be exceptions as a multi-RAT signal analyzer, but that could then very easily link several libraries. So my preference would be to have a '2g' specific library, and reflect that in the name by using either '2g' or 'gsm' as part of the name. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From axilirator at gmail.com Mon Sep 26 16:03:52 2016 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Mon, 26 Sep 2016 22:03:52 +0600 Subject: OsmoBTS -> libosmogsm code migration In-Reply-To: <20160926040504.tgh7vvd3yzbxrvvb@nataraja> References: <20160911041205.52j4ql5kolbho7ln@nataraja> <20160926040504.tgh7vvd3yzbxrvvb@nataraja> Message-ID: Hi Harald, > As re-licensing is approved by all authors meahwile, a sub-library > inside libosmocore.git seems the solution. Thanks for you assistance! > I would assume most projects would be interested in the coding of one > specific technology, and not all of them at the same time. Yes, there > might be exceptions as a multi-RAT signal analyzer, but that could then > very easily link several libraries. > > So my preference would be to have a '2g' specific library, and reflect > that in the name by using either '2g' or 'gsm' as part of the name. Ok, this is reasonable opinion and I am agree with you. There is only one possible variant in my mind - 'libosmogsm-coding'. What about this one? As soon as we reach an agreement in this question, I will update the lastest change and, I hope, my changes will be merged. Also, I would like to ask anyone to check the change, because this is first time I am adding a new library :) With best regards, Vadim Yanitskiy. 2016-09-26 11:05 GMT+07:00 Harald Welte : > Hi Vadim, > > sorry for the late foll-wup. > > On Mon, Sep 12, 2016 at 10:56:11PM +0600, Vadim Yanitskiy wrote: > > > I think there's one option that I would prefer: Having a new library > > > > Ok, one may be a separate library in separate repo, or may be included > > into libosmocore as a sub-library, if re-licensing would be successful. > > Let's go this way. > > As re-licensing is approved by all authors meahwile, a sub-library > inside libosmocore.git seems the solution. > > > > like libosmogsmphy (or libosmogsm-phy or libosmogsm_phy?) which > contains > > > the gsm0503 code and has dependencies to libosmocore and libosmocodec. > > > > IMHO, 'phy' may sound a little bit confusing. I would prefer something > > like 'libosmo-coding' or 'libosmocoding', without 'gsm' prefix, because > > there are GPRS and EDGE too. > > I wanted the 'gsm' to indicate 2G. Most people speak of "GSM" when they > actually mean GSM+GPRS+EGPRS, i.e. second-generation technologies. > > > Also, this may be a potential place for other transcoding things, > > unrelated to GSM at all. We are talking about channel coging, right? > > :) > > I would assume most projects would be interested in the coding of one > specific technology, and not all of them at the same time. Yes, there > might be exceptions as a multi-RAT signal analyzer, but that could then > very easily link several libraries. > > So my preference would be to have a '2g' specific library, and reflect > that in the name by using either '2g' or 'gsm' as part of the name. > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > ============================================================ > ================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Tue Sep 27 17:42:00 2016 From: holger at freyther.de (Holger Freyther) Date: Tue, 27 Sep 2016 19:42:00 +0200 Subject: osmo-sip-connector issue In-Reply-To: References: Message-ID: <10A313E1-A66A-4E38-89F4-D01DE817993C@freyther.de> > On 23 Sep 2016, at 17:03, Anonim Stefan wrote: > > Hi, Hi! > Yes, the same scenario worked before. > > Previous version I had was a pretty old one: osmocom-nitb:amd64 0.15.1.20160622 I tried to reproduce (with a manual built) and couldn't. Could you send us your openbsc-nitb and osmo-sip-connector configuration file? thank you! holger From craig_comstock at yahoo.com Sun Sep 25 13:22:23 2016 From: craig_comstock at yahoo.com (Craig Comstock) Date: Sun, 25 Sep 2016 13:22:23 +0000 (UTC) Subject: Moving from trac to a single redmine In-Reply-To: References: <29DF7E51-8366-40A3-8EF1-F4705D3A0E6D@freyther.de> <20160924123159.sdqpnz5yksr6njcr@nataraja> <32B40E35-7B65-4478-ADCE-CD7771DDCA7B@freyther.de> Message-ID: <53112477.360510.1474809743413@mail.yahoo.com> I am working on fernvale-nuttx-bb (fernvale-nuttx + gnutoo's nuttx-bb) and wanted to check the osmocom bb on nuttx-bb. It seems all the links are broken in the redmine version of things and the trac URLs redirect to redmine so the content is "gone"? Can you help me resurrect pages like http://osmocom.org/projects/baseband/wiki/Nuttx-bbcompile?parent=Nuttx-bb Thanks,Craig From: Sylvain Munaut <246tnt at gmail.com> To: Holger Freyther Cc: "osmocom-sdr at lists.osmocom.org" ; baseband-devel ; OpenBSC Mailing List ; gmr at lists.osmocom.org Sent: Saturday, September 24, 2016 9:01 AM Subject: Re: Moving from trac to a single redmine Hi, > * not modify trac sites but use redirect of nginx I've just put this in place for 'openbsc.osmocom.org' : rewrite ^/trac/wiki/(.*)/(.*)$ $scheme://osmocom.org/projects/openbsc/wiki/$1$2 redirect; rewrite ^/trac/wiki(.*)$ $scheme://osmocom.org/projects/openbsc/wiki$1 redirect; This seems to work fairly well. I'm sure there are some exceptions to those regexps, but I couldn't find any immediately. If we uncover them we can try to tweak them or just handle them manually. I've set them to temporary (302) redirects for now. Once we're a little more confident that this works well, this can be changed to 301s and extended to all the other old domains. If you find any case where those fails, please report. Cheers, ? ? Sylvain -------------- next part -------------- An HTML attachment was scrubbed... URL: From brucemate at mail.com Tue Sep 27 03:47:31 2016 From: brucemate at mail.com (Bruce Smith) Date: Tue, 27 Sep 2016 05:47:31 +0200 Subject: MS cannot connect; Location Update Request not received by BTS? Message-ID: An HTML attachment was scrubbed... URL: From holger at freyther.de Tue Sep 27 17:50:52 2016 From: holger at freyther.de (Holger Freyther) Date: Tue, 27 Sep 2016 19:50:52 +0200 Subject: MS cannot connect; Location Update Request not received by BTS? In-Reply-To: References: Message-ID: <291300AB-CDFF-4D1A-9797-F14D3F4E3BDA@freyther.de> > On 27 Sep 2016, at 05:47, Bruce Smith wrote: > > Greetings, Dear Bruce, I have never used osmo-trx/uhd or related with OpenBSC but in terms of figuring out what is broken let's have a look at the different components. > There's a delay of ~10s at the line marked **** where the BTS seems to wait for a location update request from the MS; which never gets received, hence the BTS times out and releases the channel. Using a phone in diagnostic mode, this message appears to be sent correctly, however the BTS never receives/processes it. So OpenBSC/osmo-nitb seems to work correctly. It doesn't "ignore" a message and it is just missing. My hypothesizes that you might have time to explore: a.) osmo-trx not being able to decode the message? b.) The osmo-bts-trx is not "receiving" data from osmo-trx? c.) osmo-bts-trx not getting the LAPDm framing right? > > I've tried using older configuration files (which have worked with older builds), as well as the sample configuration files contained with each of the master branches, but to no differing effect. > > Given the MS can see and attempt to connect to the BTS, I'm assuming the transceiver chain is working correctly... my thoughts are that perhaps I've got some simple configuration set incorrectly somewhere along the way. > > libosmocore (master) - 2016-08-30 > libosmo-abis (master) - 2016-09-05 > libosmo-netif (master) - 2016-07-07 > openggsn (master) - 2016-06-05 > libosmo-sccp (master) - 2016-07-07 > openbsc (master) - 2016-09-05 > osmo-bts (master) - 2016-09-06 > osmo-pcu (master) - 2016-09-06 > osmo-trx (master) - 2016-08-11 > uhd_003.009.002-0 Could you downgrade your osmo-trx and osmo-bts to the 12+ months old version? The rest should work just fine and doesn't seem to have the issue. So my bet is either osmo-bts (a year ago you must have used a branch, now the refactored master branch is used) or osmo-trx? holger From axilirator at gmail.com Tue Sep 27 20:18:13 2016 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Wed, 28 Sep 2016 02:18:13 +0600 Subject: OsmoBTS -> libosmogsm code migration In-Reply-To: <20160926040504.tgh7vvd3yzbxrvvb@nataraja> References: <20160911041205.52j4ql5kolbho7ln@nataraja> <20160926040504.tgh7vvd3yzbxrvvb@nataraja> Message-ID: Dear all, I just wrote a simple test to ensure, that the new library performs valid transcoding. I used a DCCH "LAPDM U, func=UI" frame for simplicity, and good news is that test passed. See attachment for details. In the test I wrote the best signal quality is assumed. So, ubit 0 is sbit -127 and ubit 1 is 127. But there is no such things as miracles, and on practice error correction takes place. So, we need to make sure, that correction works. I am going to write tests and I have some questions: 1) How can I know the maximum count of bits can be corrected for a specific channel type? 2) In case of: gsm0503_*_decode(... int *n_errors, int *n_bits_total); What do the two last params mean? 3) Can anyone provide me some samples for GPRS and EDGE? It will take some time to set up PDCH support in my test network. Thanks in advance! With best regards, Vadim Yanitskiy. 2016-09-26 11:05 GMT+07:00 Harald Welte : > Hi Vadim, > > sorry for the late foll-wup. > > On Mon, Sep 12, 2016 at 10:56:11PM +0600, Vadim Yanitskiy wrote: > > > I think there's one option that I would prefer: Having a new library > > > > Ok, one may be a separate library in separate repo, or may be included > > into libosmocore as a sub-library, if re-licensing would be successful. > > Let's go this way. > > As re-licensing is approved by all authors meahwile, a sub-library > inside libosmocore.git seems the solution. > > > > like libosmogsmphy (or libosmogsm-phy or libosmogsm_phy?) which > contains > > > the gsm0503 code and has dependencies to libosmocore and libosmocodec. > > > > IMHO, 'phy' may sound a little bit confusing. I would prefer something > > like 'libosmo-coding' or 'libosmocoding', without 'gsm' prefix, because > > there are GPRS and EDGE too. > > I wanted the 'gsm' to indicate 2G. Most people speak of "GSM" when they > actually mean GSM+GPRS+EGPRS, i.e. second-generation technologies. > > > Also, this may be a potential place for other transcoding things, > > unrelated to GSM at all. We are talking about channel coging, right? > > :) > > I would assume most projects would be interested in the coding of one > specific technology, and not all of them at the same time. Yes, there > might be exceptions as a multi-RAT signal analyzer, but that could then > very easily link several libraries. > > So my preference would be to have a '2g' specific library, and reflect > that in the name by using either '2g' or 'gsm' as part of the name. > > Regards, > Harald > -- > - Harald Welte > http://laforge.gnumonks.org/ > ============================================================ > ================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. > A6) > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: coding.c Type: text/x-csrc Size: 1629 bytes Desc: not available URL: From abdulghafar1412 at gmail.com Tue Sep 27 21:51:28 2016 From: abdulghafar1412 at gmail.com (Abdulghafar Shabaneh) Date: Tue, 27 Sep 2016 22:51:28 +0100 Subject: MS cannot connect; Location Update Request not received by BTS? In-Reply-To: <291300AB-CDFF-4D1A-9797-F14D3F4E3BDA@freyther.de> References: <291300AB-CDFF-4D1A-9797-F14D3F4E3BDA@freyther.de> Message-ID: Hi That's the same that is happening with me since about two weeks, and I was unable to solve it. They told me it might be uhd problem, but I installed different uhds with the same issue. osmo-bitb shows the same error like this: <0000> chan_alloc.c:342 (bts=0,trx=0,ts=7,pchan=TCH/F) Allocating lchan=0 as TCH_F <0004> abis_rsl.c:1727 (bts=0,trx=0,ts=7,ss=0) Activating ARFCN(60) SS(0) lctype TCH_F r=EMERGENCY ra=0xab ta=3 <0004> abis_rsl.c:536 (bts=0,trx=0,ts=7,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVATION REQUESTED <0004> abis_rsl.c:1456 (bts=0,trx=0,ts=7,ss=0) CHANNEL ACTIVATE ACK <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state ACTIVATION REQUESTED -> ACTIVE <0004> abis_rsl.c:806 (bts=0,trx=0,ts=7,ss=0) RF Channel Release CMD due error 1 <0004> abis_rsl.c:718 (bts=0,trx=0,ts=7,ss=0) DEACTivate SACCH CMD <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state ACTIVE -> RELEASE DUE ERROR <0004> abis_rsl.c:863 (bts=0,trx=0,ts=7,ss=0) RF CHANNEL RELEASE ACK <0004> abis_rsl.c:767 (bts=0,trx=0,ts=7,ss=0) is back in operation. it once showed this error: <0022> control_if.c:286 Failed to parse ip access message: -5 <0000> chan_alloc.c:355 Failed to allocate SDCCH channel <0004> abis_rsl.c:1678 BTS 0 CHAN RQD: no resources for SDCCH 0x10 osmo-pcu is not working fine with me, can this help to solve the problem?, this is the output for using it with and without sudo. pi at raspberrypi:~ $ osmo-pcu -r 1 No config file: 'osmo-pcu.cfg' Using default config. <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:264 Failed to connect to the osmo-bts PCU socket, delaying... '/tmp/pcu_bts' <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:264 Failed to connect to the osmo-bts PCU socket, delaying... '/tmp/pcu_bts' ^CSignal 2 received. full talloc report on 'Osmo-PCU context' (total 1 bytes in 1 blocks) pi at raspberrypi:~ $ sudo osmo-pcu -r 1 No config file: 'osmo-pcu.cfg' Using default config. <0001> osmobts_sock.cpp:227 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:285 osmo-bts PCU socket has been connected <0001> pcu_l1_if.cpp:357 BTS not available pi at raspberrypi:~ $ I use USRP2 , I used recently a reference clock of 10 MHz but didn't solve the issue, but it is good to know that N210 is with the same error. Another thing that my network rarely shows on the MS, but the osmo-nitb still shows the output every minute or more or when I do a mobile network search. Thanks Abdulghafar On Tue, Sep 27, 2016 at 6:50 PM, Holger Freyther wrote: > > > On 27 Sep 2016, at 05:47, Bruce Smith wrote: > > > > Greetings, > > Dear Bruce, > > I have never used osmo-trx/uhd or related with OpenBSC but in terms of > figuring out what is broken let's have a look at the different components. > > > > There's a delay of ~10s at the line marked **** where the BTS seems to > wait for a location update request from the MS; which never gets received, > hence the BTS times out and releases the channel. Using a phone in > diagnostic mode, this message appears to be sent correctly, however the BTS > never receives/processes it. > > So OpenBSC/osmo-nitb seems to work correctly. It doesn't "ignore" a > message and it is just missing. My hypothesizes that you might have time to > explore: > > a.) osmo-trx not being able to decode the message? > b.) The osmo-bts-trx is not "receiving" data from osmo-trx? > c.) osmo-bts-trx not getting the LAPDm framing right? > > > > > > I've tried using older configuration files (which have worked with older > builds), as well as the sample configuration files contained with each of > the master branches, but to no differing effect. > > > > Given the MS can see and attempt to connect to the BTS, I'm assuming the > transceiver chain is working correctly... my thoughts are that perhaps I've > got some simple configuration set incorrectly somewhere along the way. > > > > > libosmocore (master) - 2016-08-30 > > libosmo-abis (master) - 2016-09-05 > > libosmo-netif (master) - 2016-07-07 > > openggsn (master) - 2016-06-05 > > libosmo-sccp (master) - 2016-07-07 > > openbsc (master) - 2016-09-05 > > osmo-bts (master) - 2016-09-06 > > osmo-pcu (master) - 2016-09-06 > > osmo-trx (master) - 2016-08-11 > > uhd_003.009.002-0 > > Could you downgrade your osmo-trx and osmo-bts to the 12+ months old > version? The rest should work just fine and doesn't seem to have the issue. > So my bet is either osmo-bts (a year ago you must have used a branch, now > the refactored master branch is used) or osmo-trx? > > > holger -------------- next part -------------- An HTML attachment was scrubbed... URL: From holger at freyther.de Tue Sep 27 21:58:33 2016 From: holger at freyther.de (Holger Freyther) Date: Tue, 27 Sep 2016 23:58:33 +0200 Subject: MS cannot connect; Location Update Request not received by BTS? In-Reply-To: References: <291300AB-CDFF-4D1A-9797-F14D3F4E3BDA@freyther.de> Message-ID: > On 27 Sep 2016, at 23:51, Abdulghafar Shabaneh wrote: > > Hi Hi! > That's the same that is happening with me since about two weeks, and I was unable to solve it. They told me it might be uhd problem, but I installed different uhds with the same issue. same disclaimer that I have only worked with the BS11, nanoBTS and the last years with the sysmoBTS. > osmo-bitb shows the same error like this: > <0000> chan_alloc.c:342 (bts=0,trx=0,ts=7,pchan=TCH/F) Allocating lchan=0 as TCH_F > <0004> abis_rsl.c:1727 (bts=0,trx=0,ts=7,ss=0) Activating ARFCN(60) SS(0) lctype TCH_F r=EMERGENCY ra=0xab ta=3 > <0004> abis_rsl.c:536 (bts=0,trx=0,ts=7,pchan=TCH/F) Tx RSL Channel Activate with act_type=INITIAL > <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state NONE -> ACTIVATION REQUESTED > <0004> abis_rsl.c:1456 (bts=0,trx=0,ts=7,ss=0) CHANNEL ACTIVATE ACK > <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state ACTIVATION REQUESTED -> ACTIVE > <0004> abis_rsl.c:806 (bts=0,trx=0,ts=7,ss=0) RF Channel Release CMD due error 1 > <0004> abis_rsl.c:718 (bts=0,trx=0,ts=7,ss=0) DEACTivate SACCH CMD > <0004> abis_rsl.c:1127 (bts=0,trx=0,ts=7,ss=0) state ACTIVE -> RELEASE DUE ERROR > <0004> abis_rsl.c:863 (bts=0,trx=0,ts=7,ss=0) RF CHANNEL RELEASE ACK > <0004> abis_rsl.c:767 (bts=0,trx=0,ts=7,ss=0) is back in operation. > > > it once showed this error: > <0022> control_if.c:286 Failed to parse ip access message: -5 > <0000> chan_alloc.c:355 Failed to allocate SDCCH channel > <0004> abis_rsl.c:1678 BTS 0 CHAN RQD: no resources for SDCCH 0x10 I think this is not the first issue but a consequence of many channels ending up in error. > > I use USRP2 , I used recently a reference clock of 10 MHz but didn't solve the issue, but it is good to know that N210 is with the same error. > > Another thing that my network rarely shows on the MS, but the osmo-nitb still shows the output every minute or more or when I do a mobile network search. Same hint as to the original poster. Try an older version of osmo-bts and tell us preferable the SHA1 of it. Then we will ask you to git bisect between working and non-working version. holger From laforge at gnumonks.org Tue Sep 27 23:59:46 2016 From: laforge at gnumonks.org (Harald Welte) Date: Wed, 28 Sep 2016 07:59:46 +0800 Subject: OsmoBTS -> libosmogsm code migration In-Reply-To: References: <20160911041205.52j4ql5kolbho7ln@nataraja> <20160926040504.tgh7vvd3yzbxrvvb@nataraja> Message-ID: <20160927235946.4amd3ivz3uit425n@nataraja> Dear Vadim, it migt be a coincidence that I was in the "To" line of the mail, but just for clarification for me personally and the team at sysmocom: The BTS models we use don't use the gsm0503_* code, as we don't use osmo-bts-trx. The amount of involvement I had with the osmo-bts-trx code was merely to adopt it to some core infrastructural changes in osmo-bts. Don't get me wrong, I'm very happy that osmo-bts-trx (and osmo-trx) exists, but it is unfortunately still pretty much in lack of proper maintenance. On Wed, Sep 28, 2016 at 02:18:13AM +0600, Vadim Yanitskiy wrote: > 1) How can I know the maximum count of bits can be corrected > ?? for a specific channel type? I have no input on that, see above. > 2) In case of: > ?? gsm0503_*_decode(... int *n_errors, int *n_bits_total); > ?? What do the two last params mean? output variables: the number of error bits in the decoded frame and the number of total bits in the frame. Used to calculate BER. > 3) Can anyone provide me some samples for GPRS and EDGE? > ?? It will take some time to set up PDCH support in my > ?? test network. I hope the primary proponents, beneficiaries and users of the related code will be able to help out with that. Regards, Harald -- - Harald Welte http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6) From fanx07 at gmail.com Wed Sep 28 09:47:51 2016 From: fanx07 at gmail.com (Anonim Stefan) Date: Wed, 28 Sep 2016 12:47:51 +0300 Subject: osmo-sip-connector issue In-Reply-To: <10A313E1-A66A-4E38-89F4-D01DE817993C@freyther.de> References: <10A313E1-A66A-4E38-89F4-D01DE817993C@freyther.de> Message-ID: I'm attaching the config for both. Thanks, Stefan On Tue, Sep 27, 2016 at 8:42 PM, Holger Freyther wrote: > > > On 23 Sep 2016, at 17:03, Anonim Stefan wrote: > > > > Hi, > > Hi! > > > > Yes, the same scenario worked before. > > > > Previous version I had was a pretty old one: osmocom-nitb:amd64 > 0.15.1.20160622 > > I tried to reproduce (with a manual built) and couldn't. Could you send us > your openbsc-nitb and osmo-sip-connector configuration file? > > thank you! > > holger > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-nitb.cfg Type: application/octet-stream Size: 3364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: osmo-sip-connector.cfg Type: application/octet-stream Size: 94 bytes Desc: not available URL: From axilirator at gmail.com Thu Sep 29 14:31:00 2016 From: axilirator at gmail.com (Vadim Yanitskiy) Date: Thu, 29 Sep 2016 20:31:00 +0600 Subject: OsmoBTS -> libosmogsm code migration In-Reply-To: References: Message-ID: Hi Sylvain and Harald! I am contact you again (sorry for so many mails), because Sylvain is a copyright holder of the 'libosmocore/utils/conv_gen.py', and Harald listed in the output of 'git blame' for almost every line. There is a mismatch between the CS2 & CS3 convolutional code definitions in 'osmo-bts/src/osmo-bts-trx/gsm0503_conv.c' and 'libosmocore/utils/conv_gen.py'. In second source there is no puncture for both definitions: const struct osmo_conv_code gsm0503_conv_cs2 = { .N = 2, .K = 5, .len = 290, .next_output = conv_xcch_next_output, .next_state = conv_xcch_next_state, }; const struct osmo_conv_code gsm0503_conv_cs3 = { .N = 2, .K = 5, .len = 334, .next_output = conv_xcch_next_output, .next_state = conv_xcch_next_state, }; But in first source there is. And I am not sure, which definition is correct. I paid my attention here, because I just integrated some tests from 'osmo-bts/tests/bursts' to libosmocoding. PDCH test fails until there is puncture in both definitions. When I removed punctures from definitions, test passed. So, my question is do we need punctures for both CS2 & CS3? With best regards, Vadim Yanitskiy. 2016-09-06 10:46 GMT+07:00 Sylvain Munaut <246tnt at gmail.com>: > Hi, > > > With regards to convolutional coding, the main difference between GPRS > > and EGPRS will be the use of tail-biting recursive codes. > > > > Max, can the utility generate recursive state tables? > > Yes > > Cheers, > > Sylvain > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laforge at gnumonks.org Thu Sep 29 14:40:48 2016 From: laforge at gnumonks.org (Harald Welte) Date: Thu, 29 Sep 2016 16:40:48 +0200 Subject: OsmoBTS -> libosmogsm code migration In-Reply-To: References: Message-ID: <8C00661C-EE43-4107-8FBB-FD86EB010CA2@gnumonks.org> >From my memory: * CS1 is rate 1/2 conv code with no puncturing. * CS2+3 apply different puncturing amounts on that conv code * CS4 has no error correction (=100% puncturing) Why the code differs, I don't know. Maybe it was never completed in conv_gen? -- Sent from a mobile device. Please excuse my brevity. From holger at freyther.de Fri Sep 30 13:54:58 2016 From: holger at freyther.de (Holger Freyther) Date: Fri, 30 Sep 2016 15:54:58 +0200 Subject: osmo-sip-connector issue In-Reply-To: References: <10A313E1-A66A-4E38-89F4-D01DE817993C@freyther.de> Message-ID: <774061C2-0FFF-43AC-B4EC-9663C9A76B0A@freyther.de> > On 28 Sep 2016, at 11:47, Anonim Stefan wrote: > > I'm attaching the config for both. > config looks fine and besides the band (changed to 1800) I have used your config on: ii libosmoabis5:amd64 0.3.3.20160929 amd64 GSM A-bis handling ii libosmocore7:amd64 0.9.3.20160929 amd64 Osmo Core library ii libosmoctrl0:amd64 0.9.3.20160929 amd64 Osmo control library ii libosmogsm5:amd64 0.9.3.20160929 amd64 Osmo GSM utility library ii libosmovty3:amd64 0.9.3.20160929 amd64 Osmo VTY library ii osmo-sip-connector 1.20160929 amd64 MNCC to SIP bridge for osmo-nitb ii osmocom-nitb 0.15.1.20160929 amd64 GSM Network-in-a-Box, implements BSC, MSC, SMSC, HLR, VLR it works here(tm). Can you retry and if it fails keep the first error and include RSL+SIP in the same trace and include osmo-nitb log output (-e 1) and enable timestamps. thank you holger From mayuri.tendulkar at gmail.com Fri Sep 30 19:20:07 2016 From: mayuri.tendulkar at gmail.com (Mayuri Tendulkar) Date: Sat, 1 Oct 2016 00:50:07 +0530 Subject: bts lchan loopback vty command -- was: Query on run time control of network with VTY In-Reply-To: <20160921151627.GE1463@dub7> References: <20160921151627.GE1463@dub7> Message-ID: Thanks Neels. Where we can get more information on this? We would like to use this loopback for BER measurements. Is it suitable to do that? On Wed, Sep 21, 2016 at 8:46 PM, Neels Hofmeyr wrote: > On Wed, Sep 21, 2016 at 05:47:34PM +0530, Dhananjay kumar wrote: > > One more query regarding loop-back call : > > "bts <0-0> trx <0-0> ts <0-7> lchan <0-1> loopback", > > > > we tried this command to start loop-back call once MS is registered to > the > > network. > > But we are not seeing any loop-back call happening in nitb and osmo-bts > > logs. > > This command only sets a loopback flag on a given lchan and does not > actually > initiate a call. IIUC after setting the loopback, the loopback should > happen > when you make a voice call using that time slot and lchan. > It might make more sense to start a call and set the loopback on the lchan > while the call is active. So this does not replace the other MS. > > From the code it seems the loopback flag is not cleared before / after a > voice > call, so it looks like the given lchan will remain a loopback for any > number of > calls (that end up on that lchan). > > I'm not 100% sure though, only skimmed the code briefly, > I've never used this before. > > ~Neels > > -------------- next part -------------- An HTML attachment was scrubbed... URL: