OpenBSC May 2017

openbsc@lists.osmocom.org

26 participants
59 discussions

TTCN-3 / Eclipse Titan for SIGTRAN testing
by Harald Welte 16 May '17

16 May '17

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)

1 0

Welcome Message Upon first Connect / Trigger to External Server for LUR
by Ron 16 May '17

16 May '17

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>

4 6

Problems with latest 3G software
by Andreas Mueller 15 May '17

15 May '17

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

2 2

Assigning issues to "Osmocom Developers"
by Harald Welte 15 May '17

15 May '17

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)

3 2

SMS to SIP-Message Support
by Ron 15 May '17

15 May '17

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

2 2

[osmo-iuh UNKNOWN] testsuite: 1 2 3 failed
by Mo Saman 14 May '17

14 May '17

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

2 1

Filename for HLR sqlite3 Database in 3G network?
by Andreas Mueller 13 May '17

13 May '17

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

2 2

osmo-nitb | subscriber-create-on-demand random
by Ron 12 May '17

12 May '17

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

2 1

Question about multiplexed GSM signal
by Marcus Dias 11 May '17

11 May '17

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

3 3

Re: libosmocore[master]: doc: fix incorrect return value description
by Neels Hofmeyr 11 May '17

11 May '17

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

2 2

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC May 2017