OpenBSC

openbsc@lists.osmocom.org

4315 discussions

<0004> abis_rsl.c:1423 BTS 0 CHAN RQD: no resources for SDCCH 0xf
by Sipos Csaba 29 Nov '15

29 Nov '15

Dear List, I am in the process of further updating the following Wiki article: The goal is to have a clean, up to date manual which tells in detail how to set up OpenBSC. In the light of recent changes I decided to change this already working setup to use the "master" branches of every involved Osmocom project. It is finally possible to compile and run every project after the proper dependencies are met. But some new problem popped up I haven't seen before. After everything is started up (OpenBSC, GGSN, SGSN, LCR, TRX, and PCU), when a phone tries to RACH, this is what I get in the BSC log: Sat Nov 28 14:09:08 2015 <0004> abis_rsl.c:1423 BTS 0 CHAN RQD: no resources for SDCCH 0xf Sat Nov 28 14:09:19 2015 <0004> abis_rsl.c:1423 BTS 0 CHAN RQD: no resources for SDCCH 0x6 Sat Nov 28 14:09:30 2015 <0004> abis_rsl.c:1423 BTS 0 CHAN RQD: no resources for SDCCH 0x6 On the BTS side, this is what I get: <0006> scheduler.c:1186 Received Access Burst on RACH fn=9868 toa=5.88 <0006> scheduler.c:1192 Received bad AB frame at fn=9868 (25/51) <0006> scheduler.c:1186 Received Access Burst on RACH fn=52459 toa=-1.50 <0006> scheduler.c:1192 Received bad AB frame at fn=52459 (31/51) <0006> scheduler.c:1186 Received Access Burst on RACH fn=67956 toa=-0.06 <0006> scheduler.c:1192 Received bad AB frame at fn=67956 (24/51) Because I used exactly the same config files I used before when it all worked, I analyzed the logs a littlebit more. In the BTS log, during the OML setup this is what I found: <0001> oml.c:802 ADM state already was Unlocked <0001> oml.c:256 OC=BASEBAND-TRANSCEIVER INST=(00,00,ff) OPER STATE NULL -> Enabled <0001> oml.c:217 OC=BASEBAND-TRANSCEIVER INST=(00,00,ff) Tx STATE CHG REP <000b> trx_if.c:366 Response message 'RSP ERR 1' does not match command message 'CMD SETBSIC 62' !!!!!! <0001> oml.c:1059 Rx IPA RSL CONNECT IP=127.0.0.1 PORT=3003 STREAM=0x00 <0011> input/ipa.c:129 connection done. <0011> input/ipaccess.c:693 received ID get <0000> rsl.c:279 Tx RSL RF RESource INDication Maybe the recent changes in the BSIC/TSC handling part is causing this? Anyway it seems that the BSIC I set in the BSC is the correct one the BTS tries to configure during the timeslot, transceiver and BTS setup. I attached the corresponding OML trace, and the logs. If someone has any ideas, please let me know. Regards, Csaba

2 3

[PATCH 1/8] debug: Add DSS category for supplementary service
by Sergey.Kostanbaev 29 Nov '15

29 Nov '15

From: Sergey Kostanbaev <sergey.kostanbaev(a)gmail.com> This series of patches add support for external USSD processing via simplified MAP-like protocol over SUP socket. As an example of a such external application simple USSD to SIP proxy is provided (it targets TS 124 390) --- openbsc/include/openbsc/debug.h | 1 + openbsc/src/libcommon/debug.c | 6 ++++++ 2 files changed, 7 insertions(+) diff --git a/openbsc/include/openbsc/debug.h b/openbsc/include/openbsc/debug.h index 19d8fc2..10b0f46 100644 --- a/openbsc/include/openbsc/debug.h +++ b/openbsc/include/openbsc/debug.h @@ -33,6 +33,7 @@ enum { DCTRL, DSMPP, DFILTER, + DSS, Debug_LastEntry, }; diff --git a/openbsc/src/libcommon/debug.c b/openbsc/src/libcommon/debug.c index 7fb3ecb..6536944 100644 --- a/openbsc/src/libcommon/debug.c +++ b/openbsc/src/libcommon/debug.c @@ -165,6 +165,12 @@ static const struct log_info_cat default_categories[] = { .description = "BSC/NAT IMSI based filtering", .enabled = 1, .loglevel = LOGL_DEBUG, }, + [DSS] = { + .name = "DSS", + .description = "Layer3 Supplementary Service (SS)", + .color = "\033[0;33m", + .enabled = 1, .loglevel = LOGL_DEBUG, + }, }; enum log_filter { -- 1.9.1

5 17

[PATCH 1/3] mncc: Implement helper functions to convert MNCC cause to a string.
by Alexander Chemeris 25 Nov '15

25 Nov '15

This is the first patch of the series. The first two patches are improvements of the log output and are independent of the 3rd patch in terms of code - proposed logging improvements just make it easier to debug issues with MNCC cause codes. The code is also a part of the achemeris/mncc_cause_fixes_master branch. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co

2 3

[PATCH 1/4] core: RELEASE COMPLETE can be without any payload
by Sergey.Kostanbaev 25 Nov '15

25 Nov '15

From: Sergey Kostanbaev <Sergey.Kostanbaev(a)gmail.com> This series of patches supposed to add support of USSD-menu style message handling with language support. --- src/gsm/gsm0480.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/src/gsm/gsm0480.c b/src/gsm/gsm0480.c index 952604b..9bd54fa 100644 --- a/src/gsm/gsm0480.c +++ b/src/gsm/gsm0480.c @@ -248,12 +248,6 @@ int gsm0480_decode_ss_request(const struct gsm48_hdr *hdr, uint16_t len, struct ss_request *req) { int rc = 0; - - if (len < sizeof(*hdr) + 2) { - LOGP(0, LOGL_DEBUG, "SS Request is too short.\n"); - return 0; - } - if ((hdr->proto_discr & 0x0f) == GSM48_PDISC_NC_SS) { req->transaction_id = hdr->proto_discr & 0x70; rc = parse_ss(hdr, len, req); -- 1.9.1

1 3

[PATCH 3/3] mncc: Send "Dest OOO" cause in case of a link radio failure.
by Alexander Chemeris 24 Nov '15

24 Nov '15

Previously we were sending a generic "Resource unavailable" cause code making it impossible to distinguish real error cases from a regular radio link failure. This was the reason for many "unknown" call errors we've seen at Rhizomatica installations. Now they are properly classified as non-erroneous call failures. The code is also a part of the achemeris/mncc_cause_fixes_master branch. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co

1 2

[PATCH 2/3] mncc: Log CC cause when sending a primitive to MNCC.
by Alexander Chemeris 24 Nov '15

24 Nov '15

The code is also a part of the achemeris/mncc_cause_fixes_master branch. -- Regards, Alexander Chemeris. CEO, Fairwaves, Inc. https://fairwaves.co

1 1

HAVE_LIBCARES
by Neels Hofmeyr 23 Nov '15

23 Nov '15

About below commit: Sorry / Thanks! I forgot to move gtphub into the HAVE_LIBCARES conditional when I added ares... The gtphub tests wrap the ares functions away, so they build without libc-ares. But does it make sense to enable the gtphub test when the binary isn't built? ~Neels > commit 97b6bfa996ed1745d27c5598186c4583f7e90861 > Author: Harald Welte <laforge(a)gnumonks.org> > Date: Sat Nov 21 13:16:08 2015 +0100 > > Fix compilation with no libc-ares present on the system > > This build failure was introduced with the OAP and gtphub changes. > > diff --git a/openbsc/src/gprs/Makefile.am b/openbsc/src/gprs/Makefile.am > index 5212c67..5e115eb 100644 > --- a/openbsc/src/gprs/Makefile.am > +++ b/openbsc/src/gprs/Makefile.am > @@ -11,9 +11,8 @@ noinst_HEADERS = gprs_sndcp.h > bin_PROGRAMS = osmo-gbproxy > > if HAVE_LIBGTP > -bin_PROGRAMS += osmo-gtphub > if HAVE_LIBCARES > -bin_PROGRAMS += osmo-sgsn > +bin_PROGRAMS += osmo-sgsn osmo-gtphub > endif > endif > > diff --git a/openbsc/tests/Makefile.am b/openbsc/tests/Makefile.am > index 995660a..04b8e34 100644 > --- a/openbsc/tests/Makefile.am > +++ b/openbsc/tests/Makefile.am > @@ -13,7 +13,10 @@ SUBDIRS += smpp > endif > > if HAVE_LIBGTP > -SUBDIRS += sgsn oap gtphub > +SUBDIRS += gtphub > +if HAVE_LIBCARES > +SUBDIRS += sgsn oap > +endif > endif >

2 1

[PATCH 00/16] GTP kernel update (patch bomb)
by Andreas Schultz 23 Nov '15

23 Nov '15

Hi, Sorry for smsching this all together, but I couldn't find a logical point to split the patches. Also the order can't really be changed as most patches depend on each other. After this series, the GTP kernel module is functional for IPv4 payload in IPv4 GTP tunnels (for GTPv0 and v1). The libgtnl API was changed without increasing the SO version of the lib. I think this is ok since nothing really uses it (yet) nor has the library been offcially released. Andreas Schultz (16): gtp: remove unused local variable gtp: remove genl_register_family_with_ops for Linux < 3.13 gtp: convert the global gtp_instance_list to a per netns list gtp: select netns based on NL attribute gtp-rtnl: and netns support gtp: add error handling to gtp_newlink gtp: fix the order of error cases in gtp_encap_enable gtp: add socket destroy handler gtp: replace udp encap setup with setup_udp_tunnel_sock gtp: switch to iptunnel framework and no longer depend on real_dev gtp: Split TID handling got GTPv0 and GTPv1 gtp-rtnl: sync GTPA_FLOW nl attribute name from kernel to userspace gtp-rtnl: real_ifname is not long needed, remove it gtp-rtnl: Split tid handling for GTPv0 and GTPv1 list Andreas Schultz as author gtp: add support for replacing PDP contexts gtp.c | 657 ++++++++++++++++++++++++--------------- gtp_nl.h | 3 + libgtnl/AUTHORS | 1 + libgtnl/include/libgtpnl/gtp.h | 6 + libgtnl/include/libgtpnl/gtpnl.h | 3 +- libgtnl/include/linux/gtp_nl.h | 5 +- libgtnl/src/gtp-genl.c | 34 +- libgtnl/src/gtp-rtnl.c | 10 +- libgtnl/src/gtp.c | 44 ++- libgtnl/src/internal.h | 13 +- libgtnl/src/libgtpnl.map | 6 + libgtnl/tools/Makefile.am | 4 +- libgtnl/tools/gtp-link-add.c | 5 +- libgtnl/tools/gtp-tunnel.c | 132 +++++--- libgtnl/tools/gtpnl.c | 35 --- 15 files changed, 613 insertions(+), 345 deletions(-) delete mode 100644 libgtnl/tools/gtpnl.c -- 2.5.0

4 39

channel availability
by Suraev 23 Nov '15

23 Nov '15

Hi. While trying to debug issue with osmo-pcu failing to allocate tfi due to pdch unavailability I've noticed that regular connection attempts are also failing with imm. ass. reject due to channel unavailability. I do not see rach flood so it feels like misconfiguration or maybe hw issue. MY question is - how to troubleshoot this? Where can I look as to which channels are available, which are occupied and by whom? thanks, Max.

3 7

RFC: removing talloc for good?
by Harald Welte 21 Nov '15

21 Nov '15

Hi all, I've been looking into upgrading our copy of talloc.[ch] in libosmocore, but unlike 7 years ago, it is not that easy anymore. The build system integration is quite heavy, and it might be a good point to simply drop talloc from libosmocore. Also contrary to 7 years ago, distributions tend to ship libtalloc these days. So there's not really any reason to continue shiping it. Right now I'm making it optional, and have sorted out how to make this source compatible. But this generates runtime incompabilities, due to the ABI incompabibilities between our ancient talloc and current talloc :( While the API of our talloc and current talloc seems compatible, the ABI is not. For example, they changed talloc_free() into an inline function resulting in calls to _talloc_free(), while our code links directly against talloc_free(). So We'd have to move from libosmocore-6.0.0 to 7.0.0 as part of the transition and cannot really keep both options without causing additional compatibility issues to our users. So the question is: Why bother? does anyone have objections to removing the built-in talloc? -- - 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)

2 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC