- OpenBSC - lists.osmocom.org

[PATCH] msc: Add channel information to the meas_feed, bump version to v1
by Alexander Chemeris 14 Sep '15

14 Sep '15

Hi all, Attached is a patch for the openbsc which extends meas_feed with channel information - type and id (bts/trx/ts/ss). This is used by the web incarnation of meas_vis utility we wrote [1]. Originally it was a pure copy of the original meas_vis, but when we deployed it at Rhizomatica, they suggested it would be more useful if the channel information is displayed. It would be great to see this patch merged to master. When/if this is merged, I'll submit a patch with meas_json utility which listens on the meas_feed socket and converts it to JSON format digestible by web tools. This JSON is what meas_web uses as a data feed. [1] https://github.com/fairwaves/meas_web PS Apologies for attaching the patch instead of inlining it. GMail would ruin it. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co

3 4

[PATCH] build: have a disable-static build succeed
by Jan Engelhardt 11 Sep '15

11 Sep '15

When using configure --disable-static, no libosmogsm.a will be created, and the tests fail to link because symbols like _a5_3 and _a5_4 are not exported through the only remaining libosmogsm.so. A method to overcome this is an intermediate private non-distributed library, examples of which are present in e.g. libabc, kmod and systemd. With this, disable-static can now be the default and practical compile time be halved. --- This is for libosmocore.git. configure.ac | 2 +- src/gsm/Makefile.am | 8 ++++++-- tests/Makefile.am | 6 ++---- 3 files changed, 9 insertions(+), 7 deletions(-) diff --git a/configure.ac b/configure.ac index c492277..9a744b1 100644 --- a/configure.ac +++ b/configure.ac @@ -13,7 +13,7 @@ AC_PROG_MAKE_SET AC_PROG_MKDIR_P AC_PROG_CC AC_PROG_INSTALL -LT_INIT([pic-only]) +LT_INIT([pic-only disable-static]) AC_CONFIG_MACRO_DIR([m4]) diff --git a/src/gsm/Makefile.am b/src/gsm/Makefile.am index d8aff4a..1878050 100644 --- a/src/gsm/Makefile.am +++ b/src/gsm/Makefile.am @@ -10,9 +10,10 @@ noinst_HEADERS = milenage/aes.h milenage/aes_i.h milenage/aes_wrap.h \ milenage/common.h milenage/crypto.h milenage/includes.h \ milenage/milenage.h +noinst_LTLIBRARIES = libgsmint.la lib_LTLIBRARIES = libosmogsm.la -libosmogsm_la_SOURCES = a5.c rxlev_stat.c tlv_parser.c comp128.c comp128v23.c \ +libgsmint_la_SOURCES = a5.c rxlev_stat.c tlv_parser.c comp128.c comp128v23.c \ gsm_utils.c rsl.c gsm48.c gsm48_ie.c gsm0808.c sysinfo.c \ gprs_cipher_core.c gsm0480.c abis_nm.c gsm0502.c \ gsm0411_utils.c gsm0411_smc.c gsm0411_smr.c \ @@ -21,8 +22,11 @@ libosmogsm_la_SOURCES = a5.c rxlev_stat.c tlv_parser.c comp128.c comp128v23.c \ auth_milenage.c milenage/aes-encblock.c \ milenage/aes-internal.c milenage/aes-internal-enc.c \ milenage/milenage.c gan.c ipa.c gsm0341.c apn.c +libgsmint_la_LDFLAGS = -no-undefined +libgsmint_la_LIBADD = ../libosmocore.la +libosmogsm_la_SOURCES = libosmogsm_la_LDFLAGS = $(LTLDFLAGS_OSMOGSM) -version-info $(LIBVERSION) -no-undefined -libosmogsm_la_LIBADD = $(top_builddir)/src/libosmocore.la +libosmogsm_la_LIBADD = libgsmint.la EXTRA_DIST = libosmogsm.map diff --git a/tests/Makefile.am b/tests/Makefile.am index 8e31f66..cf0977d 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -19,12 +19,10 @@ utils_utils_test_SOURCES = utils/utils_test.c utils_utils_test_LDADD = $(top_builddir)/src/libosmocore.la $(top_builddir)/src/gsm/libosmogsm.la a5_a5_test_SOURCES = a5/a5_test.c -a5_a5_test_LDADD = $(top_builddir)/src/libosmocore.la $(top_builddir)/src/gsm/libosmogsm.la -a5_a5_test_LDFLAGS = -static +a5_a5_test_LDADD = $(top_builddir)/src/libosmocore.la $(top_builddir)/src/gsm/libgsmint.la kasumi_kasumi_test_SOURCES = kasumi/kasumi_test.c -kasumi_kasumi_test_LDADD = $(top_builddir)/src/libosmocore.la $(top_builddir)/src/gsm/libosmogsm.la -kasumi_kasumi_test_LDFLAGS = -static +kasumi_kasumi_test_LDADD = $(top_builddir)/src/libosmocore.la $(top_builddir)/src/gsm/libgsmint.la comp128_comp128_test_SOURCES = comp128/comp128_test.c comp128_comp128_test_LDADD = $(top_builddir)/src/libosmocore.la $(top_builddir)/src/gsm/libosmogsm.la -- 2.4.3

1 0

Osmocom Berlin User Group revival?
by Harald Welte 07 Sep '15

07 Sep '15

Dear all, After two years of intermission, I'm currently pondering to revive the Osmocom Berlin User Group and would like to understand a) who would be interested in attending? b) which day(s) of the week would be preferred / not preferred? Instad of "just" hanging out, chatting about Osmocom related topics etc. I am interested in having actual topics for each of the meetings. There is no need for a formal presentation or anything like that, but at least let's try to stay focussed on the topic for the first hour or so, and then conclude with a more general chat towards the end. Some of the topics that I would like to start with ASAP: * sharing of knowledge regarding 3G and 4G protocol stacks (I'm looking a lot at this recently, and it is a good time to talk about what I've learned) * completing the work towards splitting osmo-nitb into osmo-bsc and osmo-mss - as a first stept towards adding RANAP/Iu to osmo-mss * attempting to decode/analyze BVG bus/tram radio (TETRAPOL) using tetrapol-kit from http://brmlab.cz/git/tetrapol-kit.git * are berlin S-Bahn trains actually still broadcasting their GPS position in MPT1327? * moving ahead with AT91SAM3S based SIMtrace2 with MITM support Let me know who is interested in joining. In terms of venue I would suggest to again use the CCCB, unless somebody objects. We could of course also ask our friends at IN-Berlin or C-Base. In terms of schedule, I would actually want to go for bi-weekly again. Happy hacking, 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)

3 3

[Help needed] Testing OpenBSC without hardware BTS
by Kornschnok 03 Sep '15

03 Sep '15

Hello, I just started on OpenBSC. I would really like to test it without a hardware BTS. I'm aware that there's a smalltalk "FakeBTS" program for testing it but I did not manage to run it due to a runtime problem with libgnu-smalltalk version 3.2.91 which was listed as a requirement to run FakeBTS. As lower stable version of libgnu-smalltalk wouldn't work there's nothing I could do. I include the error message below just in case. ------------------- openbts@ubuntuopenbts:~$ gst "Global garbage collection... done" "Global garbage collection... done" /usr/share/gnu-smalltalk/kernel/SysDict.st:37: Aborted /usr/share/gnu-smalltalk/kernel/SysDict.st:37: Error occurred while not in byte code interpreter!! /usr/lib/libgst.so.7 (+0x67cef) [0xb7748cef] [0xb77af400] [0xb77af424] ... Aborted -------------------- Anyway, what I want to achieve as a start is to emulate some phone calls and trace how calls are routed through the different entities. (It's for demonstration purpose and personal interest) Would that be possible with maybe some coding? I would appreciate any suggestion on how to start. Thanks in advance! Kornschnok

1 0

[PATCH] openbsc: unhardwire MGCP endpoint id
by Mike McTernan (wavemobile) 01 Sep '15

01 Sep '15

Hi Folks, At present endpoint IDs are assumed to end with @mgw when trying to find/match non-e1 endpoint ids. Unless the MGCP peer supports compatible configuration, DNS or a hosts file may need to be setup to meet the hardwired host name requirement in the openBsc MGCP, and then we can still only run one BSC. The attached patch makes a simple change to use either the configured local_ip or source_addr, matching logic used in SDP responses. It also improves the error message when an endpoint can't be found. Please consider for inclusion to mainline. Kind Regards, Mike

2 4

dvnixload error: Entry point not found
by Diego Fernandez Alonso 24 Aug '15

24 Aug '15

Hello. I have a problem with my sysmoBTS. When I start the bts I receive a BOOTME message. So after identify in the SysmoBTS Manual the problem like broken UBL, I tried to follow the manual using the dvnixload utility. I installed the binutils-multiarch package and others neccesary for the execution of the divnixload, but during the proccess I get an error: root@ubun-osmo:/home/osmo-user/Documentos# ./dvnixload -p /dev/ttyUSB0 ubl-sysmobts-v2.elf u-boot-sysmobts-v2.elf dvnixload info: Using cross compiler "" dvnixload info: Expecting messages: [BOOTME] [BOOTPSP] [I_ME] dvnixload info: [BOOTME] received dvnixload error: Entry point not found dvnixload error: Entry point not found Do someone know why I get an "Entry point not found" message and how I can fix it? Thank you so much!!

2 5

8-PSK modulation/demodulation
by Piotr Krysik 20 Aug '15

20 Aug '15

Hi all, I'm developing gr-gsm - the ancestor of Airprobe's gsm-receiver. I want to add support for 8-PSK reception. I'm going to implement a demodulator (preferably doing also channel equalization) and also modulator (currently mostly to generate test data). I don't want to duplicate work that was already done so I want to ask if you are aware of any publicly available 8-PSK implementations (or partial implementations) aimed at supporting EDGE reception? Also I will greatly appreciate pointing to any documents containing good information on this topic. -- Best Regards, Piotr Krysik

2 1

subdir-objects / autoconf
by Harald Welte 19 Aug '15

19 Aug '15

Hi Holger, I added libosmocore commit 7c942ba1475a366cc7c8a129fbdd335166ce21c6 during the camp as at the simtrace/osmocombb/openbsc workshop, several participants could not build the respective software packages. This behavior was observed by Kevin and me, and adding subdir-objects resolved the problem. Due to the hectic nature of a workshop where everyone is waiting for the build to succeed on the system of all participants we did not have time to record the specific distribution versions at that time. On Debian unstable with autoconf 2.50 / automake 1.15, the build generates the following warnings: =============== src/gsm/Makefile.am:15: warning: source file 'milenage/aes-encblock.c' is in a subdirectory, src/gsm/Makefile.am:15: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. =============== The project still builds afterwards on this Debian system, so indeed it is just a warning. However, the warning quite clearly indicates that the use of subdir-objects is not optional in the future! So I'm not sure your revert of the assciated commit is the right way to proceed. The point seems to be that 'make distclean' wants to remove the generated objects for the tests, but the latter only are compiled when 'make check' is used, but not in the default build. Any ideas? -- - 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 4

[PATCH libosmo-netif 00/18] add dummy padding support
by pablo＠gnumonks.org 19 Aug '15

19 Aug '15

From: Pablo Neira Ayuso <pablo(a)netfilter.org> The following patchset, although it looks a bit large, it is composed of many small incremental changes to improve the existing osmux infrastructure and to add dummy padding support. The dummy padding consists of a osmux header and payload that looks like this: OSMUX seq=000 ccid=002 ft=2 ctr=3 amr_f=0 amr_q=0 amr_ft=03 amr_cmr=00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ] The frame type is OSMUX_FT_DUMMY (=2) in the batch that whose payload is padded with 0xff. Note that the message above is padding the circuit ID 2. This is used for early bandwidth preallocation in links that involve relatively slow dynamic bandwidth allocation such as Iridium/OpenPort. The osmux test infrastructure has been improved (to resolve some memleaks) and enhanced to cover this new dummy support. The OpenBSC changeset is composed of one very small patch that will come after this batch. If no major concerns, I'll push this initial batch soon into the repository. Thanks. Pablo Neira Ayuso (18): osmux: discard non voice osmux message osmux: add osmux_input_state structure osmux: add circuit helper functions osmux: rename struct batch_list_node to osmux_circuit osmux: rename circuit->list to circuit->rtp_list osmux: pass up struct osmux_batch osmux: count pending messages to be transformed in the batch osmux: introduce osmux_xfrm_input_close_circuit() osmux: introduce osmux_xfrm_input_open_circuit() tests: osmux: adapt it to use the new circuit API tests: osmux: factor out main test loop tests: osmux: test online deactivation of dummy padding tests: osmux: validate dummy padding with no voice data interaction tests: osmux: test circuit reopening after closure osmux: kill osmux_get_hdr() tests: osmux: fix msgb leaks tests: compile tests with debugging symbols, ie. -g tests: osmux: iterate 64 times in osmo_test_loop() include/osmocom/netif/osmux.h | 8 +- src/osmux.c | 374 ++++++++++++++++++++++++++--------------- tests/Makefile.am | 2 +- tests/osmux/osmux_test.c | 80 ++++++--- 4 files changed, 304 insertions(+), 160 deletions(-) -- 1.7.10.4

3 31

MNC starting with zero
by Ravi Shankar 18 Aug '15

18 Aug '15

Dear Sir As we know that mnc 01 and 1 are different for GSM. In config file even on providing MCC 001 and mnc 01 its flashes mcc as 1 and mnc as 1. How to get over from this issue and get the network as 001-01 instead of 1-1. Regards. Ravi

3 2