OpenBSC

openbsc@lists.osmocom.org

4315 discussions

about merging deletion of checking-value-strings script from libosmocore
by Neels Hofmeyr 01 Sep '17

01 Sep '17

I would have welcomed more patience in merging https://gerrit.osmocom.org/3685, "Use value string check from osmo-ci" in libosmocore. (the commit log of which fails to indicate removal of the script, btw) Moving to the new repositories, I have enough loose ends flapping in the wind, and dropping the script from libosmocore has added yet another distraction, while not being necessary to start using the one from osmo-ci. Max clearly posted "N. B: this should be merged last, after all the repos converted to check script from osmo-ci." -- which is not the case for the new repositores split from openbsc.git. In osmo-msc I have >50 patches waiting to be merged. The timing could hardly have been worse, luckily only a few gerrit builds are affected. Will try to sort out merging of the patches without needing a rebase and >50 rebuilds. Thanks for you attention :) ~N

2 2

RFC: use git-version-gen from gnulib
by Max 01 Sep '17

01 Sep '17

Hi. I'd like to propose to switch from local (unmaintained?) copy of git-version-gen script and use it directly from upstream gnulib package. It's available pretty-much everywhere (including ancient Debian which we support for nightly). It's also available in meta-oe: https://layers.openembedded.org/layerindex/recipe/47365/ It doesn't feel right to use copy-pasted code when we could offload the maintenance work to packaging/dependency tools. What do you think? Please contribute to https://osmocom.org/issues/2467 which I've created to track this RFC. -- Max Suraev <msuraev(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

2 2

[PATCH] test/common.sh: fix typo in gapk binary location
by Vadim Yanitskiy 31 Aug '17

31 Aug '17

--- test/common.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/common.sh b/test/common.sh index 39cdd7d..591be3a 100644 --- a/test/common.sh +++ b/test/common.sh @@ -4,7 +4,7 @@ REFDIR=./ref-files if [ -f ../src/gapk ]; then GAPK=../src/gapk elif [ -f `which gapk` ]; then - GAPK=`whiich gapk` + GAPK=`which gapk` else exit 1 fi -- 2.14.1

3 2

redmine e-mails broken from 08/26 through 08/31
by Harald Welte 31 Aug '17

31 Aug '17

Dear Osmocom community, from August 26th 06:54 UTC through August 31st 06:22 UTC our Osmocom.org redmine could not send any e-mails. This was due to a configuration file syntax error introduced by me, my apologies. If you rely on redmine e-mail notifications to the issues you have subscribed to, please double-check as related notifications during that interval were unfortunately lost. Best regards, Harald p.s.: The reason for the config change was to enable e-mail notifications from jenkins.osmocom.org (which it now has, if you want to configure e.g. post-build notification actions). -- - 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

Wanted: OpenBSC / Osmocom users in Pakistan?
by Harald Welte 30 Aug '17

30 Aug '17

Hi All! I'm wondering if there are any users of the Osmocom cellular stack in Pakistan around. If so, please kindly follow-up by private mail, as there might be some projects in which your help would be appreciated. Thanks in advance. 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

BSC+BTS SI + LAPD validation, TTCN-3 Testsuite
by Harald Welte 29 Aug '17

29 Aug '17

Dear all, I've started to implement some test cases that validate the accuracy of OsmoBTS and OsmoBSC SYSTEM INFORMATION generation. Those test cases are written in TTCN-3, which is a special programming language specifically designed for testing and validation of protocol stacks. For those present at OsmoDevCon, I've briefly presented about it there. In terms of general core infrastructure, I've written: * Definition of GSM RR and some other commonly used GSM types using the TTCN-3 type description language and the TITAN RAW (binary) encoder/decoder. The beauty of this is that one can simply describe the message structure without having to generate any code for encoding/decoding the message. See http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_Types.ttcn and http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSM_SystemInformation.… * A GSMTAP Test Port, whcih is basically how a TTCN-3 testcase/testsuite interacts with a given IUT (implementation under test). It is implemented as dual-faced port on top of the TITAN IPL4asp (ip layer 4) port and implements GSMTAP header encoding/decoding from/to TTCN-3 structured data types: http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSMTAP_PortType.ttcn which uses http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/GSMTAP_Types.ttcn describing the GSMTAP header format. * Helper functions to emulate interactive use of the VTY based on the existing TITAN TELNETasp Test Port: http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/Osmocom_VTY_Functions.… * L1CTL type definition (again using auto-generated encoder/decoders!) http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/L1CTL_Types.ttcn as well as an L1CTL Test Port at http://git.osmocom.org/osmo-ttcn3-hacks/tree/library/L1CTL_PortType.ttcn Using the above one can easily interface from TTCN3 with L1CTL of virtphy in order to e.g. sync to a BTS on a given ARFCN and establish a dedicated radio channel. Here is where the beautoy of the TTCN3 type language, templates and matching can be seen. It's very easy to perform something like "does this IMMEDIATE ASSIGNMENT match the RA + FN of the RACH request that I sent? Based on all of the above, there's two test suites: == Test Suites 1) SYSTEM INFORMATION contents and scheduling validation I've written some SI validation code which can be found at http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo SI scheduling is quite complex, particularly when you have many of the 2ter/2bis/2quater/13/2n/... enabled. At some point actually you will overflow what's possible to comply with the rules in a BCCH Norm. and you have to go to a BCCH Extd. (OsmoBTS doesn't implement the latter yet, btw). See e.g. function f_validate_si_scheduling() for validation of scheduling constraints: http://git.osmocom.org/osmo-ttcn3-hacks/tree/sysinfo/Test.ttcn#n229 Later in the file you can find test cases TC_cellid() and below for the individual test cases that validate that individual VTY configured values such as BSIC, CellId, LAC, ... are actually broadcast in the SI message. IT will update its internal matching template and then perform a sequence of VTY commands to e.g. change the LAC followed by verifying that the LAC of the decoded SI has actually changed. The above tools have helped to discover (and fix) the following bugs: * http://osmocom.org/issues/2368 * http://osmocom.org/issues/2367 * http://osmocom.org/issues/2365 (very critical, I believe) and also the not-yet-fixed but low-importance * http://osmocom.org/issues/2364 2) LAPDm testing I've written some (early) LAPDm testing code at http://git.osmocom.org/osmo-ttcn3-hacks/tree/lapdm The idea here is to test for valid and invalid transactions on the Um interface and see how OsmoBTS and the libosmcore lapdm code perform. With very few lines, this has already uncovered the following issues: * http://osmocom.org/issues/2370 * http://osmocom.org/issues/2380 Unfortunately my progress was severely affected over the weekend as I spent about one working day wrapping my head around something that turned out to be a bug in the Eclipse TITAN RAW coder, see https://www.eclipse.org/forums/index.php/t/1087557/ - fortuantely the Titan team has provided both a work-around and a fix today, which I count as excellent service. If you're curious about TTCN-3, I strongly recommend http://www.ttcn-3.org/files/TTCN3_P.pdf as an introductory slide deck. == Outlook I want to add more test cases to the sysinfo and lapdm test suites and get hands-on experience with the Junit XML output plugin. At that point, a Debian 9 build slave of our jenkins should be able to automatically build + run the latest test cases from osmo-ttcn3-hacks.git and present the individual test case results inside jenkins. I also want to add test suites for validation of: * proper generation + scheduling of of PAGING REQUEST in the BTS, considering paging groups particularly in the context of different BS_AG_BLKS_RES values * CBCH validation * proper generation of CCCH load indications by the BTS, i.e. generate a certian load e.g. on uplink RACH and check the reports * TA loop verification (add timing information to GSMTAP and then dynamically change timing from MS side to see that BTS is compensating as expected * power control loop verification: GSMTAP already has a field for transmitting RSSI in dBm. We can adjust this from the MS side to validate the BTS will adjus the instructed transmit power level of the virtual MS accordingly * actually exhaust all channels of a multi-TRX virtual BTS in different channel combinations, verify we can establish all existing logical channels in each configuration * combine the last topic with configurations that have dynamic PDCH/TCH channels to verify we properly switch forward and backward * various link failure conditions, i.e. does the BTS close the logical channel in the expected timing after uplink loss? Despite my current excitement about all of this, I'm not sure how much time I will be able to spend on this, given that the sysmocom customer priority is typically not the development of automatic test suites. But I'll try my best. If anyone wants to join: TITAN is just one "apt-get install eclipse-titan" away! == What's not good to test with TTCN-3 / TITAN: While the existing infrastructure I've built is very suitable to test low-level protocol topics, I think it's not particularly useful/applicable in other areas: * SI REST OCTETS and GPRS RLC/MAC, as they're defined in CSN.1 and TITAN has no CSN.1 encoder/decoder. For easy mathing/generation of those messages, we'd have to find something like an external CSN.1-to-ASN.1-BER or CSN.1-to-XML converter which we could use. I'd be happy to consider paying a reasonable amount for a proprietary product, just as long as we are sure that it will provde the kind of productivity that's useful here. * full end-to-end tests with actual mobile phones, RF and BTSs in the picture. We already have osmo-gsm-tester for this, and Titan with its powerful type language, templates and matching capabilities doesn't provide all that much benefit here over other languages/approaches * higher-layer protocol testing. We do have OsmocomBB as a L2 + L3 MS-side implementation, and I don't think it makes sense to replicate this. Even while the message encoding/decoding is super easy with TITAN, we still have all the related state machines. So I'd rather extend OsmocomBB where needed for automatic test cases than reinvent the wheel here. 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)

3 4

Osmocom release process update
by Max 28 Aug '17

28 Aug '17

Hi. Just a heads-up on recent changes related to Osmocom releases. In short: read about it at https://osmocom.org/projects/cellular-infrastructure/wiki/Make_a_new_release Somewhat longer explanation: In attempt to simplify and structure release process (see https://projects.osmocom.org/issues/1861 ) I've added helper script (osmo-release.mk, installed by recent libosmocore-dev) which attempts to automate as much as possible: * treat library and non-library projects differently * autogenerate debian/changelog * automatically bump version * cleanup TODO-RELEASE * checks for missing *_LIBVERSION update * automatically commit, sign and tag the result Of course it might fail to do the right thing for multitude of reasons (incorrectly filled TODO-RELEASE, missing tags, missing git-version-gen helper, weird versions in debian/changelog etc) so nothing is pushed automatically. You're expected to inspect the release commit and push it manually (don't forget to push the tag too!). In general, it works: made libosmo-abis 0.4.0 and osmo-bts 0.6.0 releases using it. The patches to make it available to other *osmo* projects are under review. Now, if you've read that far, you must be really interested in making release for some Osmocom project (or just really bored :) Either way, please do any of the following: * read the wiki page linked above and see if anything unclear/poorly written/needs corrections * suggest further updates to release policy described in there * review corresponding patches in gerrit * suggest further automation step (ideally, as a patch to osmo-release.mk ;) * try "make release" for one of the projects not mentioned above (if you have sufficient rights to push tags to gerrit) * have a look at recent libosmo-abis (>=0.4.0) and osmo-bts (>=0.6.0) and see if anything is broken N. B: release helper expects version to follow http://semver.org/ - this has been raised in ML and no objections followed. Please adhere to it for all future versions. -- Max Suraev <msuraev(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

1 0

osmocom.org redmine unable to register new users?
by Neels Hofmeyr 27 Aug '17

27 Aug '17

I notice that our osmocom.org redmine no longer seems to send out registration mails. See https://osmocom.org/issues/2466 ~N

1 0

osmo-msc patch series from openbsc.git
by Neels Hofmeyr 27 Aug '17

27 Aug '17

I rebased the recent openbsc.git patches to osmo-msc.git and am submitting all of them on gerrit, to make sure each passes the tests. Since they are already accepted on openbsc.git, I'll also directly +2 and merge them. We will be re-using the same Change-Ids from openbsc.git, and I checked: if multiple commits match the same change-id, a search on gerrit will simply list all matches, so we're not losing any information. https://gerrit.osmocom.org/#/q/Ie7cdf16232181d4b8093e61f2d8a3faed9010d4f ~N

2 2

Jenkins build slave setup / messy
by Harald Welte 25 Aug '17

25 Aug '17

Dear all, I had to spend a large portion of my spare time last night in order to add a new jenkins build slave in a way that it works. What should have been very simple by following the wiki at https://osmocom.org/projects/osmocom-servers/wiki/Jenkins_Node_Setup turned out into a long process of failures that still continue, see http://jenkins.osmocom.org/jenkins/job/osmo-bts-gerrit/1325/ I'm really not happy about the lack of discipline in keeping the documentation in sync - or even bothering to state in the wiki "FIXME, some stuff needs to be done which is not documented". Having very incomplete documentation that suggests something is a very easy and straight-forward task is possibly worse than having no documentation, at which point the reader/user is clear about this being a time-consuming procedure that involved manual recreation of a manual setup. We do now have "build-2.osmocom.org", which is a Ryzen 1700X eight-core CPU with 64GB RAM. It natively runs Debian 9 (stretch) and has a Debian8 build slave inside a lxc container. I've updated the wiki page, but I don't think "copy over the ~/docker directory whose contents is not under revision control and then run ./update.sh" is all that good an idea either. Adding more build slaves to a jenkins setup should be the most natural and normal thing to do. After all, the entire system is designed to scale out by adding more build slaves. I think the right process here would be to have a script that generates the build slave[s]. My preference would be to have a lxc template for it, so any new build host simply needs to lxc-create from that template. Is anyone willing to contribute in that area? 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC