OpenBSC

openbsc@lists.osmocom.org

4315 discussions

Re: osmo-bts: Repository write acces / Gerrit migration
by Harald Welte 05 Jul '16

05 Jul '16

Dear Tom, I hope you don't mind me Cc'ing the list, as this question might come up again. On Fri, Jul 01, 2016 at 02:42:25AM -0700, Tom Tsou wrote: > I appear to no longer have write access to the osmo-bts repository. > "ERROR:gitosis.serve.main:Repository write access denied" > Can I have write access restored? As decided at the Osmocom Developer Conference in April 2016, we have started to use gerrit for a more formalized tool for code review. The advantages are plentiful, among other things submitted patches are running through 'make distcheck' on several supported platforms before even being eligible to merge. Please see https://osmocom.org/projects/cellular-infrastructure/wiki/Gerrit for a short intro in how to use it. There are instructions both for submitting patches against master, as well as for pushing to user-private branches. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

3 3

error install openbsc
by sms makhof 05 Jul '16

05 Jul '16

Hi all I am installing OpenBSC.I just following http://openbsc.osmocom.org/trac/wiki/Building_OpenBSC (I am just Building libosmocore, Building libosmo-abis, Building libosmo-netif, Building OpenBSC and install library.) But when I tried to run OpenBSC,I encounter with this error(problem). user12@ubuntu:~$ cd '/home/user12/openbsc/openbsc/src/osmo-nitb' user12@ubuntu:~/openbsc/openbsc/src/osmo-nitb$ sudo ./osmo-nitb <0005> bsc_init.c:492 Failed to parse the config file: 'openbsc.cfg' Or how do I run the software(OpenBSC)! Or do I have to install something missing? Note: My Linux is version ubuntu 12.04 . Please help me. thank you.

2 1

freebsd and jenkins
by Max 04 Jul '16

04 Jul '16

Hi. Yet again I've hit an issue with jenkins build failing on freebsd only: http://jenkins.osmocom.org/jenkins/job/libosmocore-gerrit/label=FreeBSD_amd… No warnings, no errors, just a failure which I'm unable to reproduce locally as I do not have access to any machine with freebsd. If we can't make freebsd tests optional (which I personally would prefer) can we at least configure jenkins in a way that it runs "cat tests/testsuite.log" so it's available via "console output" part of jenkins web ui? Or somehow else provide access to build artifacts. That will give at least some clue as to what exactly is broken on freebsd. Any ideas as to why build fails are highly appreciated as well. -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

2 3

Is there a maximum separation in Mhz for ARFCNs on one BTS?
by Keith Whyte 01 Jul '16

01 Jul '16

Hi all, Would somebody who is familiar with the relevant part of the GSM spec be able to comment? I'm wondering if there's any issue in GSM running a dual TRX BTS with two ARFCNs on opposite ends of the band? For example, in GSM850, this would mean the downlinks could be on 869.2 and 893.8 Mhz so the phone could have to tune across a wider range between the SDCCH and TCH for example. Thanks!

2 1

osmo-nitb/osmo-bts-trx: Logging traffic on A-bis interface
by Sebastian Stumpf 01 Jul '16

01 Jul '16

Hi all, I wanted to check if the bts - bsc communication works properly with my configuration. For example, if my osmo-nitb does send the system information messages to the bts. I tried the vty logging interface of osmo-bts and logged some messages, but they were not the messages I expected. I configured the groups rsl, oml, rll, rr and abis to "notice", all to "everything" and everything else to "error" and got following log output (lots of these and nothing else): ... <0006> scheduler.c:405 PH-RTS.ind: chan=CCCH chan_nr=0x90 link_id=0x00 fn=993588 ts=0 trx=0 <0006> scheduler.c:341 PH-DATA.req: chan_nr=0x90 link_id=0x00 fn=993588 ts=0 trx=0 ... PH-RTS.ind and PH-DATA.req seem to come from layer1 SAP, the osmo-trx and have probably nothing to do with the SI messages. Is traffic on abis generally not logged or is my log config faulty? I ended up configuring the gsmtap interface for osmo-bts and could so see the uplink/downlink in wireshark and could see that the SI information is properly sent. But gsmtap only works for the air interface. What is the best way for logging/sniffing the communication on the A-bis interface? With kind regards, Sebastian Stumpf

3 2

Re: GPRS on osmo-trx not working
by Alexander Chemeris 29 Jun '16

29 Jun '16

On Jun 29, 2016 10:04 PM, "Tom Tsou" <tom(a)tsou.cc> wrote: > > On Wed, Jun 29, 2016 at 8:31 AM, Neels Hofmeyr <nhofmeyr(a)sysmocom.de> wrote: > Another non-startup error message I found is bad PDTCH and PTCCH and > blocks under ideal RF signal conditions. It appears that you have seen > this behavior as well. > > DL1C <0006> scheduler_trx.c:835 Received bad data frame at fn=372020 > (12/104) for PTCCH > DL1C <0006> scheduler_trx.c:918 Received bad PDTCH block ending at > fn=310516 (76/104) for PDTCH > > The cause of these errors with excellent signal is the following piece > of code where zero-filled buffers are passed to the decoder. I have no > idea why this is done. Removing the code prevents the bad PDTCH/PTCCH > blocks with no loss of GPRS functionality. > > diff --git a/src/common/scheduler.c b/src/common/scheduler.c > @@ -1598,10 +1598,6 @@ int trx_sched_ul_burst() > > func(l1t, tn, fn, chan, bid, bits, rssi, toa); > } else if (chan != TRXC_RACH && !l1cs->ho_rach_detect) { > - sbit_t spare[148]; > - > - memset(spare, 0, 148); > - func(l1t, tn, fn, chan, bid, spare, -128, 0); > } Each L2 frame consists of several L1 bursts, so you need to accumulate them all before you can pass them to Viterbi for decoding. If I remember this part of the code correctly, this zeroing is required to make this work when there are lost bursts. E.g. if you need 4 bursts, but you only received bursts 0, 1 and 2 you should let the device know that your missing burst 3. If you don't do that, decoder won't run at all and to will miss what could be a decodable frame. By disabling this code you essentially start decoding only perfect frames, which are obviously decoded fine in perfect conditions. I.e. this only makes the actual problem, whatever it is. Please excuse typos. Written with a touchscreen keyboard. -- Regards, Alexander Chemeris CEO Fairwaves, Inc. https://fairwaves.co

2 1

scope of scheduler.c and trx_sched_*
by Neels Hofmeyr 29 Jun '16

29 Jun '16

I notice that apparently osmo-bts-trx is the only caller of the trx_sched_* API, yet it is implemented in common/scheduler.c and compiled to libl1sched.a. Is osmo-bts-trx really the only caller? Also in osmo-bts-trx, the "trx" to me means SDR, like B200. But any BTS has one or more TRXs. So why isn't it osmo-bts-sdr? That's why I thought: maybe trx_sched_ is for all BTS models? Thanks for any clarification / confirmation :) ~Neels -- - Neels Hofmeyr <nhofmeyr(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschäftsführer / Managing Directors: Harald Welte

2 1

osmotrx init problem
by Max 29 Jun '16

29 Jun '16

Hi. I've got following problem while trying to make osmotrx work in multitrx setting on USRP B210: sudo chrt 20 ./Transceiver52M/osmo-trx -c 2 sudo chrt 15 ./src/osmo-bts-trx/osmo-bts-trx -t 2 -c ~/.config/osmocom/osmo-bts-mtrx.cfg -d DRTP:DCC:DRSL:DOML:DL1C:DTRX The bts quits from trx_if.c after checking "if (tcm->critical) {...". The command sequence seems to be the same for both phy0.0 and phy0.1 However 0.0 one accepts SETTSC command and 0.1 rejects it: trx_if.c:380 transceiver (phy0.1) rejected TRX command with response: 'RSP SETTSC 1 7' So far I fail to see where this difference comes from. Full log: <0001> oml.c:1249 Initializing OML attribute definitions <000b> trx_if.c:560 Open transceiver for phy0.0 <000b> trx_if.c:222 Adding new control 'CMD POWEROFF' <000b> trx_if.c:169 Sending control 'CMD POWEROFF' to phy0.0 <000b> trx_if.c:560 Open transceiver for phy0.1 <000b> trx_if.c:348 Response message: 'RSP POWEROFF 0' <0001> oml.c:547 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug! <000b> trx_if.c:222 Adding new control 'CMD POWEROFF' <000b> trx_if.c:169 Sending control 'CMD POWEROFF' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP POWEROFF 0' <0001> oml.c:884 ADM state already was Unlocked <000b> trx_if.c:222 Adding new control 'CMD RXTUNE 1783400' <000b> trx_if.c:169 Sending control 'CMD RXTUNE 1783400' to phy0.0 <000b> trx_if.c:222 Adding new control 'CMD TXTUNE 1878400' <000b> trx_if.c:222 Adding new control 'CMD SETTSC 7' <000b> trx_if.c:222 Adding new control 'CMD POWERON' <000b> trx_if.c:222 Adding new control 'CMD SETRXGAIN 1' <000b> trx_if.c:222 Adding new control 'CMD SETPOWER 0' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 0 4' <0005> paging.c:545 Paging: BS_AG_BLKS_RES = 0 != 1 not fully supported <000b> trx_if.c:348 Response message: 'RSP RXTUNE 0 1783400' <000b> trx_if.c:169 Sending control 'CMD TXTUNE 1878400' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP TXTUNE 0 1878400' <000b> trx_if.c:169 Sending control 'CMD SETTSC 7' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETTSC 0 7' <000b> trx_if.c:169 Sending control 'CMD POWERON' to phy0.0 <0005> paging.c:545 Paging: BS_AG_BLKS_RES = 0 != 1 not fully supported <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 1 7' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 2 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 3 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 4 13' <000b> trx_if.c:348 Response message: 'RSP POWERON 0' <000b> trx_if.c:169 Sending control 'CMD SETRXGAIN 1' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETRXGAIN 0 1' <000b> trx_if.c:169 Sending control 'CMD SETPOWER 0' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETPOWER 0 0' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 0 4' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 0 4' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 1 7' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 1 7' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 2 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 2 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 3 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 3 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 4 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 4 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 5 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 5 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 5 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 6 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 6 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 6 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 7 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 7 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 7 13' <0001> oml.c:884 ADM state already was Unlocked <000b> trx_if.c:222 Adding new control 'CMD RXTUNE 1783800' <000b> trx_if.c:169 Sending control 'CMD RXTUNE 1783800' to phy0.1 <000b> trx_if.c:222 Adding new control 'CMD TXTUNE 1878800' <000b> trx_if.c:222 Adding new control 'CMD SETTSC 7' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 0 7' <000b> trx_if.c:348 Response message: 'RSP RXTUNE 0 1783800' <000b> trx_if.c:169 Sending control 'CMD TXTUNE 1878800' to phy0.1 <000b> trx_if.c:348 Response message: 'RSP TXTUNE 0 1878800' <000b> trx_if.c:169 Sending control 'CMD SETTSC 7' to phy0.1 <000b> trx_if.c:348 Response message: 'RSP SETTSC 1 7' <000b> trx_if.c:380 transceiver (phy0.1) rejected TRX command with response: 'RSP SETTSC 1 7' <0001> bts.c:203 Shutting down BTS 0, Reason TRX-CTRL-MSG: CRITICAL <000b> trx_if.c:222 Adding new control 'CMD POWEROFF' <000b> trx_if.c:169 Sending control 'CMD POWEROFF' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP POWEROFF 0' <0001> oml.c:547 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:547 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:884 ADM state already was Unlocked <000b> trx_if.c:222 Adding new control 'CMD POWERON' <000b> trx_if.c:169 Sending control 'CMD POWERON' to phy0.0 <000b> trx_if.c:222 Adding new control 'CMD SETRXGAIN 1' <000b> trx_if.c:222 Adding new control 'CMD SETPOWER 0' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 0 4' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 1 7' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 2 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 3 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 4 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 5 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 6 13' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 7 13' <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <000b> trx_if.c:348 Response message: 'RSP POWERON 0' <000b> trx_if.c:169 Sending control 'CMD SETRXGAIN 1' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETRXGAIN 0 1' <000b> trx_if.c:169 Sending control 'CMD SETPOWER 0' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETPOWER 0 0' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 0 4' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 0 4' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 1 7' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 1 7' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 2 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 2 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 3 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 3 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 4 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 4 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 5 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 5 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 6 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 6 13' <000b> trx_if.c:169 Sending control 'CMD SETSLOT 7 13' to phy0.0 <000b> trx_if.c:348 Response message: 'RSP SETSLOT 0 7 13' <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 0 7' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 1 1' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 2 1' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 3 1' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 4 1' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 5 1' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 6 1' <000b> trx_if.c:222 Adding new control 'CMD SETSLOT 7 1' <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <0001> oml.c:884 ADM state already was Unlocked <000b> trx_if.c:138 Clock indication: fn=999376 <000b> trx_if.c:470 TX burst tn=0 fn=999396 pwr=0 <000b> trx_if.c:470 TX burst tn=1 fn=999396 pwr=0 <000b> trx_if.c:470 TX burst tn=2 fn=999396 pwr=0 ... -- Max Suraev <msuraev(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Alt-Moabit 93 * 10559 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Director: Harald Welte

2 1

[PATCH 1/2] add basic .gitignore
by Neels Hofmeyr 28 Jun '16

28 Jun '16

From: Neels Hofmeyr <neels(a)hofmeyr.de> --- .gitignore | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 .gitignore diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..3e0ee03 --- /dev/null +++ b/.gitignore @@ -0,0 +1,43 @@ +# build results +*.o +*.lo +*.la + +# tests +CommonLibs/BitVectorTest +CommonLibs/ConfigurationTest +CommonLibs/F16Test +CommonLibs/InterthreadTest +CommonLibs/LogTest +CommonLibs/RegexpTest +CommonLibs/SocketsTest +CommonLibs/TimevalTest +CommonLibs/URLEncodeTest +CommonLibs/VectorTest + +# automake/autoconf +*.in +.deps +.libs +.dirstamp +*~ +Makefile +config.log +config.status +config.h +config.guess +config.sub +config/* +configure +compile +aclocal.m4 +autom4te.cache +depcomp +install-sh +libtool +ltmain.sh +missing +stamp-h1 + +# vim +*.sw? -- 2.1.4

1 3

[PATCH] configure.ac: check for boost/config.hpp header
by Neels Hofmeyr 28 Jun '16

28 Jun '16

From: Neels Hofmeyr <neels(a)hofmeyr.de> --- configure.ac | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configure.ac b/configure.ac index 6c6ca2e..c4db4d2 100644 --- a/configure.ac +++ b/configure.ac @@ -119,6 +119,9 @@ AM_CONDITIONAL(ARCH_ARM_A15, [test "x$with_neon_vfpv4" = "xyes"]) PKG_CHECK_MODULES(LIBUSB, libusb-1.0) +AC_CHECK_HEADER([boost/config.hpp],[], + [AC_MSG_ERROR([boost/config.hpp not found, install e.g. libboost-dev])]) + dnl Output files AC_CONFIG_FILES([\ Makefile \ -- 2.1.4

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC