OpenBSC May 2017

openbsc@lists.osmocom.org

26 participants
57 discussions

Start a nNew thread

UMTS
by sami 03 May '17

03 May '17

Hi all, Does OpenBSC support UMTS like the OpenBTS-UMTS ? best regards,

2 3

autoreconf: "header not found" in generated source
by Vadim Yanitskiy 02 May '17

02 May '17

Hi all, I am currently working on https://gerrit.osmocom.org/#/c/2075/ The problem is that the conv.h should be shared between several source code files, and it works fine for all of them, excepting the gsm0503_test_vectors.c, which will be generated automatically by the utils/conv_gen.py in the next commit. The header is currently included this way: #include "conv.h" And building in separate directory fails: CC conv/gsm0503_test_vectors.o conv/gsm0503_test_vectors.c:25:18: fatal error: conv.h: No such file or directory #include "conv.h" ^ compilation terminated. This is why I tried to move this header to the global include directory. According to received feedback from Harald and Sylvain, this approach isn't good and I need to find another one. Any suggestions how to make the conv/gsm0503_test_vectors.c able "to see" the conv.h header? With best regards, Vadim Yanitskiy.

4 8

osmo-bts-trx error / osmo-trx illegal instruction (core dumped)
by Ron 02 May '17

02 May '17

Hi All, Upon running "osmo-bts-trx -c osmo-bts.cfg” while "osmo-nitb -C -c openbsc.conf -T -P -m” and “osmo-trx” are running, the following error shows and also shuts down “osmo-trx” osmo-bts-trx error: root@entropy:~/osmocom_files# osmo-bts-trx -c osmo-bts.cfg ((*)) | / \ OsmoBTS <0017> control_if.c:725 CTRL at 127.0.0.1 4238 <0010> telnet_interface.c:95 telnet at 127.0.0.1 4241 <0012> input/ipaccess.c:885 enabling ipaccess BTS mode, OML connecting to 192.168.1.129:3002 <000b> trx_if.c:584 Open transceiver for phy0.0 <0012> input/ipa.c:129 connection done. <0012> input/ipaccess.c:706 received ID get <0001> oml.c:475 Ignoring T200[0] (150 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:475 Ignoring T200[1] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:475 Ignoring T200[2] (180 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:475 Ignoring T200[3] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:475 Ignoring T200[4] (520 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:475 Ignoring T200[5] (165 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:475 Ignoring T200[6] (1680 ms) as sent by BSC due to suspected LAPDm bug! <0001> oml.c:844 ADM state already was Unlocked <0012> input/ipa.c:129 connection done. <0012> input/ipaccess.c:706 received ID get <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <0009> pcu_sock.c:651 PCU socket not connected, dropping message <000b> trx_if.c:187 No response from transceiver for phy0.0 <0009> pcu_sock.c:848 PCU socket connected to external PCU <0001> oml.c:72 Reporting FAILURE to BSC: 0.3.20170425 <0000> rsl.c:624 (bts=0,trx=0,ts=4,ss=0) not sending CHAN ACT ACK <0000> rsl.c:624 (bts=0,trx=0,ts=5,ss=0) not sending CHAN ACT ACK <0000> rsl.c:624 (bts=0,trx=0,ts=6,ss=0) not sending CHAN ACT ACK <0000> rsl.c:624 (bts=0,trx=0,ts=7,ss=0) not sending CHAN ACT ACK <000b> trx_if.c:187 No response from transceiver for phy0.0 <000b> trx_if.c:187 No response from transceiver for phy0.0 <000b> trx_if.c:187 No response from transceiver for phy0.0 <000b> trx_if.c:187 No response from transceiver for phy0.0 <000b> trx_if.c:187 No response from transceiver for phy0.0 <000b> trx_if.c:187 No response from transceiver for phy0.0 <000b> trx_if.c:187 No response from transceiver for phy0.0 <000b> trx_if.c:187 No response from transceiver for phy0.0 <0007> l1sap.c:413 Invalid condition detected: Frame difference is > 1! <0001> bts.c:208 Shutting down BTS 0, Reason No clock from osmo-trx <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <0000> rsl.c:528 (bts=0,trx=0,ts=4,ss=0) not sending REL ACK <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <0000> rsl.c:528 (bts=0,trx=0,ts=5,ss=0) not sending REL ACK <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <0000> rsl.c:528 (bts=0,trx=0,ts=6,ss=0) not sending REL ACK <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <000b> trx_if.c:203 CTRL NOHANDOVER ignored: No clock from transceiver, please fix! <0000> rsl.c:528 (bts=0,trx=0,ts=7,ss=0) not sending REL ACK Shutdown timer expired osmo-trx logs: NOTICE 139966735525632 16:51:01.4 Transceiver.cpp:794:driveControl: Changing TSC from 0 to 7 NOTICE 139966735525632 16:51:01.4 Transceiver.cpp:243:start: Starting the transceiver Illegal instruction (core dumped) osmo-nitb logs: Thu Apr 27 16:50:43 2017 <001e> input/ipa.c:263 accept()ed new link from 192.168.1.129 to port 3002 Thu Apr 27 16:50:43 2017 <001e> input/ipa.c:263 accept()ed new link from 192.168.1.129 to port 3003 Thu Apr 27 16:50:43 2017 <0004> bsc_init.c:288 bootstrapping RSL for BTS/TRX (0/0) on ARFCN 885 using MCC=1 MNC=1 LAC=1 CID=1 BSIC=63 BTS 0 reported connected PCU version 0.3.20170425 Thu Apr 27 16:51:06 2017 <001e> input/ipaccess.c:241 Sign link vanished, dead socket Thu Apr 27 16:51:06 2017 <001e> input/ipaccess.c:69 Forcing socket shutdown with no signal link set Thu Apr 27 16:51:06 2017 <0020> bsc_init.c:341 Lost some E1 TEI link: 1 0x7f5f48820070 Thu Apr 27 16:51:06 2017 <0020> bsc_init.c:341 Lost some E1 TEI link: 2 0x7f5f48820070 ^Csignal 2 received Also attached the configuration files used. What seems causes the issue? OS: Ubuntu 16.04 SDR: B210 Best Regards, Ron Rylan B. Menez Operations Manager +63 998 989 7973 +63 2 893 1781 [cid:bbb8aa9b-ea08-431b-bb55-8cc77a18e169@apcprd06.prod.outlook.com] Singapore * Philippines Products: Gridloc*Intelle*Hype*Lighthouse*Telco Services*Software Development This email (including any attachment to it) is confidential and intended only for the use of the individual named above and may contain information that is privileged. If you are not the intended recipient, you are notified that any dissemination, distribution or copying of this email is strictly prohibited. If you have received this email in error, please notify us immediately by return email or telephone and destroy the original message (including any attachment to it). Thank you.

5 13

FreeBSD C compiler version
by Neels Hofmeyr 02 May '17

02 May '17

@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. ~N

1 0

nano3G <-> sip-connector <-> asterisk?
by Andreas Mueller 02 May '17

02 May '17

Hello, is it possible to connect the openbsc from the vlr_3G Branch with sip-connector to asterisk as described on https://osmocom.org/projects/osmo-sip-conector/wiki/Osmo-sip-connector, or are there changes in the vlr_3G Branch that makes this impossible? When trying to set this up I was able to call an UMTS-Phone which was connected to the nano3G from a softphone using jitsi, and the UMTS-Phone was ringing, but it was not possible to answer the call. I have only limited experiences with asterisk and so I am for example unsure about what voice-codecs to use, if my asterisk-config is correct,... and so I would like to know if it should work in principle and I have to find the correct configuration. have a nice weekend, Andreas

2 1

Using repo to make 'regular' releases
by Holger Freyther 02 May '17

02 May '17

Hi, for the topic of making "releases" I wondered if we want to explore using "repo" to tie the different Osmocom repositories into a single "release". Below is an example "default.xml" that would make up a release. The default.xml would be maintained in a git repository that we could tag, e.g. something like v201704.1 (vYYYYMM.MINOR). I could envision we have: * A simple build shell script to build/install everything * A script to update (and tag) the default.xml to make new releases available. How to use it (if repo is installed): repo init -u git://git.osmocom.org/osmocom-cellular-manifest repo sync ./build_all.sh --prefix=/opt/cellular aand on a new release repo sync ./build_all.sh ... ideas? comments? holger default.xml: <?xml version="1.0" encoding="UTF-8"?> <manifest> <remote fetch="git://git.osmocom.org" review="gerrit.osmocom.org" name="osmocom"/> <default revision="refs/heads/master" remote="osmocom"/>  <project name="libosmocore" revision="9e83c3d5ca64428befe74e5aad61bd84bccaf309"/> <project name="libosmo-abis" revision="bf7976c0b0076410ad1bd67061dd18d0f33a7f43"/> <project name="libosmo-netif" revision="c108c9db969c4d4abaccc88419b4ac0c44957365"/> <project name="libsmpp34" revision="cc0bcd6bc051d5ccaf32cdbbc28f073369900857"/> <project name="libosmo-sccp" revision="57d0449d4ed5d82050c52551c8ad6195db38fdf1"/>  <project name="osmo-trx" revision="de116e90c03c534fa4b51ef40dfd2bb9e843c86e"/> <project name="osmo-bts" revision="25742a5929edecc545a4fc254f678cc834f8c3b3"/> <project name="osmo-pcu" revision="e6d26ec09c2bcd2126416a58cb23af27318ec67e"/> <project name="osmo-iuh" revision="46fea15afc38fb995baf4100f4de1d6a3565899f"/> <project name="openggsn" revision="19e19e3609508d121ba46c165e5ed1502a3cf9da"/> <project name="openbsc" revision="d75f11e6f26a50c11f73625de5c0833971900cde"/> <project name="osmo-sip-connector" revision="417f2542163edfe8ac8729918e2452dc7787a3d7"/>  <project name="osmo-hlr" revision="743cf42ac5dfa2661317e73f70b204bde7450ff2"/>  <project name="osmo-gsm-manuals" revision="4b593a2259a107211489940b8b59f44219e73b2d"/>  <project name="osmo-ci" revision="e72f35cfa9969e52d0018ba4661f4519519c39ba"> <linkfile src="build/build.sh" dest="build.sh"/> </project> <project name="python/osmo-python-tests" path="osmo-python-tests" revision="baa6f12260c383f40a477b71743b16940c50e5aa"/> </manifest>

6 14

core/conv: SCH decoding problem
by Vadim Yanitskiy 01 May '17

01 May '17

Hi Tomas, I again have a question related to your SSE accelerated Viterbi decoder, and I hope it's the last issue, which prevents us from finishing this work. In short, SSE based implementation provides one-byte different decoding result for SCH transcoding test. So, the whole GSM 05.03 coding test fails. I have done some debugging, and would like to share some results. Have a look at the tests/coding/test_sch(), which first encodes a L3 packet into ubits and sbits, then some bits are getting destroyed, then the gsm0503_sch_decode() is being called to get decoded bytes back, and finally decoded bytes are being compared with original bytes. As long as encoder implementation is not covered by SSE code, it works as before. But SSE accelerated decoder outputs one-byte different result in case of SCH: int gsm0503_sch_decode(uint8_t *sb_info, sbit_t *burst) { ubit_t conv[35]; int rv; osmo_conv_decode(&gsm0503_sch, burst, conv); rv = osmo_crc16gen_check_bits(&gsm0503_sch_crc10, conv, 25, conv + 25); if (rv) return -1; // ... } // Original implementation ubit_t conv[35] = { 0x01 0x01 0x00 0x01 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x01 0x01 0x01 0x00 0x01 0x00 }; // Accelerated implementation ubit_t conv[35] = { 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01 0x00 0x00 0x01 0x01 0x01 0x00 0x01 0x00 }; As you can see, the conv[3] isn't the same in both cases. So, at the next step the osmo_crc16gen_check_bits() returns -1. Latest version of this change: https://gerrit.osmocom.org/#/c/2454/ Do you have any ideas? Despite SCH decoding isn't required on BTS side, the problem may be more global, than the test shows. With best regards, Vadim Yanitskiy.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC May 2017