OpenBSC

openbsc@lists.osmocom.org

4 participants
4156 discussions

Message Sequence Charts on A / SCCPlite / 3GPP AoIP

by Harald Welte

Dear all, today I put together some message sequence charges on the different A interface configurations. This should serve to establish some kind of "common understanding" about what is different in terms of a) classic A interface (E1 on Abis and A) b) Old OsmoBSC with Abis/IP and SCCPlite+MGCP on A c) New OsmoBSC with Abis/IP and 3GPP AoIP d) New OsmoBSC with Abis/E1 and 3GPP AoIP (extended MGW) The document is in gerrit review, but you can also find a rendered version of the current draft at http://people.osmocom.org/laforge/tmp/aoip-mgw-options.pdf Please let me know if your understanding of the different protocol/options is different. I'll continue to work on the document and add some more textual explanation. 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)

8 years, 1 month

osmo-trx rx gain question

by Max

Hi. While testing latest osmo-trx in multi-trx mode I've noticed following errors: sudo chrt -r 99 ./Transceiver52M/osmo-trx -c 2 -x -m linux; GNU C++ version 6.2.0 20161005; Boost_106100; UHD_003.009.006-release opening configuration table from path :memory: Info: SSE3 support compiled in and supported by CPU Info: SSE4.1 support compiled in and supported by CPU Config Settings Log Level............... NOTICE Device args............. TRX Base Port........... 5700 TRX Address............. 127.0.0.1 Channels................ 2 Tx Samples-per-Symbol... 4 Rx Samples-per-Symbol... 4 EDGE support............ Disabled Reference............... External C0 Filler Table......... Disabled Multi-Carrier........... Enabled Tuning offset........... 0 RSSI to dBm offset...... 0 Swap channels........... 0 -- Detected Device: B210 -- Operating over USB 2. -- Initialize CODEC control... -- Initialize Radio control... -- Performing register loopback test... pass -- Performing register loopback test... pass -- Performing CODEC loopback test... pass -- Performing CODEC loopback test... pass -- Asking for clock rate 16.000000 MHz... -- Actually got clock rate 16.000000 MHz. -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting master clock rate selection to 'automatic'. -- Asking for clock rate 51.200000 MHz... -- Actually got clock rate 51.200000 MHz. -- Performing timer loopback test... pass -- Performing timer loopback test... pass -- Setting B200/B210 4 SPS Multi-ARFCN -- Transceiver active with 2 channel(s) NOTICE 139729930782464 12:59:47.8 Transceiver.cpp:794:driveControl: Changing TSC from 0 to 7 NOTICE 139729930782464 12:59:47.8 Transceiver.cpp:243:start: Starting the transceiver NOTICE 139729930749696 12:59:48.0 Transceiver.cpp:794:driveControl: Changing TSC from 7 to 7 ALERT 139729930749696 12:59:48.0 UHDDevice.cpp:611:setRxGain: Requested non-existent channel 1 ALERT 139729930749696 12:59:48.0 UHDDevice.cpp:611:setRxGain: Requested non-existent channel 1 ... This doesn't seem to have any visible effect but still makes me wonder what's going on here? If this is indeed critical error than what exactly is broken and how to test it? If it's smth which could be safely ignored than why it's reported with alert priority? Any help clarifying it would be appreciated. -- 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

8 years, 1 month

osmo-gsm-tester successfully runs {NITB, AoverIP} x {sysmoBTS, B210}

by Neels Hofmeyr

Just now I obtained a successful test run of the osmo-gsm-tester with these combinations: OsmoNITB with sysmoBTS OsmoNITB with osmo-bts-trx (Ettus B210) OsmoMSC + OsmoBSC (AoverIP) with sysmoBTS OsmoMSC + OsmoBSC (AoverIP) with osmo-bts-trx (Ettus B210) http://jenkins.osmocom.org/jenkins/view/osmo-gsm-tester/job/osmo-gsm-tester… yay! :) All of these are now enabled by default. ~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

8 years, 1 month

PCU socket in OsmoNITB breaks osmo-gsm-tester

by Neels Hofmeyr

> commit b4999b60d48bcbb5aa575973d068e07ab672e095 > Author: Philipp Maier <pmaier(a)sysmocom.de> > Date: Wed Oct 26 15:19:41 2016 +0200 > > pcu_sock: add basic pcu interface support > > Adds a basic version of a pcu socket interface, similar > to the one that can be found in osmo-bts. > > Change-Id: Ib13cb4099d12fa71e9e0b8727e19ab29e11909b2 This commit adds PCU sockets to OsmoNITB, but these are not configurable, which is a problem for the osmo-gsm-tester. We cannot have separate OsmoNITB processes all write to /tmp/pcu_bts, their paths needs to be configurable. Also they seem to not be cleaned up when the process exits. I now see failures of OsmoNITB starting because the /tmp/pcu_bts is still present. This appears when a different user attempts to start an OsmoNITB, i.e. I had a successful run with the 'jenkins' user and am then trying as 'neels'. I guess the PCU socket file should be cleaned up on exit?? The third point is that I don't understand why the OsmoNITB or the OsmoBSC need PCU sockets. The commit log does not explain that unfortunately. I would like this commit to be reverted until the location is configurable, so that the osmo-gsm-tester can continue to run across several users. (and several NITBs at once, which we're not using yet, but in principle could want to.) I have a ticket for this in the OsmoGSMTester project, we may need to move it to a different parent project or create a new ticket: https://osmocom.org/issues/2293 ~N

8 years, 1 month

static builds in jenkins

by Max

Hi. Most (if not all) of Osmocom libraries can be built for static linking. With the addition of https://gerrit.osmocom.org/#/c/2748/ we can leverage this to also build static OpenBSC which comes in handy while testing from time to time. Would be nice to add this option to jenkins as well (for OpenBSC as well as all the libraries). What do you think? -- 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

8 years, 1 month

Re: OsmocomBB compile testing / Re: libosmocore embedded build

by Craig Comstock

I was thinking about how to setup an automated real device test for the repo and/or PRs especially. I have devices and cables, just was thinking about how to automate the re-loading of firmware (via an interface to the power button I suppose). Any work ongoing on this front? I'd be happy to contribute as I have a server I'm going to use for nano3g, calypsobts, development. -Craig -------------------------------------------- On Thu, 5/18/17, Harald Welte <laforge(a)gnumonks.org> wrote: Subject: OsmocomBB compile testing / Re: libosmocore embedded build To: "André Boddenberg" <dr.blobb(a)gmail.com> Cc: baseband-devel(a)lists.osmocom.org, "OpenBSC" <openbsc(a)lists.osmocom.org>, "Vadim Yanitskiy" <axilirator(a)gmail.com> Date: Thursday, May 18, 2017, 1:24 PM Hi Andre and others. We currently have a series of patches from Vadim pending in gerrit for OsmocomBB. They cannot move ahead, as we have no compile testing / jenkins job which would give this a +1. To resolve this, we should also start to have a jenkins compile testing job for OsmocomBB. The "host" (PC) part of the code is built against regular libosmocore, just like e.g. openbsc or osmo-bts. That should be possible even so far, and it might make sense to start with that. Basically you need to: * git clone osmocom-bb * cd src/host/layer23 * regular 'autoreconf -fi && ./configure && make' compile-testing the 'embedded' (firmware) part is not possible easily in the current master. However, as a second step, and after the libosmocore embedded build has run (and it is installed to /usr/local/arm-none-eabi), and if you use the laforge/remove-libosmocore branch in OsmocomBB, you should also be able to compile-test the firmware using * git clone osmocom-bb * cd src/target/firmware && make There currently is no "make check" tests for either the host utilities or the firmware, and of course we have no clue if the resulting binaries will do anything useful on an actual pone [yet!], but I still think the two steps above would be very useful to move ahead, and to unify the patch submission/review/verification/approval/merge process in gerrit with what we have established for the network-side projects like OsmoBTS & co. 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)

8 years, 1 month

m3ua and sua testing as part of jenkins?

by Harald Welte

Dear all, for some time, I've been wanting to have an easy way to run m3ua-testtool and sua-testtool as part of our regular regression testing setup. After some very disappointing trials using docker (see my blog), I managed to make this work using the 'unshare' program (part of util-linux). The key regquirement basically is: * create a network namespace * configure some netdevice / ip adresses in it * run the software under test (osmo-stp in this case) * run the test suite * tear down everything Initially I tried to do this using 'ip netns', but the problem is that you normally require root permissions to configure the netdevice inside the new namespace. And being root is of course difficult if you think of a jenkins build slave. However, 'unshare' offers the ability to map your real UID to root inside the namespace. At that point, everything can be done as non-root. The resulting scripts are in libosmo-sccp/contrib/test: "run-in-ns.sh" is a simple wrapper around unshare, so you have to call something like ./run-in-ns.sh ./test-m3ua.sh In order to use the m3ua-testtool, you will need to * install guile * clone + build + install https://github.com/nplab/guile-sctp * clone + build m3ua-testtool and sua-testtool from git.osmocom.org, no installation of this require. I would appreciate feedback from others trying to reproduce the above setup on their machine[s]. All tests should be GREEN/PASS. If anyone knowns how to integrate this with jenkins for libosmo-sccp,I think it would be great to have this as part of our testing of gerrit patches. I'm not so sure if it makes sense to try to integrate this with "make check", as it is not a unit test (and it would only work on Linux). I'm planning to use the saee "run-in-ns.sh" approach for my SCCP level tests implemented in TTCN-3/Titan. One further idea is if it make sense to report the test reuslts in a more friendly way. Right now it's deailed osmo-stp logs interspersed with output from the tester. Mayb there's some more information we can feed back into jenkins? Again, I have very little understanding of jenkins. 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)

8 years, 1 month

gapk jenkins integration

by Harald Welte

Dear all, gapk (the GSM Audio Pocket Knife) now has tests that can be executed in order to determine if encoding and decoding from/to most supported formats still work "most" as the file source can only read codecs with fixed block size, so AMR cannot be tested yet. It would be great if somebody[tm] would jump in to add this to jenkins, so new commits can be tested against this. Thanks in advance! The test is not integrated with autotest, I wasn't sure if it makes sense. Probably yes, to unify with other projects? In either case, after a successful 'make', you should be able to do a (cd test && ./test_all_formats.sh) and get some meaningful output as well as a status code (1 = error, 0 = success). Patches for autotest integration or any other step towards CI integration is much appreciated. I'm planning to disable direct git commit and move patch submissions to gerrit soon, too (to get the benefit of pre-merge patch verification). I'll also be working on some usage examples on gapk in the redmine wiki and/or included with the tool. By now you can use it as a RTP sink to transcode an RTP stream and play it back on your sound card via ALSA, which is very useful, particularly in combination with a patch that will enable you to issue a MDCX from the BSC VTY, requesting the BTS to redirect the RTP stream e.g. to that gapk RTP sink. 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)

8 years, 1 month

Illegal instruction error

by Max

Hi. It seems like some of the recent changes to libosmocore cased following build failures: [ 216s] +/usr/src/packages/BUILD/tests/testsuite.dir/at-groups/9/test-source: line 25: 28875 Illegal instruction $abs_top_builddir/tests/conv/conv_gsm0503_test See https://build.opensuse.org/package/live_build_log/network:osmocom:nightly/l… Could you please have a look as to what's causing it? I'm also puzzled by the build failing on 16.10 only. Versions 16.04 and 17.04 seems to be fine. -- 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

8 years, 1 month

redmine search for issues problem

by Neels Hofmeyr

Just noticed, in redmine, it's best to search without any projects selected, even if they are the parent of some others you intend to search in: - go to osmocom.org - enter 'AoverIP' in the search field (do not select a particular project). - find 5 issues, they are from projects OsmoMSC and OsmoBSC. versus: - select 'Cellular Infrastructure', next to the search field at 'Jump to a Project' - enter 'AoverIP' in the search field. - Find no issues at all. Why? OsmoMSC and OsmoBSC are both subprojects of Cellular Infrastructure. ... good to know. ~N

8 years, 1 month

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC