OpenBSC December 2016

openbsc@lists.osmocom.org

20 participants
39 discussions

M2M call with no voice
by Kristian Martens 08 Dec '16

08 Dec '16

Hello, I got a mobile to mobile call working for signalling only. Two RTP channels are being established successfully. But there are only a few pattern sent over these channels (1 byte 0x23 as UDP payload). Is there a setting I am missing in the configuration files? Please find attached a .zip file with pcap and cfg files. Thanks, Kristian

2 1

MGCP logging
by Kristian Martens 07 Dec '16

07 Dec '16

Dear all, I have switched on logging to file and have set the log level to "debug" for "mgcp" in both osmo-bsc.cfg and osmo-bsc-mgcp.cfg. Still I cannot find any output in the log file related to MGCP if I get an error. Is there a trick to make the MGCP module more verbose? Thanks, Kristian

4 18

osmo-iuh-3G_2016_09
by Radiarisainana Sitraka 07 Dec '16

07 Dec '16

Hello, I would also ask if the osmo-iuh-3G_2016_09 support the new sfr-femto tha sfr sold now (for 90 euro) or it's not available only for le old sfr femto !?Is it possible also for the new femtocell vodafone signal secure 3 !? (and if it's possible I would like to konw how to find Tx-Rx-GND for this femto) Thanks for helping chears,

2 1

osmo-trx debian nightly builds fail due to uhd requirement
by Harald Welte 06 Dec '16

06 Dec '16

Dear all, as osmo-trx has recently introduced a dependency on a super-recent version of UHD (as opposed to what regular stable distributions ship), the nightly debian builds are broken for both Debian 8.0 and Ubuntu 14.04: https://build.opensuse.org/package/show/network:osmocom:nightly/osmo-trx I would like to ask the osmo-trx folks to consider a) adding the uhd version dependencly to the debian rules b) submitting a suitable uhd package version that can be build in the osmoco nightly OBS repository 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)

4 7

osmo-trx binary can't be moved between "same" CPUs
by Neels Hofmeyr 05 Dec '16

05 Dec '16

Hi osmo-trx folks, I'd like to draw your attention to https://osmocom.org/issues/1869 -- "osmo-trx binary cannot be moved to similar CPU" Has anyone seen this before and/or is up to the task of fixing it? 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

2 2

Dynamic TCH/F_PDCH does not work as TCH/F for CS voice call
by Mrinal Mishra 05 Dec '16

05 Dec '16

Hello All, As reported earlier "CS call is not working using TCH/F_PDCH dynamic channel configuration" in URRP B210 board(osmo-trx) . We further checked the commit version using git bisect to find out the exact version from where this functionality is broken . Below is the commit version of BSC : c3f72f63afde926dfc46827d6880055597515fb6 dyn TS: fix: ts_subslots() for TCH/F_PDCH in PDCH mode Thanks and Regards, Mrinal

3 2

libosmocore support for GSMTAP based logging
by Harald Welte 02 Dec '16

02 Dec '16

Dear all, when debugging Osmocom programs, one usually looks at either the pcap trace of one of the many interfaces (Um interface via GSMTAP or OsmocomBB, Abis, Gb, Gp or A interface via ethernet, ...) or at the log files of the various osmocom programs. Sometimes it can be hard to match the two different domains, and it is useful to see in sequence when a certain message was received and what kind of actions this triggered inside e.g. OsmoPCU or OSmoSGSN. One could have used the libosmocore 'syslog' log target for this and then configure the local syslog daemon to log to a remote syslog server via the network. However, as there is another local process and context switches involved, the messages were re-ordered. Also, syslog only receives the fully-formatted log string, and not the meta-data like the log level or sub-system. Hence, the idae of having a GSMTAP based log target was floating around the project for many years. I finally implemented this today. The advantage is that in our single-threaded osmocom programs the GSMTAP messages will leave in-sequence with the protocol messages received or transmitted, and there is only the limited chance of re-ordering by the local network stack and/or intermediate routers. Both shouldn't be much of a concern during local debugging. What do you need to use this? 1) The follwoing three libosmcoore commits from gerrit: https://gerrit.osmocom.org/#/c/1355 https://gerrit.osmocom.org/#/c/1356 https://gerrit.osmocom.org/#/c/1357 2) a "log gsmtap" configuration in your config file (or via vty), similar to how syslog logging is configured: === SNIP === log gsmtap localhost logging filter all 1 logging color 1 logging print category 0 logging timestamp 0 logging level all everything logging level rll notice [...] === SNIP === 3) a wireshark with my Change-ID I0de723445e5b5ce0199a4081808111240a9ed047 (can also be found in the laforge/gsmtap-log branch of git://git.osmocom.org/wireshark or http://git.osmocom.org/wireshark/commit/?h=laforge/gsmtap-log&id=3a207894a4… I will leave this in review for a few days and then plan to merge it into libosmocore. The wireshark patch will also be submitted at that time. A screenshot is attached for your reference. There is of course no coloring of the lines in wirshark, but you can set various wireshark filters (e.g. on log level, sub-system) and also use colorization rules to e.g. map sub-systems again to colors. 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

broken build, reverting CHREQ_T_PDCH_ONE_PHASE and CHREQ_T_PDCH_TWO_PHASE
by Neels Hofmeyr 02 Dec '16

02 Dec '16

Heads up, the current openbsc build is broken, as verified by https://jenkins.osmocom.org/jenkins/job/OpenBSC/ This is due to below libosmocore commit, which adds two items to enum chreq_type, thereby implicitly enlarging the ctype_by_chreq struct and breaking the static assert for gsm_network->ctype_by_chreq's size: ../../../src/libbsc/gsm_04_08_utils.c:138:1: error: size of array ‘dummyassert_size’ is negative osmo_static_assert(sizeof(ctype_by_chreq) == ^ What this patch lacks is * adjustment of ctype_by_chreq[] according to the new additions in libbsc/gsm_04_08_utils.c * same for reason_by_chreq[], also in libbsc/gsm_04_08_utils.c * enlarge ctype_by_chreq[] in gsm_network to 18, in openbsc/gsm_data.h. I could try to guess what the ctype_by_chreq[] and reason_by_chreq[] items should be, but to not get distracted from my current task, and since the values don't seem to be used by the current master branches yet, I decided to simply revert the libosmocore commit and leave it up to the original authors to follow up. (No need to mention that those should be merged to libosmocore and openbsc "at the same time" to avoid builds failing.) Thanks and apologies for any inconvenience... ~Neels commit c3c28528de78fd5d50c3a141c2176c0da5dd7075 Refs: 0.9.0-299-gc3c2852 Author: Alexander Couzens <lynxis(a)fe80.eu> AuthorDate: Tue Nov 29 12:42:05 2016 +0100 Commit: Harald Welte <laforge(a)gnumonks.org> CommitDate: Thu Dec 1 15:26:29 2016 +0000 gsm0408: add chreq_type for CHREQ_T_PDCH_ONE_PHASE and CHREQ_T_PDCH_TWO_PHASE For BSC-located pcu the BSC must understand the PDCH chan request. Change-Id: Ice44dcaaf798f93af3652a96c567f8e16a6cf784 --- include/osmocom/gsm/protocol/gsm_04_08.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/osmocom/gsm/protocol/gsm_04_08.h b/include/osmocom/gsm/protocol/gsm_04_08.h index 767aa3d..c05b62e 100644 --- a/include/osmocom/gsm/protocol/gsm_04_08.h +++ b/include/osmocom/gsm/protocol/gsm_04_08.h @@ -1456,6 +1456,8 @@ enum chreq_type { CHREQ_T_PAG_R_TCH_F, CHREQ_T_PAG_R_TCH_FH, CHREQ_T_LMU, + CHREQ_T_PDCH_ONE_PHASE, + CHREQ_T_PDCH_TWO_PHASE, CHREQ_T_RESERVED_SDCCH, CHREQ_T_RESERVED_IGNORE, }; -- - 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

RBS 2308 Protocol Error
by Caleb Pal 02 Dec '16

02 Dec '16

Good Evening, With the recent commits for the OM2000 protocol, I figured it was time to dust off the RBS2308 and see what would happen. I am using the latest version of DAHDI, with a TE122P T1 card. All osmocom software was pulled yesterday and installed successfully on a machine running Debian Stable. When OpenBSC starts, all appears normal with regards to bringing the BTS up until the timeslots for the first TRX are being configured. When the timeslots are configured, a protocol error is given for each. If I change trx0/ts0 from the default of CCCH+SDCCH4 to CCCH, that timeslot is successfully brought up, and the BTS transmits. Other configurations (TCH/F, TCH/F, PDCH, SDCCH8, TCH/F_TCH/H_PDCH) on timeslots 1-7 give the same protocol error. I have attached my openbsc.cfg, the output from the OpenBSC console, a pcap of the failed startup, and my DAHDI configuration. If they do not come through the list server, they are also available at: http://cleb.org/RBS/ Thanks, Caleb

3 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC December 2016