OpenBSC January 2015

openbsc@lists.osmocom.org

5 participants
9 discussions

[PATCH 0/4] core/conv: Fast Viterbi decoding

by Thomas Tsou

Hi all, This patch set adds to libosmocore an optimized Viterbi decodeer for architecture specific (Intel SSE) and non-specific cases. The implementation covers codes with constraint lengths of K=5 and K=7 and rates 1/4 to 3/4, which make up the majority of GSM use cases. Speedup from the current implementation is in the range of 5 to 20 depending on the processor and code type. API is unchanged. Tested on Haswell (i7-4770K) and Atom (D2550). Additional test codes from osmo-bts are included. Further tests for AWGN bit-error-rate and benchmarks can be found in the following repository. https://github.com/ttsou/osmo-conv-test Here are some examples. Bit error test for GPRS CS2 with SNR of 5 dB and 100000 bursts. $ ./conv_test -c 2 -e -r 5 -i 100000 ================================================= [+] Testing: GPRS CS2 [.] Specs: (N=2, K=5, non-recursive, flushed, not punctured) [.] Input length : ret = 290 exp = 290 -> OK [.] Output length : ret = 588 exp = 588 -> OK [.] BER tests: [..] Testing base: [..] Input BER.......................... 0.042443 [..] Output BER......................... 0.000006 [..] Output FER......................... 0.001350 (135) [..] Testing SIMD: [..] Input BER.......................... 0.042460 [..] Output BER......................... 0.000005 [..] Output FER......................... 0.001240 (124) Timed AFS benchmark with 8 threads and 100000 bursts per thread. $ ./conv_test -b -c 10 -j 8 -i 100000 ================================================= [+] Testing: GSM TCH/AFS 6.7 [.] Specs: (N=4, K=5, recursive, flushed, punctured) [.] Input length : ret = 140 exp = 140 -> OK [.] Output length : ret = 448 exp = 448 -> OK [.] Performance benchmark: [..] Encoding / Decoding 800000 bursts on 8 thread(s): [..] Testing base: [..] Elapsed time....................... 4.320001 secs [..] Rate............................... 25.925920 Mbps [..] Testing SIMD: [..] Elapsed time....................... 0.458272 secs [..] Rate............................... 244.396341 Mbps [..] Speedup............................ 9.426718 -TT

7 years, 12 months

[PATCH] Use generic auth API

by Max

Signed-off-by: Max <max.suraev(a)fairwaves.co> --- openbsc/src/libmsc/auth.c | 69 +++++++++++++++++++---------------------------- 1 file changed, 28 insertions(+), 41 deletions(-) diff --git a/openbsc/src/libmsc/auth.c b/openbsc/src/libmsc/auth.c index 10d8edf..d04b2fc 100644 --- a/openbsc/src/libmsc/auth.c +++ b/openbsc/src/libmsc/auth.c @@ -24,47 +24,11 @@ #include <openbsc/debug.h> #include <openbsc/auth.h> #include <openbsc/gsm_data.h> - -#include <osmocom/gsm/comp128.h> +#include <osmocom/crypt/auth.h> #include <stdlib.h> -static int -_use_xor(struct gsm_auth_info *ainfo, struct gsm_auth_tuple *atuple) -{ - int i, l = ainfo->a3a8_ki_len; - - if ((l > A38_XOR_MAX_KEY_LEN) || (l < A38_XOR_MIN_KEY_LEN)) { - LOGP(DMM, LOGL_ERROR, "Invalid XOR key (len=%d) %s\n", - ainfo->a3a8_ki_len, - osmo_hexdump(ainfo->a3a8_ki, ainfo->a3a8_ki_len)); - return -1; - } - - for (i=0; i<4; i++) - atuple->sres[i] = atuple->rand[i] ^ ainfo->a3a8_ki[i]; - for (i=4; i<12; i++) - atuple->kc[i-4] = atuple->rand[i] ^ ainfo->a3a8_ki[i]; - - return 0; -} - -static int -_use_comp128_v1(struct gsm_auth_info *ainfo, struct gsm_auth_tuple *atuple) -{ - if (ainfo->a3a8_ki_len != A38_COMP128_KEY_LEN) { - LOGP(DMM, LOGL_ERROR, "Invalid COMP128v1 key (len=%d) %s\n", - ainfo->a3a8_ki_len, - osmo_hexdump(ainfo->a3a8_ki, ainfo->a3a8_ki_len)); - return -1; - } - - comp128(ainfo->a3a8_ki, atuple->rand, atuple->sres, atuple->kc); - - return 0; -} - /* Return values * -1 -> Internal error * 0 -> Not available @@ -76,6 +40,11 @@ int auth_get_tuple_for_subscr(struct gsm_auth_tuple *atuple, { struct gsm_auth_info ainfo; int i, rc; + static struct osmo_sub_auth_data auth = { + .type = OSMO_AUTH_TYPE_GSM + }; + struct osmo_auth_vector _vec; + struct osmo_auth_vector *vec = &_vec; /* Get subscriber info (if any) */ rc = db_get_authinfo_for_subscr(&ainfo, subscr); @@ -109,13 +78,23 @@ int auth_get_tuple_for_subscr(struct gsm_auth_tuple *atuple, return 0; case AUTH_ALGO_XOR: - if (_use_xor(&ainfo, atuple)) - return 0; + auth.algo = OSMO_AUTH_ALG_XOR; + if ((ainfo.a3a8_ki_len > A38_XOR_MAX_KEY_LEN) || (ainfo.a3a8_ki_len < A38_XOR_MIN_KEY_LEN)) { + LOGP(DMM, LOGL_ERROR, "Invalid XOR key (len=%d) %s\n", + ainfo.a3a8_ki_len, + osmo_hexdump(ainfo.a3a8_ki, ainfo.a3a8_ki_len)); + return -1; + } break; case AUTH_ALGO_COMP128v1: - if (_use_comp128_v1(&ainfo, atuple)) - return 0; + auth.algo = OSMO_AUTH_ALG_COMP128v1; + if (ainfo.a3a8_ki_len != A38_COMP128_KEY_LEN) { + LOGP(DMM, LOGL_ERROR, "Invalid COMP128v1 key (len=%d) %s\n", + ainfo.a3a8_ki_len, + osmo_hexdump(ainfo.a3a8_ki, ainfo.a3a8_ki_len)); + return -1; + } break; default: @@ -124,6 +103,14 @@ int auth_get_tuple_for_subscr(struct gsm_auth_tuple *atuple, return 0; } + memcpy(auth.u.gsm.ki, ainfo.a3a8_ki, sizeof(auth.u.gsm.ki)); + + if (osmo_auth_gen_vec(vec, &auth, atuple->rand) < 0) + return -1; + + memcpy(atuple->sres, vec->sres, 4); + memcpy(atuple->kc, vec->kc, 8); + db_sync_lastauthtuple_for_subscr(atuple, subscr); DEBUGP(DMM, "Need to do authentication and ciphering\n"); -- 1.9.1

8 years, 10 months

recurring issue with OpenBSC

by Ciaby

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi! First a small update: we finally decided to _not_ use token mode, as it confuses a lot of phones, after receiving the token message the SIM goes into an error state and the only way to recover is to reboot the phone. Now we just read the IMSI straight from the SIM (using the card python library, just like osmo-sim-auth does) and register them. Now, the issue we see is that 1-2 users every day reach a point where they can make phone calls and send messages, but they can't receive neither of them. Sometimes the problem can be fixed by running: > subscriber extension <EXT> clear-requests but this only work when there are pending requests. In other cases, the phone has to be rebooted. Did anyone encounter the same issue? Cheers Ciaby -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJUef1WAAoJEPU83OtbD4fQ69kQAI7peg30lHwbDPMXnTX80gUu 0dGsiK2iB5oWZ6Ohbs3W+/+xVoMseuG1di6Rk0XT9buN2IOR5fMfAs3INQ2EuAlV qz1RRn5Ux8uV0RJWyAJoSt7eFh3gbnDgsJ+x8SXEHQRw4rYHG2P+HXyEtncW6A6y L8/oPeIxH/LlP/55MP3KUY5BnQmN658LnJU9AFSwPkpjn2f/dj4o6mUdWo8haTTQ UWPWEdhQoeXPBqHsn2cKamT13SmiepMYAGuDEJci9LCS+J8vd70ukAP/oa1L6u1w +3+RbcNvC9fwAKDLU01b/cu630v6/mhk0lxWNlIz/kNL1aHPZe8QhP5sM4SuLtzj UaeHLxp4u2Pb7N31b3qtRA4jgl+5YFla5376F3d00jPSfZpmFggFgdRB2qWhF1m8 WucfzLc41dV1AVTdL90ISSRt1LZ/fLHBea8kgUxK+KrhBO7U7AV3PXk9of4EAf7y VKMX3KZWwtEKhpi0v3PihgW8bS/RaG3zEmsr30QXzXVaZknCfjGi8OOOB0JaHY48 o3g40YpzeyEq1gOyKKfBmtf1qk4GgLyPKfMUoTvXE2oNHmrg3ZlJldABKNzR9qz3 5hsHJ6/QGsBST1E3dphI0Zb6ubLnFwqBl02GyeJELLbtPCLPQMDicx03cqT4BjO3 vzDcPdIWg1sfSomYKMK9 =Zw4T -----END PGP SIGNATURE-----

9 years

Final review of L1SAP ported to current maste

by Harald Welte

Dear all, the valuable L1SAP abstraction has been sitting out of master for too long time. It is a pity that this has taken so long. I've finally been able to put some time into osmo-bts again and reviewed the following patch series. It consists of mostly Andreas' work, interspersed with smaller patches/fixups that I introduced after the respective original patch from Andreas. I have started a sysmobts between all of the major steps in this patch series and did a short manual tests involving registration (LU) of two MS, mobile-to-mobile call and vty-to-mobile SMS. So far I couldn't see any problems. What has not been tested yet is the PCU interface as well as encryption support. I plan to do this later this week. I intend to merge the code after this current review cycle. Please take your time to have a look and provide feedback (if any), so we can get this over and work on new features again, rather than infrastrutural changes. I didn't yet rebase the osmo-bts-trx interface on top of the L1SAP, as I don't have a hardware setup for it, and I will leave it to the owners of such hardware to publish/push the respective code after L1SAP is merged. 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)

9 years

openbsc Crypto

by ramesh shankar

Hello Its says in OpenBSC_crypto that "The keys will be stored in the table AuthKeys? of the hlr databse". I don't see that, is there any setting to get that. I am using sqlitebrowser to open HLR regards Ramesh

9 years, 2 months

Osmo-trx and USRP1

by Benedetta Piantella Simeonidis

All mighty list, I am stuck and hope you can help. I know the USRP1 is no longer supported (and so libusrp), but the USRP1 is the only thing I have access to at the moment. I have gotten Osmo NITB working with the USRP1 previously, but this new install seems to be stuck between a rock and a hard place. I am running Ubuntu 12.04 and I have gnuradio-3.4.2 installed (for libusrp) and I followed the directions here: http://openbsc.osmocom.org/trac/wiki/network_from_scratch and http://openbsc.osmocom.org/trac/wiki/OsmoTRX Running OpenBSC and OsmoBTS seems to be working fine. Issuing uhd_usrp_probe works and returns the details of the USRP1 with two daughtercards and I have the USRP1 connected to clocktamer and properly clocked at 52MHz. All the hardware modifications have been done on the USRP1. The issues are: Problem 1: When running osmo-trx this is what happens: ~$ sudo osmo-trx linux; GNU C++ version 4.6.3; Boost_104601; UHD_003.008.000-release Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 1 Samples-per-Symbol...... 4 External Reference...... Disabled C0 Filler Table......... Disabled Diversity............... Disabled Tuning offset........... 0 -- Opening a USRP1 device... -- Using FPGA clock rate of 52.000000MHz... ALERT 3044955904 03:14:40.8 UHDDevice.cpp:607:parse_dev_type: USRP1 is not supported using the UHD driver ALERT 3044955904 03:14:40.8 UHDDevice.cpp:608:parse_dev_type: Please compile with GNU Radio libusrp support ALERT 3044955904 03:14:40.8 osmo-trx.cpp:380:main: Failed to create radio device Shutting down transceiver... Problem 2: When I try and configure osmo-trx using ./configure --with-usrp1, it configures and then at the make process this is what happens: ... CXX USRPDevice.lo USRPDevice.cpp:603:14: error: prototype for 'RadioDevice* RadioDevice::make(size_t, size_t, bool)' does not match any in class 'RadioDevice' radioDevice.h:40:23: error: candidate is: static RadioDevice* RadioDevice::make(size_t, size_t, bool, double) make[3]: *** [USRPDevice.lo] Error 1 make[3]: Leaving directory `/home/cosmo/osmo-trx/Transceiver52M' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/cosmo/osmo-trx/Transceiver52M' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/cosmo/osmo-trx' make: *** [all] Error 2 Could this have anything to do with permissions or where all my files are located? I am wondering if anyone has had the same issues and has some insight on what I am doing wrong or missing. Any help will be super appreciated, Thanks a lot! Benny -- Benedetta Piantella Simeonidis Phone US: +1.347.495.1237 Phone EU: +39.3397921313

9 years, 3 months

meas_feed fails to compile if libcdk5-dev is not installed

by Jacob Erlbeck

Hi Harald, OpenBSC fails to compile because meas_feed unconditionally depends on cdk.h. If this file is not available, configure just issues checking cdk/cdk.h usability... no checking cdk/cdk.h presence... no checking for cdk/cdk.h... no but does not fail. On the other hand, the meas_tool's Makefile does not check for the result of that check before starting the compilation. So IMO either the configure script should abort (and the package added to debian/control) or the compilation of meas_feed should be optional. Jacob -- - Jacob Erlbeck <jerlbeck(a)sysmocom.de> http://www.sysmocom.de/ ======================================================================= * sysmocom - systems for mobile communications GmbH * Schivelbeiner Str. 5 * 10439 Berlin, Germany * Sitz / Registered office: Berlin, HRB 134158 B * Geschaeftsfuehrer / Managing Directors: Holger Freyther, Harald Welte

9 years, 3 months

libosmocore sylvain/security branch

by Harald Welte

Hi Sylvain, I was doingwwwww libosmocore 'branch hygiene' and was wondering what's the status of that branch? I would like to see XOR support and randomized padding support included. Is it ready for merge? It is clear that of course osmo-bts / osmocom-bb would subsequently need to be modified to use randomized padding... 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)

9 years, 3 months

libosmocore daniel/scts-fixes branch

by Harald Welte

Hi Daniel, I was doing some libosmocore 'branch hygiene' and removed several of your branches that had already been merged. However, there's the scts-fixes branch. Can you please let me know about the status of the branch? Does it still need testing? Is it ready for merge? 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)

9 years, 3 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2015