OpenBSC

openbsc@lists.osmocom.org

4 participants
4156 discussions

[osmo-iuh UNKNOWN] testsuite: 1 2 3 failed

by Mo Saman

Hi.. Sending logs as instructed by install script make[5]: Leaving directory '/home/saman/osmo-iuh/src/tests' make check-local make[5]: Entering directory '/home/saman/osmo-iuh/src/tests' /bin/bash './testsuite' ## ---------------------------- ## ## osmo-iuh UNKNOWN test suite. ## ## ---------------------------- ## Regression tests. 1: helpers FAILED (testsuite.at:9) 2: hnbap FAILED (testsuite.at:15) 3: ranap FAILED (testsuite.at:21) ## ------------- ## ## Test results. ## ## ------------- ## ERROR: All 3 tests were run, 3 failed unexpectedly. ## -------------------------- ## ## testsuite.log was created. ## ## -------------------------- ## Please send `src/tests/testsuite.log' and all information you think might help: To: <openbsc(a)lists.osmocom.org> Subject: [osmo-iuh UNKNOWN] testsuite: 1 2 3 failed You may investigate any problem if you feel able to do so, in which case the test suite provides a good starting point. Its output may be found below `src/tests/testsuite.dir'. Makefile:796: recipe for target 'check-local' failed make[5]: *** [check-local] Error 1 make[5]: Leaving directory '/home/saman/osmo-iuh/src/tests' Makefile:650: recipe for target 'check-am' failed make[4]: *** [check-am] Error 2 make[4]: Leaving directory '/home/saman/osmo-iuh/src/tests' Makefile:623: recipe for target 'check-recursive' failed make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory '/home/saman/osmo-iuh/src' Makefile:772: recipe for target 'check' failed make[2]: *** [check] Error 2 make[2]: Leaving directory '/home/saman/osmo-iuh/src' Makefile:439: recipe for target 'check-recursive' failed make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory '/home/saman/osmo-iuh' Makefile:730: recipe for target 'check' failed make: *** [check] Error 2 Mo Saman Chief Platform Architect +1 202 621 0097 <mailto:m.saman@cerebrosphere.com> m.saman(a)cerebrosphere.com

8 years, 1 month

Filename for HLR sqlite3 Database in 3G network?

by Andreas Mueller

Hallo, when setting up a 3G network with the nano3G the default filename of the HLR according to osmo-hlr is hlr.db (source code: hlr.c), but the run.sh script, which is included in https://osmocom.org/attachments/download/2636/3G-config-example-v5.tar tries to access hlr.sqlite3 (7th line: sqlite3 hlr.sqlite3 "delete from sms"). So, when starting an error message occures: "Error: no such table: sms". greetings, Andreas

8 years, 1 month

osmo-nitb | subscriber-create-on-demand random

by Ron

Hi All, We are trying to used a specific pool of number (extension) for the "subscriber-create-on-demand” configuration in osmo-nitb. Unfortunately, when we used the range from 9570000000 to 9579999999, it returns a different value upon running “show running-config”. So we tried to change it from the config file of openbsc.conf. After restarting the osmo-nitb application, different value still shows upon running “show running-config”. But the supported Min and Max value for the "subscriber-create-on-demand random” is from 1-9999999999. Attached is the config file we used and below is the “show running-config” value of "subscriber-create-on-demand random" value. nitb subscriber-create-on-demand subscriber-create-on-demand random 980065408 990065407 no assign-tmsi Best Regards, Ron Rylan B. Menez

8 years, 1 month

Question about multiplexed GSM signal

by Marcus Dias

Dear all, Most BTS code I have, generate only one or two 200 kHz channels, but I need to test a receiver using several (multiplexed) 200 kHz channels, composing approximately 5 MHz of total bandwidth. This should be a "valid" multiplex signal (correct and "decodable" control channel). Can anyone pointout where should I start to put together the software to generate a binary file with such signal? I guess I can inspect the code of a BTS that supports two TRX (two 200 kHz channels) but I would like to double check whether there is a more direct approach. Thanks beforehand, Marcus Dias UFPA - Lasse - LaPS

8 years, 1 month

Re: libosmocore[master]: doc: fix incorrect return value description

by Neels Hofmeyr

On Wed, May 10, 2017 at 12:43:42PM +0000, Max wrote: > To view, visit https://gerrit.osmocom.org/2552 > > Patch Set 1: > > > I guess this could use an entry in 'TODO-RELEASE' to note the fixed API? > > Why? TODO-RELEASE is for keeping track of API/ABI changes so we bump corresponding versions when necessary. Docstring change requires neither API not ABI bump. In my view the API doc describes how the API/ABI *should* behave, and if it mismatches that's like a bug in the API. If we fix that bug, that's interesting for users of the API, right? ~N

8 years, 1 month

osmo-trx version question

by Max

Hi. Is there a way for osmo-bts-trx to get osmo-trx version programmatically (at runtime)? -- 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

8 years, 2 months

Re: FreeBSD C compiler version

by Vadim Yanitskiy

Hi Max and Harald, As I mentioned above, my suggestion is to keep the source code "as portable as possible", which doesn't mean absolutely portable. I don't suggest to add other UNIX platforms (Darwin, Solaris, etc.) to our portability scope, I suggest to perform checks on the same platforms as we currently do, but additionally to have both Clang and GCC on both slaves. Why Clang? - it's default compiler on FreeBSD (recent distributions); - it has its own big community; - it has growing compatibility with GCC, see: en.wikipedia.org/wiki/Clang#Performance_and_GCC_compatibility Why different versions? - different distributions provide different versions available out of the box, i.e. some (such as FreeBSD) provide the latest version, while some other provide a bit dated versions; - some things may change in newer versions, e.g. from my recent experience: Clang 4.0 has support of the __builtin_cpu_supports built-in, while older versions don't. I see the only disadvantage of this approach - longer total build time. So, if you guys support this idea, I could do all configuration and installation related work. Also, I'll try to contribute some computing power to Jenkins: there are some servers in my university, which power isn't used anyhow, so they mostly idle all the time. > Recently I decided to dig into FreeBSD's world, because one of my > changes in Gerrit does build fine on Debian slave, but doesn't on > FreeBSD. Here I found the problem. Cite from GCC's documentation page x86-Built-in-Functions.html at gcc.gnu.org: > If you specify command-line switches such as -msse, the compiler > could use the extended instruction sets even if the built-ins > are not used explicitly in the program. For this reason, applications > that perform run-time CPU detection must compile separate files for > each supported architecture, using the appropriate flags. In > particular, the file containing the CPU detection code should be > compiled without these options. Adding SIMD flags to a whole project breaks portability between different CPUs, so I added these flags for viterbi_sse.lo only. Now the problem seems solved. With best regards, Vadim Yanitskiy.

8 years, 2 months

Re: FreeBSD C compiler version

by Vadim Yanitskiy

Dear all, > @fixeria: re the C compiler used on the FreeBSD build slave: > it is actually, apparently: > > FreeBSD clang version 3.4.1 > 20140512 > x86_64-unknown-freebsd10.3 > > At least that's what a libosmocore ./configure step shows in > its config.log. I would like to start a little discussion about FreeBSD build slave. As it turned out, every new commit is being checked on clang compiler too! It was a bit unexpectedly to me, because we already discussed about this in Gerrit: https://gerrit.osmocom.org/#/c/2100/ > Max: > > Do we officially support anything besides gcc? > > Harald: > > not really, but then it is also nice to be portable. My vote > > would be to merge the current patch under discussion, but open > > a ticket as a reminder that this should be made more portable. > > I suppose mplayer/ffmpeg/fftw or other libs with heavily > > optimized algorithms also have a solution to that. Recently I decided to dig into FreeBSD's world, because one of my changes in Gerrit does build fine on Debian slave, but doesn't on FreeBSD. So, I spent a whole night with my laptop and finally installed and configured FreeBSD first time in my experience. https://gerrit.osmocom.org/#/c/2100/ I am running 11.0 STABLE, and by default it comes with clang as default compiler. There is no GCC installed by default. I tried to build my change with different versions of clang and found the following interesting facts: - Recent clang-4.0 does support the __builtin_cpu_supports call, so runtime CPU detection should work in this case too. I don't know if it works in other versions. So, I suggest to add a new configure.ac task, which would check whether compiler supports this call or not. - Regarding to my change, it builds fine on several tested clang versions: clang-3.4.2, clang-3.9, clang-4.0. And I see two possible reasons, why the build fails on FreeBSD: 1) Version 3.4.1 is pretty dated, and we cat try to upgrade it. 2) Clang compiles the source code in a different way, when some SIMD flags are provided. But target CPU doesn't support some of provided SIMD flags. Now in both OsmoTRX and libosmocore we only check whether compiler supports some SIMD flags, but we don't check whether these flags are supported by current build machine CPU. So, lack of the last check and specific optimization / compilation way of clang may cause the fail. I still need to know supported SIMD features of FreeBSD build machine to confirm or refute this assumption. I also have an idea: what if we could build our projects with several compilers (GCC and clang) and with their several versions (the three latest for example) on Jenkins at the same time? I think, it would be great to keep our projects as portable as possible. With best regards, Vadim Yanitskiy.

8 years, 2 months

nano3G Access Points Authorization

by root＠雪碧

Hello, I want to configure the nano3G Access Points through 8089 port ( nano3G AP’s configuration web page )，but i don't konw the username and password . what should i do? http://www.ipaccess.com/uploads/wysiwyg_editor/files/2017/S8_S16-Datasheet-… Best regards.

8 years, 2 months

Re: Undeliverable: PCU broken: PACCH paging omitted

by Neels Hofmeyr

On Fri, May 05, 2017 at 03:28:48PM +0000, postmaster(a)Radisyscorp.onmicrosoft.com wrote: > Your message to Sivasankari.Theerthagiri(a)radisys.com couldn't be delivered. > > Sivasankari.Theerthagiri wasn't found at radisys.com. Dear Radisys, since we are having a problem with a patch from Sivasankari Theerthagiri and since that contact is apparently no longer available, do you have another contact that could help resolve the issue? Thanks! ~N > From: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> > To: openbsc(a)lists.osmocom.org > CC: sivasankari <Sivasankari.Theerthagiri(a)radisys.com> > Subject: PCU broken: PACCH paging omitted > User-Agent: Mutt/1.5.23 (2014-03-12) > > Trying to fix a PCU breakage, I introduced another error, causing paging to be > broken. All the details are at: > https://osmocom.org/issues/2241 > https://gerrit.osmocom.org/2420 > > I need help: could anyone verify whether the patch is doing the right thing > now? Otherwise we will need to revert the whole series of breaking patches: > > http://git.osmocom.org/osmo-pcu/commit/?id=da7250ad2c1cd5ddc7d3c6e10435a00b… > "Add counter at BTS level And statistics at TBF/MS level." > sivasankari <Sivasankari.Theerthagiri(a)radisys.com> > > http://git.osmocom.org/osmo-pcu/commit/?id=b78a4a6dfef217c538d45949a6ae725e… > "fix segfault: check for NULL tbf in sched_select_ctrl_msg()" > Neels Hofmeyr <nhofmeyr(a)sysmocom.de> > > Thanks for any help! > > ~N -- - 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

8 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC