OpenBSC November 2016

openbsc@lists.osmocom.org

21 participants
30 discussions

by mosbah abdelkader

> I don't understand. This callback will be called with data you need to write > to the network. In case of MTP Level3 you will need to wrap that around the > msgb you got. I means: is the interaction with mtp3 layer implemented (is sending sccp data by mtp3 implemented by the library?)? Also, what about the reception of data from mtp3 layer. is that implemented in the sccp lib. I am asking these questions because I see the code of mtp3 in the lib but no significant call is present in the sccp part of the lib. Thank you for your help.

4 weeks

dynamic traffic channels

by Neels Hofmeyr

On Tue, Jun 28, 2016 at 10:05:28AM +0200, Harald Welte wrote: > [translated from german] > is it certain that we switch a channel to PDCH only when > gprs mode != none? A TS can be GSM_PCHAN_TCH_F_PDCH; those are the only ones for which we send a PDCH ACT message. We send a PDCH ACT message - during init (CHANNEL OML's state changed to enabled -> send PDCH ACT), - and upon channel release ack when pchan == GSM_PCHAN_TCH_F_PDCH. So the question is, when we receive a channel release ack, could that be the PDCH release and we switch PDCH right back on by accident? No, because we only receive a chan rel ack when the *TCH/F* is being released. That is because the PDCH release is initiated "internally" from the PDCH DEACT, and thus this condition in common/rsl.c rsl_tx_rf_rel_ack() catches on, which existed before dyn PDCH: if (lchan->rel_act_kind != LCHAN_REL_ACT_RSL) { LOGP(DRSL, LOGL_NOTICE, "%s not sending REL ACK\n", gsm_lchan_name(lchan)); return 0; } In rsl_rx_rf_chan_rel() the rel_act_kind is set to LCHAN_REL_ACT_RSL, but not in the rsl_rx_dyn_pdch(). This is analogous to the ip.access way -- the ip.access nanobts replies to a PDCH DEACT with a PDCH DEACT ACK and doesn't send a separate channel release ack. Maybe we could set rel_act_kind to some new LCHAN_REL_ACT_IPAC_DYN_PDCH for clarity? (But we shouldn't actually send a release ack, to stay compatible.) Even though it works as-is, we should indeed add another flag check: - We do check the flags that no ACT/DEACT is already pending; - And we do send a PDCH DEACT only if ts->flags & TS_F_PDCH_ACTIVE; - But we would send a PDCH ACT despite ts->flags & TS_F_PDCH_ACTIVE. This should never happen, but it would make sense to ensure that. ~Neels

1 month

osmo-trx jenkins

by Max

HI. A little heads up: uhd version in jenkins building osmo-trx should be updated to 3.9.0 - this would allow gerrit #1117 to be properly verified by jenkins. -- 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, 5 months

TbfTest fails sanitizer build, please take a look @tbf-folks

by Neels Hofmeyr

Dear authors of Tbf, can you make sense of this build failure? https://jenkins.osmocom.org/jenkins/job/Osmocom_Sanitizer/373/console It shows that the expected stderr output of the TbfTest deviates, and the test exits prematurely. interesting output: +tbf_dl.cpp:766:65: runtime error: load of value 32767, which is not a valid value for type 'egprs_puncturing_values' -- got ack for BSN=1258 -- got ack for BSN=1259 -- got ack for BSN=1260 +- got NACK for BSN=1258 +- got NACK for BSN=1259 +- got NACK for BSN=1260 To help reproducing it, find below the jenkins script that runs this sanitizer build. Thanks for any patches that could fix our sanitizer build! ~Neels #!/bin/sh set -ex export BUILDDIR=$PWD/build/ export PKG_CONFIG_PATH=$BUILDDIR/lib/pkgconfig export LD_LIBRARY_PATH=$BUILDDIR/lib/ export PATH="$PATH:$HOME/osmo-ci/scripts" build() { RET=$PWD git clone git://git.osmocom.org/$1 source/$1 cd source/$1 git checkout -b build-branch origin/$2 cd $3 autoreconf --install --force ./configure --prefix=$BUILDDIR $4 make check CFLAGS+="-fsanitize=address -fsanitize=undefined" CXXFLAGS+="-fsanitize=address -fsanitize=undefined" ASAN_OPTIONS="detect_leaks=0" UBSAN_OPTIONS="print_stacktrace=1:halt_on_error=1" \ || cat-testlogs.sh make install CFLAGS+="-fsanitize=address -fsanitize=undefined" CXXFLAGS+="-fsanitize=address -fsanitize=undefined" cd $RET } rm -rf $BUILDDIR rm -rf source mkdir -p source mkdir -p $BUILDDIR/include/sysmocom/femtobts git clone git://git.sysmocom.de/sysmo-bts/layer1-api.git source/layer1-api/ cp source/layer1-api/include/* $BUILDDIR/include/sysmocom/femtobts/ build libosmocore $LIBOSMOCORE_BRANCH ./ build libosmo-abis $LIBOSMOABIS_BRANCH ./ build libosmo-netif $LIBOSMONETIF_BRANCH ./ build libosmo-sccp $LIBOSMOSCCP_BRANCH ./ # gcc ice's #build libsmpp34 $LIBSMPP_BRANCH build openggsn $OPENGGSN_BRANCH ./ build openbsc $OPENBSC_BRANCH ./openbsc "--enable-nat --enable-osmo-bsc --enable-vty-tests --enable-external-tests" build osmo-pcu $OSMOPCU_BRANCH ./ "--enable-sysmocom-dsp --enable-vty-tests" build osmo-bts $OSMOBTS_BRANCH ./ "--enable-sysmocom-bts --enable-trx" -- - 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, 6 months

Osmo-bts/Osmocom-bb virtual layer 1

by Sebastian Stumpf

Hi, I further implemented the base of the virtual layer with the purpose of replacing the um-air interface with a multicast-socket solution. This has been started by Harald Welte some time ago in the Osmobts - laforge/virt-bts branch. As I was not really confident enough to create an official new branch before someone had a look on what I did, so I developed in copies of the osmocom-bb and osmo-bts projects on my github-page (https://github.com/BastusIII/osmocom-bb-virt/tree/stumpf/virt-um and https://github.com/BastusIII/osmo-bts-virt/tree/stumpf/virt-bts). If someone finds to time to have a look into them (structure, path, implementation) and give me feedback about it, I would be glad :). Please use the following config files that i have tested: - https://github.com/BastusIII/osmocom-config-files/blob/master/openbsc-virtu… - https://github.com/BastusIII/osmocom-config-files/blob/master/osmobts-virtu… - https://github.com/BastusIII/osmocom-config-files/blob/master/osmocom-bb-mo… What works: BTS: - downlink over gsmtap and a multicast socket - OML and RSL on abis properly established and seems to work - virtual-um connection establishment Osmocom-bb: - virtual-um -- l23 app connection establishment (bridging osmocon, no serial link needed) - BCCH downlink handling and forwarding to l23 app - handling of some l1ctl requests from l23 (e.g. power management had to be mocked, so l23 gets a response and is satisfied) What not: BTS: - missing uplink handling Osmocom-bb - missing uplink routines (RACH, TCH, dedicated channels) - handlers for l23 requests only partially implemented (missing TCH, RACH, ... I a currently a bit overwhelmed by the mass of messages exchanged between l23-app (used mobile, btw.) and the virtual-um and hanging because mobile gets a sync timeout. I am looking forward to hear from you :). Sebastian Stumpf

8 years, 6 months

osmo-trx debian nightly builds fail due to uhd requirement

by Harald Welte

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)

8 years, 6 months

RBS 2308 Protocol Error

by Caleb Pal

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

8 years, 6 months

confused by libosmo-netif

by Neels Hofmeyr

By random, I looked at an fd leak complained about by coverity in osmo_stream_srv_fd_cb() and came up with https://gerrit.osmocom.org/1320 Now I wanted to at least run it once to make sure I didn't break anything, but I'm unsure in figuring out how it is used. There are two Iu related callers: osmo-iuh's hnbgw.c and libosmo-sccp's sua.c. And I find libosmo-netif/src/channel/abis/ipa_stream_server.c, called in libosmo-netif/src/channel.c by osmo_chan_init() and osmo_chan_create(). But it seems no-one is ever calling these, except for examples in libosmo-netif. Am I right to conclude that there's some 2G / Abis / ip.access related code in libosmo-netif but we're not actually using it in openbsc, and that the only "real" osmo_stream_srv_* callers are 3G/Iu related? ~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, 6 months

Re: Re: Any one who can help me ,can't find a branch or tag which may compile success.!! thank u.

by Harald Welte

pleaes always make sure you send your responses to the mailing list, never by private mail to individual developer s only On Mon, Nov 28, 2016 at 07:52:39AM +0800, 韩明君 wrote: > when i use the newest version of git tag 3G_2016_09 for compile I got lots of > make error(；′⌒`) so switch to the old version if you want anyone to help you, you need to include the exact error messages (copy+paste) in your message to the mailing list. > Anad another question is where may I found the nightly package,and download the *.deb file It is really very simple. Go to osmocom.org and search for 'nigthly'. Then you will find the link to http://osmocom.org/projects/cellular-infrastructure/wiki/Nightly_Builds -- - 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, 6 months

Any one who can help me ,can't find a branch or tag which may compile success.!! thank u.

by 韩明君

hello everyone ,first thanks for yours look at this email ... i work under ubuntu 14.04 and with the doc of http://osmocom.org/projects/openbsc/wiki/Building_OpenBSC now i only can do make install and success with git version of on-waves/0.3 （openbsc） and success found the executable file drwxr-xr-x 2 root root 4096 11月 27 15:42 ./ drwxr-xr-x 11 root root 4096 11月 13 21:46 ../ -rwxr-xr-x 1 root root 551571 11月 27 15:42 bs11_config* -rwxr-xr-x 1 root root 1877782 11月 27 15:42 bsc_hack* -rwxr-xr-x 1 root root 528464 11月 27 15:42 bsc_mgcp* -rwxr-xr-x 1 root root 1547559 11月 27 15:42 bsc_msc_ip* -rwxr-xr-x 1 root root 967960 11月 27 15:42 bsc_nat* -rwxr-xr-x 1 root root 1359089 11月 27 15:42 ipaccess-config* -rwxr-xr-x 1 root root 37451 11月 27 15:42 ipaccess-find* -rwxr-xr-x 1 root root 25066 11月 27 15:42 isdnsync* but as the README under openbsc this version don't work well with ip based BTS

8 years, 6 months

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2016