- OpenBSC - lists.osmocom.org

Running osmo-trx and osmo-bts-trx Shows Errors
by Ron 12 Apr '17

12 Apr '17

Hi, We just finished installing the following osmo elements using Ubuntu 14.04 and the procedures from this link: https://osmocom.org/projects/cellular-infrastructure/wiki/Ettus_USRP_B2xx_f… https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_source * libosmocore * libosmo-abis * libosmo-netif * openggsn * libosmo-sccp * openbsc * osmo-pcu * osmo-trx * osmo-bts We are now trying to run each applications to test osmo. All applications were run smoothly except for osmo-trx and osmo-bts-trx. We also installed the UHD driver of Ettus B2xx series using both “apt-get install” process and binary process as well using this link: https://files.ettus.com/manual/page_install.html https://files.ettus.com/manual/page_build_guide.html But still, the same errors were received. Errors received: # osmo-trx [INFO] [UHD] linux; GNU C++ version 4.8.4; Boost_105400; UHD_3.11.0.git-128-g379f922d opening configuration table from path :memory: 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 osmo-trx: symbol lookup error: osmo-trx: undefined symbol: _ZN3uhd6device4findERKNS_13device_addr_tE # osmo-bts-trx -c /etc/osmo-bts.cfg ((*)) | / \ OsmoBTS There is no such command. Error occurred during reading below line: fn-advance 20 Failed to parse the config file: '/etc/osmo-bts.cfg’ What seems to cause this errors? What logs do we need to check? Best Regards, Ron Rylan B. Menez Operations Manager +63 998 989 7973 +63 2 893 1781 [cid:D7861C66-51ED-4DB6-B9ED-BADEB28148EC] 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.

4 4

weekly test report (w14 2017)
by Joachim Steiger 07 Apr '17

07 Apr '17

Hi, this is the BTS test report for week14 2017. BTS models which have been tested with OsmoNITB are: - sysmoBTS1002 - octasic OCTBTS3500 - ettus USRP B200 - nanoBTS model:165G Most test cases have passed: sysmobts and nanobts worked without issue. the only one failing were with the octbts: the issues there were reliability of establishing a voicecall and or gprs. only every 2nd or 3rd attempt works. on the 3 TCH/H, 3 PDCH config gprs was not working at all with the ettus B200 everything worked but gprs seemed extremely slow or lossy. i could only view small testpages, big graphics do not load. For additional information related to test cases, timeslots configuration and voice codecs used, please visit: https://osmocom.org/projects/cellular-infrastructure/wiki/Weekly_BTS_Tests following are some git hashes/version strings of tested components: libosmo-abis: bf7976c0b0076410ad1bd67061dd18d0f33a7f43 libosmocore: ff20641d9e3bb4373f9577c3382df1480ace4e91 libosmo-netif: 5fe77a4656f3590c343861ea96bcec18e370e437 libosmo-sccp: 8e708d1f2da1b187f631bf08172a5194a85b1a23 libsmpp34: cc0bcd6bc051d5ccaf32cdbbc28f073369900857 openbsc: 2d92162a6b6720d72129bee1bcbef353b0fd0aa6 openggsn: 19e19e3609508d121ba46c165e5ed1502a3cf9da osmo-bts: e16b59357411ffa4903ac110ac4ce46d343e878d osmo-bts-octphy: e16b59357411ffa4903ac110ac4ce46d343e878d osmo-pcu: e6d26ec09c2bcd2126416a58cb23af27318ec67e osmo-trx: 6031734f448c6308d67b1ee464a13d60b33cd843 sysmobts: OsmoBTS version 0.4.0.414-e16b5 sysmobts: Osmo-PCU version 0.2.900-e6d2 octbts: (name='octsdr_gsm', desc='Software Define Radio', ver='02.07.00-B1039', ver_hdr='02.07.00-B1039') octbts: (platform='Opus2', version='OCTSYS_VERSION=01.02.19.B1;OCTODK_VERSION=01.15.01-B1;OCTADF_VERSION=04.05.01-B2637;') nanobts: Equipment_Version='165g029_79' nanobts: Software_Version='168d462_v200b202d0' if you are interested in the details, drop me a mail and i'll forward the whole report. kind regards -- - Joachim Steiger <jsteiger(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 Directors: Harald Welte

1 0

[RFC] Coding Style: Longer Line Lengths?
by Harald Welte 06 Apr '17

06 Apr '17

Dear all, [Despite today being April 1st, this is not an april fool's joke] ever since the start of the Osmocom project, we have adopted pretty much 1:1 the Linux Kernel coding style. Having a uniform coding style all over the project is important for readability, and from my point of view it doesn't really matter too much which style it is, as long as it is uniform accross the projects. I'm still fine with the Linux kernel coding style for most parts, but I think we could consider allowing longer lines. 80 characters is still nice here and there, but maybe something like 100, 120 or even 130 might actually make the code more readable and permit us to use slightly longer identifiers without having to wrap every second statement in the code. What do people generally think here? 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)

10 16

DBus usage
by Neels Hofmeyr 05 Apr '17

05 Apr '17

Hi Pau (and maybe others), here is a test script that showcases how I'd like to use DBus in the osmo-gsm-tester: use pydbus and keep the glib main loop in a thread (to handle DBus signals only). It sounds ambitious but the test program actually works. Would be great to hear your opinion on it: http://git.osmocom.org/osmo-gsm-tester/tree/selftest/dbus_test/ofono_client… The same thing cosmetically rearranged as module stub: http://git.osmocom.org/osmo-gsm-tester/tree/src/osmo_gsm_tester/dbus_client… Thanks! ~N Related: OS#1980 https://osmocom.org/issues/1980 -- - 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

1 0

osmo-bts Installation Issue
by Ron 04 Apr '17

04 Apr '17

Hi All, Requesting your help regarding the case that we had encountered during the installation of osmo-bts using UBUNTU 14.04 as OS. Without using the 201509-fairwaves-rebase, the installation go past through. Unfortunately, there is no “osmo-bts-trx” executable. Below are the steps we followed for the installation of osmo-bts. cd /opt/osmo/src/ git clone git://git.osmocom.org/osmo-bts cd osmo-bts autoreconf -fi ./configure make -j5 make check make install We tried using the 201509-fairwaves-rebase, but unfortunately the installation stops and an error was encountered during the “make” process. Below are the installation steps and error encountered: cd /opt/osmo/src/ git clone git://git.osmocom.org/osmo-bts cd osmo-bts git checkout 201509-fairwaves-rebase autoreconf -fi ./configure --enable-trx make Error encountered: make[2]: Entering directory `/opt/osmo/src/osmo-bts/src' Making all in common make[3]: Entering directory `/opt/osmo/src/osmo-bts/src/common' CC gsm_data_shared.o CC sysinfo.o CC logging.o CC abis.o abis.c: In function ‘abis_open’: abis.c:233:25: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default] bts_dev_info.unit_name = model_name; ^ abis.c:236:25: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default] bts_dev_info.location2 = model_name; ^ CC oml.o oml.c:46:30: error: conflicting type qualifiers for ‘abis_nm_att_tlvdef_ipa’ static struct tlv_definition abis_nm_att_tlvdef_ipa = { ^ In file included from oml.c:33:0: /usr/local/include/osmocom/gsm/abis_nm.h:37:36: note: previous declaration of ‘abis_nm_att_tlvdef_ipa’ was here extern const struct tlv_definition abis_nm_att_tlvdef_ipa; ^ oml.c:373:6: error: nested redefinition of ‘enum abis_nm_t200_idx’ enum abis_nm_t200_idx { ^ oml.c:373:6: error: redeclaration of ‘enum abis_nm_t200_idx’ In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:647:6: note: originally defined here enum abis_nm_t200_idx { ^ oml.c:374:2: error: redeclaration of enumerator ‘T200_SDCCH’ T200_SDCCH = 0, ^ In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:648:2: note: previous definition of ‘T200_SDCCH’ was here T200_SDCCH = 0, ^ oml.c:375:2: error: redeclaration of enumerator ‘T200_FACCH_F’ T200_FACCH_F = 1, ^ In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:649:2: note: previous definition of ‘T200_FACCH_F’ was here T200_FACCH_F = 1, ^ oml.c:376:2: error: redeclaration of enumerator ‘T200_FACCH_H’ T200_FACCH_H = 2, ^ In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:650:2: note: previous definition of ‘T200_FACCH_H’ was here T200_FACCH_H = 2, ^ oml.c:377:2: error: redeclaration of enumerator ‘T200_SACCH_TCH_SAPI0’ T200_SACCH_TCH_SAPI0 = 3, ^ In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:651:2: note: previous definition of ‘T200_SACCH_TCH_SAPI0’ was here T200_SACCH_TCH_SAPI0 = 3, ^ oml.c:378:2: error: redeclaration of enumerator ‘T200_SACCH_SDCCH’ T200_SACCH_SDCCH = 4, ^ In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:652:2: note: previous definition of ‘T200_SACCH_SDCCH’ was here T200_SACCH_SDCCH = 4, ^ oml.c:379:2: error: redeclaration of enumerator ‘T200_SDCCH_SAPI3’ T200_SDCCH_SAPI3 = 5, ^ In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:653:2: note: previous definition of ‘T200_SDCCH_SAPI3’ was here T200_SDCCH_SAPI3 = 5, ^ oml.c:380:2: error: redeclaration of enumerator ‘T200_SACCH_TCH_SAPI3’ T200_SACCH_TCH_SAPI3 = 6 ^ In file included from oml.c:32:0: /usr/local/include/osmocom/gsm/protocol/gsm_12_21.h:654:2: note: previous definition of ‘T200_SACCH_TCH_SAPI3’ was here T200_SACCH_TCH_SAPI3 = 6 ^ make[3]: *** [oml.o] Error 1 make[3]: Leaving directory `/opt/osmo/src/osmo-bts/src/common' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/osmo/src/osmo-bts/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/osmo/src/osmo-bts' make: *** [all] Error 2 We followed the installation process from the URLs below: https://osmocom.org/projects/cellular-infrastructure/wiki/Ettus_USRP_B2xx_f… https://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_source Best Regards, Ron Rylan B. Menez Operations Manager +63 998 989 7973 +63 2 893 1781 [cid:D7861C66-51ED-4DB6-B9ED-BADEB28148EC] 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.

2 2

RFC: speed up gerrit verifications by using dependency artifacts
by André Boddenberg 31 Mar '17

31 Mar '17

Hi, some weeks a go the topic about using dependency-artifacts to speed up gerrit verifications was mentioned by Neels in the "RFC: jenkins pipeline" thread [1]. I was curious and wrote a bash script (osmo-artifacts.sh) [2], which enables build jobs to archive and fetch dependencies. Instead of Docker it simply uses archives to store them. An artifact's name has the following form: ( n(${project}.${branch}.${shortRev}_) ).tar.gz Openbsc builds are 50 % faster when using artifacts. [3] The jenkins.sh [2] script had to be slightly modified i.e. basically split into two functions: 1) buildProjectDeps() 2) buildProject() A third function to generate the artifact name has been added. The template.sh [2] script illustrates this description. What do you think about the result/artifactStore/approach in general? A cleanUpArtifactStore.sh script running as a cron job is already on my mind, but imo it's a good point to discuss the intermediate result. blobb [1] http://lists.osmocom.org/pipermail/openbsc/2017-March/010400.html [2] git clone https://github.com/blobbsen/diy-artifacts.git [3] https://jenkins.blobb.me/job/openBSC_multi-configuration_withArtifacts_test…

4 6

weekly test report (w13 2017)
by Joachim Steiger 31 Mar '17

31 Mar '17

Hi, this is the BTS test report for week13 2017. BTS models which have been tested with OsmoNITB are: - sysmoBTS1002 - octasic OCTBTS3500 - ettus USRP B200 - nanoBTS model:165G All test cases have passed. For additional information related to test cases, timeslots configuration and voice codecs used, please visit: https://osmocom.org/projects/cellular-infrastructure/wiki/Weekly_BTS_Tests following are some git hashes/version strings of tested components: libosmo-abis: 5e87fdfcabc9cabe0025d7350b7ab31cdc4b6fa3 libosmocore: d78c973cd89fc7c119573357cfbebb891dbc697a libosmo-netif: 5fe77a4656f3590c343861ea96bcec18e370e437 libosmo-sccp: 8e708d1f2da1b187f631bf08172a5194a85b1a23 libsmpp34: cc0bcd6bc051d5ccaf32cdbbc28f073369900857 openbsc: b1e6b3749389ec5b3f33d5ac0fcc7f43df3f4641 openggsn: 19e19e3609508d121ba46c165e5ed1502a3cf9da osmo-bts: e16b59357411ffa4903ac110ac4ce46d343e878d osmo-bts-octphy: e16b59357411ffa4903ac110ac4ce46d343e878d osmo-pcu: e6d26ec09c2bcd2126416a58cb23af27318ec67e osmo-trx: e0c12189d455eb0d17299e4504749ce36629e18b sysmobts: OsmoBTS version 0.4.0.414-e16b5 sysmobts: Osmo-PCU version 0.2.900-e6d2 octbts: (name='octsdr_gsm', desc='Software Define Radio', ver='02.07.00-B1039', ver_hdr='02.07.00-B1039') octbts: (platform='Opus2', version='OCTSYS_VERSION=01.02.19.B1;OCTODK_VERSION=01.15.01-B1;OCTADF_VERSION=04.05.01-B2637;') nanobts: Equipment_Version='165g029_79' nanobts: Software_Version='168d462_v200b202d0' if you are interested in the details, drop me a mail and i'll forward the whole report. kind regards -- - Joachim Steiger <jsteiger(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 Directors: Harald Welte

1 0

commit python script to openbsc/contrib
by Keith Whyte 30 Mar '17

30 Mar '17

Hi all. I have a python script I'd like to commit to openbsc/contrib. It reads the SMS table, gives stats and retrieves individual messages. - should maybe go in openbsc/contrib/sms ? Anyway, should I submit this via gerrit + code review or is there another way? There's really no point in having jenkins look at it, right? Thanks! k.

2 1

pysim has moved to gerrit
by Neels Hofmeyr 28 Mar '17

28 Mar '17

pysim patches are managed by gerrit from now on. ~N

1 0

[PATCH 0/2] fixes for pysim
by Philipp Maier 27 Mar '17

27 Mar '17

Hello, I would like to propose the two changes for pysim, the first is for fixing the sysmo-usim-sjs1 support and the second fixes the missing support for writing the ICCID to a sysmo-usim-sjs1. If there are no major concerns with that I would like to merge the two patches to master. Repo: https://git.osmocom.org/pysim Branch: pmaier/fixfci regards, Philipp Maier Philipp Maier (2): Fix select control parameter fix writing of ICCID for sysmo-usim-sjs1 pySim/cards.py | 15 ++++++++------- pySim/commands.py | 11 +++++++++-- 2 files changed, 17 insertions(+), 9 deletions(-) -- 1.9.1

5 9