OpenBSC

openbsc@lists.osmocom.org

4 participants
4156 discussions

by Ron

Hi All, We are having “INCOMPATIBLE_DESTINATION” error in Freeswitch using the half rate configuration of each timeslots in NITB. Our setup have 1 OSMO-NITB (with OSMO-BTS-TRX, OSMO-TRX, and OSMO-SIP-CONNECTOR) and 2 Freeswitch. One of the Freeswitch is local in the server while the other Freeswitch is at the cloud. Using the Full Rate Configuration of each timeslots, we do not encounter the “INCOMPATIBLE_DESTINATION” error and we successfully connected 2 phone calls. Upon using the Half Rate Configuration, "INCOMPATIBLE_DESTINATION” error occurs. We played around the codecs of Freeswitch but unfortunately, we were not able to complete the call. It always disconnects the call immediately after the MT answers. Does anyone tried this kind of setup before? What equivalent codec does the “default-codec tch/h hr” or GSM-HR-08 as seen in Freeswitch? OS: Ubuntu 16.10 OSMO Elements: OSMO-TRX OSMO-BTS-TRX OSMO-NITB OSMO-SIP-CONNECTOR SDR: Ettus B210 Softswitch: Freeswitch (Version 1.6) Attached are the config files used for OSMO Elements. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

8 years, 1 month

libosmocore embedded build

by Harald Welte

Dear all, when we originally moved a lot of generic code from OpenBSC to libosmo{core,gsm} to re-use it from OsmocomBB, we created an 'embedded' build of libosmocore, which can use [most of] the library code also in deeply embedded, OS-less 'bare metal' microcontroller environments. The ability to build libosmocore this way has been broken for many years, but I've fixed that in recent libosmocore master. Below command works for me [tm]: ./configure --prefix=/usr/local/arm-none-eabi \ --host=arm-none-eabi \ --enable-embedded \ --disable-shared \ CFLAGS="-Os -ffunction-sections -fdata-sections -nostartfiles -nodefaultlibs" What we'd need now is: 1) make sure embedded builds continue to work by building libosmocore for embedded as part of the jenkins setup (using gcc-arm-none-eabi debian package). Any volunteers? 2) start to use this embedded build from simtrace2 firmware, osmocom-bb and the upcoming fimrware for the RFDN[1]. So far, * osmocom-bb uses an old clone of libosmocore, * simtrace2 is using some copy+pasted fork of some libosmocore files * rfdn is using some copy+pasted fork of some libosmocore files The above is no longer required. 3) consider if we can shrink the resource requirements of some libosmocore parts. One issue coming up are the static buffers in osmo_hexdump[] or the like. If your total processor RAM is 8k or 16k, then spending 4k on the buffer for hex-dumping is indeed a bit excessive. Any help is appreciated, particularly on the jenkins side. Regards, Harald [1] (1:8 splitter-combiner with adjustible step attenuators, part of the osmo-gsm-tester setup we're building at sysmocom). Code will be released as soon as the hardware is validated. -- - 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)

8 years, 1 month

Re: libosmocore embedded build

by Craig Comstock

> Can someone else may have a > quick look at log [2] to point me in the > right direction? Afaics build dependencies are > available but the > compilation itself > fails. > [2] https://jenkins.osmocom.org/jenkins/job/TEST_libosmocore_arm_none_eabi/arch… Looks like the tests are failing. My build seems to work but when I run "make check-am" in tests I get a different error related to talloc. This is on a Debian 8 stable box using arm-none-eabi and newlib from debian packages. Maybe the make of timer_test fails and doesn't log somehow? I"m not sure. craig@z500:~/libosmocore/tests$ vi timer/timer_test. timer_test.c timer_test.ok craig@z500:~/libosmocore/tests$ vi timer/timer_test.c craig@z500:~/libosmocore/tests$ make check-am make timer/timer_test sms/sms_test ussd/ussd_test smscb/smscb_test bits/bitrev_test a5/a5_test conv/conv_test auth/milenage_test lapd/lapd_test gsm0808/gsm0808_test gsm0408/gsm0408_test gb/bssgp_fc_test gb/gprs_bssgp_test gb/gprs_ns_test gprs/gprs_test kasumi/kasumi_test gea/gea_test logging/logging_test fr/fr_test codec/codec_test loggingrb/loggingrb_test strrb/strrb_test vty/vty_test comp128/comp128_test utils/utils_test smscb/gsm0341_test stats/stats_test ctrl/ctrl_test bitvec/bitvec_test msgb/msgb_test bits/bitcomp_test tlv/tlv_test gsup/gsup_test oap/oap_test fsm/fsm_test write_queue/wqueue_test socket/socket_test coding/coding_test conv/conv_gsm0503_test abis/abis_test endian/endian_test sercomm/sercomm_test make[1]: Entering directory '/home/craig/libosmocore/tests' CC timer/timer_test.o In file included from timer/timer_test.c:31:0: ../include/osmocom/core/talloc.h:4:20: fatal error: talloc.h: No such file or directory #include <talloc.h> ^ compilation terminated. Makefile:1336: recipe for target 'timer/timer_test.o' failed make[1]: *** [timer/timer_test.o] Error 1 make[1]: Leaving directory '/home/craig/libosmocore/tests' Makefile:1529: recipe for target 'check-am' failed make: *** [check-am] Error 2

8 years, 1 month

dependency artifacts for faster builds/gerrit-verifications

by André Boddenberg

Hi all, here's a (late) recap on the "dependency-artifacts" topic discussed with Holger and Neels at OsmoDevCon. The "mv $artifact"-issue, which occurs when run within a docker container has been resolved. Now artifacts are created inside a temporary directory within the ARTIFACT_STORE and not inside the Docker container, so the "mv" command won't take as long as a "cp" anymore. Moreover, artifacts are now stored per jenkins job and not per git project. A JOB_NAME-directory inside the ARTIFACT_STORE is created for each jenkins job to distinguish between them. This means artifacts aren't shared across jobs which build the same git project. This might change in the future, but is safe for now as some jenkins jobs might need dependencies built with different configurations. Note: the necessary disk space for openBSC artifacts of one matrix-configuration job is ~400 MB (~50 MB per axis). Furthermore, each jenkins job takes care about garbage collection on its own by simply deleting the entire content of its JOB_NAME-directory inside the ARTIFACT_STORE. The two scripts osmo-{build,artifacts}.sh have been tested [1][2], shellcheck'ed and pushed to gerrit [3]. The following actions are pending to enable the use of artifacts inside contrib/jenkins.sh within each git repository, but can not be applied by me: - setting ARTIFACT_STORE environment variable for each jenkins slave - copying osmo-artifact.sh and osmo-build.sh to ~/bin of each slave user - adding a new docker volume for the ARTIFACT_STORE to the image But, let's review first. =) Cheers, André [1] https://jenkins.blobb.me/job/openBSC_multi-configuration_withArtifacts_test… [2] https://jenkins.blobb.me/job/openBSC_multi-configuration_withArtifacts_test… [3] https://gerrit.osmocom.org/#/c/2465/

8 years, 1 month

A over IP / osmo-gsm-tester / aoip branch

by Neels Hofmeyr

Since our A-interface efforts are slowly shaping out, I am adding a build of OsmoMSC that is capable of A over IP to our osmo-gsm-tester setup. For that purpose, I created the branch 'aoip' by glorifying my branch that combines pmaier's AoIP branches (for OsmoBSC and for OsmoMSC) to be the one that osmo-gsm-tester will build the AoIP binaries from. This will converge with vlr_3G and ultimately will become the new master branch(es) of our planned new osmo-bsc and osmo-msc git repositories. Overview of current "root level" branches: master: active 2G development vlr_2G: OsmoNITB capable of external HLR and UMTS authentication vlr_3G: OsmoMSC that can do 3G with an hNodeB, but no 2G aoip: OsmoMSC that has 3G disabled but can do 2G over A-interface with a separate OsmoBSC. The reason why 3G is disabled there is the early code state; vlr_3G and aoip will soon become identical. ~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, 1 month

TTCN-3 / Eclipse Titan for SIGTRAN testing

by Harald Welte

Hi all, some of you have heard me talk about my first steps in TTCN-3 and Eclipse Titan for testing of libosmo-sccp SIGTRAN code. Ericsson has thankfully agreed to release their M3UA and SCCP code (called "protocol emulation"). I received an advance copy to get started. Now, they have officially released it at: git://git.eclipse.org/gitroot/titan/titan.ProtocolEmulations.SCCP.git git://git.eclipse.org/gitroot/titan/titan.ProtocolEmulations.M3UA.git git://git.eclipse.org/gitroot/titan/titan.TestPorts.MTP3.git Using my earlier version of that code, I was able to craft some test cases for connectionless and connection-oriented SCCP (as shown on OsmoDevCon). I will now need to port that code onto the officially released git repositories above, and after that I'll of course release that on osmocom.org. 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)

8 years, 1 month

Welcome Message Upon first Connect / Trigger to External Server for LUR

by Ron

Hi All, Is there the an equivalent configuration from OpenBTS’ Control.LUR.!OpenRegistration.Message in OSMO? This is the welcome SMS to the devices when they attached to an open registration network. What we are trying to do is replicate most of the features from OpenBTS and migrate it to OSMO. Another feature we are looking for is a trigger to an external server for every LUR of devices. Best Regard, Ron Menez ron.menez(a)entropysolution.com<mailto:ron.menez@entropysolution.com>

8 years, 1 month

Problems with latest 3G software

by Andreas Mueller

Hello, I had success running an 3G network with the nano3G femtocell and osmocom-software a month ago, but I did not follow the changes which happend during the last 4 weeks. With the latest version of the software from git I am not able to register any phone on the network! The test result of 3 different phones: * iPhone: Can see the 3G network, but cannot join * Samsung S5 duos: Not seeing the network, when searching for providers * Acer Liqid M330: Not able to join the network I did not test the iPhone and S5 on the previous version of the network, but the Acer was running perfectly with it. What I did: * checked out the latest source-code and compiled it with the script osmocom.org/attachments/download/2670/clone_and_build_osmocom_3g.sh after completely removing the old source code [I had to change the script to use "sudo make install", because /usr/local/ is not writable for users on my system] => When I checked the created directories I realized, that "/usr/local/include/openbsc " has a trailing space! * I verifyed, that all needed dependencies mentioned in clone_and_build_osmocom_3g.sh are installed (running debian8 32bit) * verifyed that the initial config of the nano3G [according to http://osmocom.org/projects/cellular-infrastructure/wiki/Configuring_the_ip…] is present * I checked my config-files ggsn.conf, osmo-hlr.cfg, osmo-msc.cfg, mgcp.cfg, osmo-hnbgw.cfg, osmo-sgsn.cfg against those provided by osmocom.org/attachments/download/2669/3G-config-example.tar, but they only differ in ip-addresses and ip-networks due to my local network configuration. * I created a new hlr.db with sqlite3 hlr.db < src/osmo-hlr/sql/hlr.sql sqlite3 hlr.db < own_hlr.sql echo "update auc_3g set sqn = 32 where sqn < 32;" | sqlite3 hlr.db with own_hlr.sql containing the IMSIs and auth-data of the used USIM-cards like: INSERT INTO "subscriber" (id, imsi, msisdn) VALUES(1,'901700000014910','1111'); INSERT INTO "auc_3g" VALUES(1,5,'xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx','yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy',NULL,32,5); When running the network and trying to join with different smartphones: => in sgsn.log I can see messages like: ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:699 SUBSCR(901700000014913) Received GSUP message OSMO_GSUP_MSGT_SEND_AUTH_INFO_ERROR ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:455 SUBSCR(901700000014913) Send authentication info has failed with cause 2, handled as: Permission denied ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:463 SUBSCR(901700000014913) GPRS send auth info req failed, access denied, GMM cause = 'IMSI unknown in HLR' (2) ESC[0;m20170514014440104 DGPRS <000f> gprs_subscriber.c:813 SUBSCR(901700000014913) Updating subscriber authentication info => when looking at the RANAP-packages captured from eth0 I can see also "GSM A-I/F DTAP - Attach Reject" "GMM Cause: IMSI unknown in HLR" * I checked, that the IMSIs and auth-data is present in hlr.db => I observed that for one subscriber (the Acer Phone, which was connected to the network with a previous version of the software) the sqn number in auc_3g Table is increased, where the value of other subscribers is still 32 (=initial value) => in hnbgw.log I can only see the IMSI of the acer-phone, but not of the two other phones. So it looks like phones who had joined the network before are seen there, but phones which IMSIs are new to the network do not show up there ESC[0;m20170514014439016 DHNBAP <0001> hnbgw_hnbap.c:436 UE-REGISTER-REQ ID_type=1 imsi=901700000014913 cause=1 ESC[0;m20170514014439016 DHNBAP <0001> hnbgw.c:176 created UE context: id 0x17, imsi 901700000014913, tmsi 0x0 => in hlr.log I can also only the the IMSI of the Acer phone (keys changed) when 5 vectors are created: ESC[0;mESC[1;33m20170514014439573 DAUC <0003> db_auc.c:132 901700000014913: No 2G Auth Data ESC[0;mESC[1;33m20170514014439573 DAUC <0003> db_auc.c:213 901700000014913: Calling to generate 5 vectors ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:94 Computing 5 auth vectors: 3G only (2G derived from 3G keys) ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:96 3G: k = kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:99 3G: OP = oooooooooooooooooooooooooooooooo ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:101 3G: for sqn ind 0, previous sqn was 32 ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:113 vector [0]: rand = rrrrrrrrrrrrrrrrrrrrrrrrrrrrrrrr ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:137 vector [0]: sqn = 64 ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:139 vector [0]: autn = aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:140 vector [0]: ck = cccccccccccccccccccccccccccccccc ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:141 vector [0]: ik = iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:142 vector [0]: res = 22222222222222222222222222222222 ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:143 vector [0]: res_len = 8 ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:147 vector [0]: kc = kckckckckckckck ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:148 vector [0]: sres = resrestes ESC[0;mESC[1;33m20170514014439573 DAUC <0003> auc.c:149 vector [0]: auth_types = 0x3 .... I am running the network as non-privileged user (only ggsn with sudo), but this user can write hlr.db. Does this user also need to have write-access to files under /usr/local ? As it looks to me that there is a problem with new USIMs, which have never joined the network: Do the USIMs need special preparation for joining the network? (the USIMs are bought from the sysmocom-shop) has anybody have the same problems or can give me a hint, where to look for an error? Thanks! greetings, Andreas

8 years, 1 month

Assigning issues to "Osmocom Developers"

by Harald Welte

Dear all, I've seen dozens of tickets in recent weeks being assigned to the group "Osmocom Developers". That group is a really large group of redmine users, quite a number of which don't even work on the GSM/cellular protocol part. Assigning issues to that group has the result that they will show up in *every group members* "My issues" / "My page". And as those issues are not relevant to most people, they will increase the noise ration of important information in that default view. So please think twice before you decide to assign an issue to that group. It should only be done if you think the issue actually deserves such a wide audience. If you don't yet know who will handle a ticket, simply have no assignee. Also, we (at least Holger, Sylvain, Neels and I) can easily create more groups for more specific teams, e.g. an "osmo-gsm-tester developers" group or the like. Thanks for your attention. -- - 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)

8 years, 1 month

SMS to SIP-Message Support

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, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC