December 2016 - OpenBSC - lists.osmocom.org

Re: range1024 encoding question
by Max 08 Dec '16

08 Dec '16

In which repo it is? I don't know of other users but I might have overlooked smth. 08.12.2016 21:10, Holger Freyther пишет: > > hard to say. Initially I tried to use less storage but we have other range encoding users and testcases for it? E.g. Jacob created property based testing for it. Did you have a look there? > > holger > > -- 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 Directors: Holger Freyther, Harald Welte

1 0

range1024 encoding question
by Max 08 Dec '16

08 Dec '16

Hi. I've stumbled upon situation where range1024 encoding produces weird results - see gerrit #1373 and http://jenkins.osmocom.org/jenkins/job/OpenBSC-gerrit/1515/IU=--disable-iu,… right before "Wrong number of arfcns" Is this because I call it somehow wrong or there's actually a flaw in our implementation? -- 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

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