OpenBSC

openbsc@lists.osmocom.org

12 participants
4278 discussions

Contribute to Osmocom and receive a free 3.5G femtocell
by Harald Welte 09 Jan '17

09 Jan '17

Dear all, not everyone might have seen the news item that was posted in late December on our website at http://osmocom.org/news/62 I'm looking forward to receiving your proposal on how you would contribute to the Osmocom project if you were to receive one of those free 3.5G femtocells. Quote of the news item below: ------ So please excuse me to cross-post this over several Osmocom project mailing lists. I know that a number of people have either hacked on femtocells in the past, or at least expressed interest in doing so... Osmocom's support for 2G/GSM is mature and widespread. Since 2016, we're taking on the next level: 3G/3.5G. The key to running your own 3G network is to obtain actual 3G cell hardware -- here is an exciting opportunity to get started: No less than 50 femtocells will be given away for free by sysmocom, one of the main drivers of the Osmocom project. To receive a free 3G femtocell, tell us how you will help the Osmocom project drive 3.5G forward if you had one, before the end of January 2017. This marks the launch of the 3.5G Acceleration Project, backed by the Osmocom community. Join us! Find further details on the 3.5G Acceleration Project and receiving your own 3G femtocell for free at https://sysmocom.de/downloads/accelerate_3g5_cfp.pdf. ------ Best regards and happy hacking, Harald Welte -- - 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

Re: libosmocore[master]: libosmocoding: migrate transcoding routines from OsmoBTS
by Harald Welte 09 Jan '17

09 Jan '17

On Wed, Jan 04, 2017 at 08:55:45AM +0000, Vadim Yanitskiy wrote: > I think it's due to --enable-sanitize, because > when I am trying to compile libosmocore this way: > > ./configure --enable-static --enable-sanitize > make check > > Some other tests fail (current master version, clang-3.6): > > Regression tests. > 8: gea FAILED (testsuite.at:51) > 9: msgfile FAILED (testsuite.at:59) > 15: lapd FAILED (testsuite.at:96) > 16: gsm0808 FAILED (testsuite.at:102) > 17: gsm0408 FAILED (testsuite.at:108) > 30: bssgp-fc FAILED (testsuite.at:190) I pushed some fixes,see https://gerrit.osmocom.org/1530 and https://gerrit.osmocom.org/1531 - the remaining failures are all LeakSanitizer warnings, and I suspect that while we release all memory back to talloc, talloc itself doesn't release it back to glibc malloc/free, and hence LeakSanitizer is kicking in. A quick online search didn't seem like anyone else has yet come up with a solution for this, so I guess we should turn it off. I remember some discussion on the list about a year ago where the concensus was to disable LeakSanitizer by environment variables on the buildhost anyway? -- - 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)

4 3

log messages summary
by Neels Hofmeyr 09 Jan '17

09 Jan '17

Hi Max, you recently tend to have very general commit log summaries. The summary should best contain a hint at the general area the patch is about, so a reader can quickly know whether a patch could be related to a given other topic. I've asked so on gerrit a few times, and now also found a couple of commits merged IMHO with ETOOGENERAL, so I thought I'd drop a note: osmo-bts: 2017-01-06 17:30 Max o Log socket path on error 2017-01-02 18:17 Max o Move code to libosmocore 2016-11-11 17:44 Max o Remove duplicated code osmo-pcu: 2017-01-06 17:20 Max o Log socket path on connection 2017-01-05 18:26 Max o Improve logging Would be nice to add an indicator to the summary in the future. A small word or phrase in the beginning is enough, like 'rsl: frobnicate', or include a function name or -prefix for code dup / moved code. Thanks! ~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

1 0

[libosmocore 0.9.6.48-3419] testsuite: 28 failed
by Martin Hauke 08 Jan '17

08 Jan '17

-------------------------------------------------------------------- 28: stats FAILED (testsuite.at:177) -------------------------------------------------------------------- os: openSUSE Tumbleweed arch: armv7l compiler: gcc (SUSE Linux) 6.2.1 20161209 [gcc-6-branch revision 243481] configure options: default I have attached testsuite.log best regards, Martin

1 0

[libosmocore 0.9.6.35-3faa] testsuite: 8 9 15 16 17 30 failed
by Vadim Yanitskiy 06 Jan '17

06 Jan '17

Ubuntu 16.04.1 LTS gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.4) Configured with: --enable-static --enable-sanitize See attachment please. With best regards, Vadim Yanitskiy.

2 1

Re: libosmocore[master]: libosmocoding: migrate transcoding routines from OsmoBTS
by Neels Hofmeyr 01 Jan '17

01 Jan '17

On Sat, Dec 31, 2016 at 01:10:30PM +0000, Vadim Yanitskiy wrote: > Regarding to the change, there is a problem: despite all tests > pass without any problems on my machine, some tests fail on Jenkins. > I will try to find out, what's wrong. Let me know if I should install some library dependencies or similar on the build slaves... ~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

1 0

[XTRX] Price?
by Choukou Moun 26 Dec '16

26 Dec '16

Hello. Wath is the price of the xtrx board ? Thank you.

2 1

ki in osmo-nitb's built-in HLR db
by Neels Hofmeyr 26 Dec '16

26 Dec '16

Merry x-mas! Just now I found a curious problem with the current osmo-nitb ciphering key. I'm working on the new VLR, which will inherently fix this issue, but in the course of that I recapped the current osmo-nitb's sequence of events for 2G ciphering as it is on the openbsc master branch. It so happens that I'm using a SIM card with a fabricated Ki value of hex: 000102030405060708090a0b0c0d0e0f i.e. starting with a zero byte. I was able to store this in and retrieve from the hlr.sqlite3 db: sqlite> INSERT INTO "AuthKeys" VALUES(57,2,X'000102030405060708090A0B0C0D0E0F'); sqlite> select hex(a3a8_ki) from AuthKeys; 000102030405060708090A0B0C0D0E0F So there were 16 bytes worth of BLOB in the Ki column for sure. But in openbsc's db.c in db_get_authinfo_for_subscr(), I always got DMM <0002> ../../../src/libmsc/auth.c:70 Invalid COMP128v1 key (len=0) Curious, could it be the zero byte? Just to check, I put the zero byte further left: sqlite> select hex(a3a8_ki) from AuthKeys; hex(a3a8_ki) F00102030405060008090A0B0C0D0E ^ nonzero ^^ zero Now the log says: DMM <0002> ../../../src/libmsc/auth.c:70 Invalid COMP128v1 key (len=5) f1 f3 f4 f5 f6 That's even weirder. I was expecting a 7 byte BLOB, of f0 01 02 03 04 05 06 and not f1 f3 f4 f5 f6 ... what on earth ... It appears that we've so far always been unable to use Ki keys that contain a zero byte, or apparently anything that's outside the 7bit ascii space ... ? To be able to recap what the old osmo-nitb is doing (without going to fetch a card reader from the office and reprogram the Ki on the SIM card), I fixed this bug with this funny little hack: https://gerrit.osmocom.org/1504 Todo: are other BLOB values also affected? Is there a better way to fix? Even though the new VLR is on its way, it might be good to get a fix like this out in the meantime ... though it appears that no-one is using ciphering on 2G anyway? ~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

2 3

Debugging osmo-trx constellation on XTRX SDR
by Alexander Chemeris 25 Dec '16

25 Dec '16

Hi Thomas, We're porting osmo-trx to our XTRX and we see some weird constellation (https://goo.gl/photos/1KycUsv26Z6T6aN97). It looks like a normal GMSK circle is there, but there is also a square like if a signal is clipped. Do you have any idea what could cause this from your previous experience? We're running osmo-trx at 4 SPS. Then we double sample rate in software (XTRX can't handle sample rates below 2 MSPS yet) and then transmit. See first image above. Then we tried to increase sample rate and enabled 4x interpolation in LMS7 - that led to a distorted cicrle + square constellation (https://goo.gl/photos/zMZRecxmZsqiCYMHA). -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co

2 2

Error of skipping buffer data
by Mayuri Tendulkar 23 Dec '16

23 Dec '16

Hi Team Has anybody seen error like below while running osmo-stack on B210? What could be the reason of this failure? We are seeing this randomly. ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1039:check_rx_md_err: An internal receive buffer has filled at 31.9377 sec. ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer data: timestamp=8696668 time_end=8651398 ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer data: timestamp=8696668 time_end=8651398 ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer data: timestamp=8696668 time_end=8651398 ERR 140460077602560 20:17:18.4 UHDDevice.cpp:1576:write: Skipping buffer data: timestamp=8696668 time_end=8651398 NOTICE 140460079380224 20:17:34.0 Transceiver.cpp:306:stop: Stopping the transceiver ALERT 140460079314688 20:24:03.3 radioInterface.cpp:323:pullBuffer: Receive error 0 ERR 140460079314688 20:24:03.4 UHDDevice.cpp:1039:check_rx_md_err: An internal receive buffer has filled at 437.017 sec. Regards Mayuri

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC