OpenBSC October 2017

openbsc@lists.osmocom.org

21 participants
47 discussions

Packiging: Install config files? Examples only?

by Harald Welte

Dear Community, while working on the "osmocom:latest" builds the last few days, I noticed that some packages (notably osmo-pcu) install a config file to /etc/osmocom, while most other packages simply install some example config files to /usr/share/doc/* and don't create either /etc/osmocom nor any config files in it - despite the systemd jobs depending on it. For sure, the behavior should be unified across all Osmocom packages, but in which way? What is the best practise here? What do our users expect? Let's have a discussion here and note the conclusion in https://osmocom.org/issues/2602 before implementing it. -- - 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)

7 years, 9 months

Looking to see if I can test 3g hNodeB with HNBGW implementation on Osmo

by Dees

Hi all, Very new to Osmo. Wondering Osmo has full stack support for Iuh, if yes is there any guidance or wiki page. Kind regards,Dees

7 years, 9 months

RFC: gerrit verifcations as Jenkins Job Builder YAML file

by André Boddenberg

Hi all, I've created a prototyp'ish JJB YAML file [1] that holds all current gerrit verification jobs on jenkins.osomocom.org. Holger and Lynxis suggested to explore this way of managing Jenkins jobs in the "jenkins build slaves: Rationale for some builds in docker vs. some not?" thread. Following differences occurred, while clicking through all gerrit jobs configurations: - some jobs using gcc c compiler warnings v3, some v4 - some jobs are verifying drafts, some not - only two gerrit jobs are allowing concurrent builds Are these differences wanted? All job differences are commented in the YAML file. The jobs are deployed on jenkins.blobb.me [2]. What do you think about this approach [1] in general? Regards, André [1] https://gerrit.osmocom.org/#/c/3911/1 [2] https://jenkins.blobb.me/view/gerrit-JJB/

7 years, 9 months

RFC: Getting rid of FreeBSD build testing

by Harald Welte

Dear all, Holger and I (plus later the sysmocom team) had a discussion about whether we should continue to keep the FreeBSD build testing. Right now, jenkins is set up in a way to test build of a patch on Linux (currently Debian 8) and FreeBSD (currently 10.3). Only if it builds and passes "make check", the patch gets the magical "+V" so it can be merged. While in general it's of course good practise to write portable code and to test building on multiple operating systems, this adds quite a bit of extra effort: * patches every so often don't build on FreeBSD due to include header differences or the like, requiring extra iterations of a patch * the build takes longer time as the build matrix is multiplied by two operating systems * we cannot easily/safely migrate the way we buld to docker, as docker on FreeBSD is experimental Particularly during my recent OpenGGSN developments (IPv6) support, this was a big PITA and I'm sure I spent more time in debugging FreeBSD build issues than actually writing the code in the first place. Given that we arr not aware of anyone using the Osmocom stack on FreeBSD, the suggestion is thus to focus our available time on actual GSM related features rather than fixing up portability issues. So unless we receive significant complains as a response to this e-mail, we will disable the automatic build testing for patches on FreeBSD. This doesn't mean we will drop related code from our projects. We still appreciate build and other fixes for other platforms, but those would have to come as contributions from users on those platforms, rather than something that's actively maintained and tested by Osmocom upstream. If we want to extend build testing, I think it's more useful to have e.g. ARM/Linux builds, or clang builds on Linux than the FreeBSD builds. Let me know what you think. 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)

7 years, 9 months

Support in using slotmask

by Mayuri Tendulkar

Hi team I want to test the data on timeslot basis, where I can activate alternate timeslot oN B200. How this is possible? I tried to add parameters in bts-conf file with slotmask as 10101010. But I don't see any change. I also tried to change this value from 0xff to 0xaa in osmo-bts-trx code, but I get error. Can u please help? Regards Mayuri

7 years, 10 months

osmo-msc needs a fix of fsm names

by Neels Hofmeyr

Talking about libosmocore changes that break builds ;) By chance I noticed that since now osmo-gsm-tester tests fail for AoIP, osmo-msc bailing with fsm.c:150 Attempting to register FSM with illegal identifier 'FSM RESET' fsm.c:216 Attempting to allocate FSM instance of type 'FSM RESET' with illegal identifier 'FSM RESET INST' @pmaier, please fix osmo-msc's FSM name in a_reset.c ASAP. We can't test OsmoMSC until you do. Thanks! ~N

7 years, 10 months

libosmocore / rate_ctr / osmo_fsm / invalid identifiers

by Harald Welte

Dear Osmocom comunity, after my patches being in gerrit since October 3 without getting any significant review comments, I decided to rebase+merge the code to enforce correct "identifiers" for entnties like rate_ctr or osmo_fsm which get registered to libosmocore and which are subsequently automatically exported via CTRL. A valid identifier is from now on known as any 7-bit ASCII string excluding characters from the following set: :., {}[]()<>|~\\^`'\"?=;/+*&%$#! This has caused some (not entirely unexpected) breakage in osmo-bts.git and osmo-bsc.git and is the cause of a couple of "red" Jenkins builds for those projects. I've quickly followed-up with patches for those two repositories to make sure other people/patches don't suffer from fall-out. What's important to note from now on and in the future: * don't use any string identifiers that violate osmo_identifier_valid() * check the return value of calls like osmo_fsm_register() as they may fail if your identifiers are incorrect * use ':' as separator in rate_ctr_group or rate_ctr names. Any existing '.' will be transparently converted to ':' for compatibility reasons. * if you find other sub-systems in the libosmo* universe that use string identifiers for certain objects, let's try to introduce calls to osmo_identifier_valid() in all of their registration paths to ensure that we could later on add automatic export of such objects to CTRL or other interfaces without having to change the name at that point. Things that come to my mind are e.g. * SCCP global titles and AS/ASP names in libosmo-sigtran * SMPP ESME names in osmo-{msc,nitb} Patches welcome! Regards, Harald -- - Harald Welte <hwelte(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 * Geschaeftsfuehrer / Managing Director: Harald Welte

7 years, 10 months

Problem running osmoBTS with BladeRF

by Anindya Sankar Roy

Hello all, I am getting the following error and osmocom-bts-virtual just closes giving following error. bts.c:208 Shutting down BTS 0, Reason Abis close <0006> bts_model.c:161 Unimplemented bts_model_trx_deact_rf <0006> bts_model.c:55 Unimplemented bts_model_trx_close Please help Thanks Anindya

7 years, 10 months

Re: layer23/mobile: VTY is broken

by Harald Welte

Hi Neels, On Mon, Oct 23, 2017 at 03:54:40AM +0200, Neels Hofmeyr wrote: > Ah, damn. I checked all of the repositories I know to use the VTY, I didn't > imagine that OsmocomBB also has a VTY. That's really my fault then. I think in general we should not fall into that trap. We have *no clue* at all who might be using libosmo* for whatever purpose. If we provide a libary with a given API/ABI, then it's our responsibility to keep that ABI/API as stable as possible. I understand that it was hardly possible without fall-out in that particular case, and for sure there are exceptions. However, completely unrelated to this particular topic (and hence the Cc to openbsc@) I'm not happy in general with the way how "carlessly" we sometimes introduce breakage. We have to be more disciplined in general on this. All of us. BTW: The fact that this change has gone into master without being noticed also means that possibly we're not modelling osmocom-bb as a downstream user of libosmocore that needs to be rebuilt (and at least checked if it starts up correctly?) whenever testing a libosmocore change. That's also something to investigate. Maybe there's some way we can test this without too much effort. 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)

7 years, 10 months

Re: [MERGED] libosmocore[master]: Cleanup jenkins build scripts

by Neels Hofmeyr

This patch was merged, but I frankly don't like what it does. Building in a separate dir is fine, but it does so with a bunch of changes along that introduce indenting errors and potentially destroy the scripts' certainty of building cleanly every time. Please still reply to my comments at https://gerrit.osmocom.org/#/c/3132/ ...maybe actually here on the ML instead of on gerrit? Thanks! ~N

7 years, 10 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC October 2017