OpenBSC May 2017

openbsc@lists.osmocom.org

26 participants
55 discussions

by Ron

Hi All, We are looking for a way to route all SMS to freeswitch to convert it to SIP-Message. The reason behind this is a better control and additional VAS for SMS transactions. The forum that we had stumble upon is dated four years ago (http://openbsc.osmocom.narkive.com/9hGGHzZP/help-with-asterisk-setup-to-sto…) and it seems that it was not yet supported by OSMO-NITB by that time. Not sure if there is already an existing document regarding this case but, can anyone confirm if this is doable and help us on how to do it? We are using the following: OS: Ubuntu 16.10 OSMO Elements: osmo-nitb osmo-sip-connector osmo-bts-trx osmo-trx Ettus SDR Best Regards, Ron Rylan B. Menez

8 years, 3 months

[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, 3 months

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, 3 months

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, 3 months

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, 3 months

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, 3 months

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, 3 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, 3 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, 3 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, 3 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC May 2017