OpenBSC

openbsc@lists.osmocom.org

12 participants
4278 discussions

Re: osmo-bts-trx error with tch/h
by Vadim Yanitskiy 14 Feb '17

14 Feb '17

Just let me know if I can help you somehow. I have SDR based board too. P.S. Please CC me in the further messages. With best regards, Vadim Yanitskiy.

1 0

[PATCH net-next v2 0/6] gtp: misc improvements
by Andreas Schultz 14 Feb '17

14 Feb '17

Hi Pablo, Resent as v2, because I forgot the net-next target. Sorry for noise, I promise I won't forget it again. This series lays the groundwork for removing the socket references from the GTP netdevice by removing duplicate code and simplifying the logic on some code paths. It slighly changes the GTP genl API by making the socket parameters optional (though one of them is still required). The removal of the socket references will break the 1:1 releation between GTP netdevice and GTP socket that prevents us to support multiple VRFs with overlaping IP addresse spaces attached to the same GTP socket (needed for multi APN support). Regards Andreas Andreas Schultz (6): gtp: make GTP sockets in gtp_newlink optional gtp: merge gtp_get_net and gtp_genl_find_dev gtp: unify genl_find_pdp and prepare for per socket lookup gtp: consolidate pdp context destruction into helper gtp: add socket to pdp context gtp: consolidate gtp socket rx path drivers/net/gtp.c | 564 +++++++++++++++++++++++++++--------------------------- 1 file changed, 280 insertions(+), 284 deletions(-) -- 2.10.2

5 28

Re: osmo-bts-trx error with tch/h
by Vadim Yanitskiy 13 Feb '17

13 Feb '17

Great work Max! I just applied your patch to the libosmocoding, and the problem was solved. Valgrind now says, that everything is ok ;) BTW: did the osmo-bts-trx TCH/H problem solved? With best regards, Vadim Yanitskiy.

2 1

Re: osmo-bts-trx error with tch/h
by Vadim Yanitskiy 11 Feb '17

11 Feb '17

> Is this also covered in gerrit review for some of your patches like 933 > or 1628? Yeah, it's covered by https://gerrit.osmocom.org/#/c/933/ , and this is exactly the reason, why the change isn't ready to merge yet :( Well, some more details: # valgrind --track-origins=yes tests/coding/.libs/lt-coding_test ==27652== Memcheck, a memory error detector ==27652== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==27652== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==27652== Command: tests/coding/.libs/lt-coding_test ==27652== xcch_decode: n_errors=60 n_bits_total=456 ber=0.13 xcch_decode: n_errors=60 n_bits_total=456 ber=0.13 xcch_decode: n_errors=60 n_bits_total=456 ber=0.13 tch_fr_decode: n_errors=8 n_bits_total=378 ber=0.02 tch_fr_decode: n_errors=8 n_bits_total=378 ber=0.02 tch_fr_decode: n_errors=10 n_bits_total=456 ber=0.02 tch_fr_decode: n_errors=10 n_bits_total=456 ber=0.02 tch_fr_decode: n_errors=10 n_bits_total=456 ber=0.02 ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x400F49: ubits2sbits (coding_test.c:48) ==27652== by 0x401416: test_hr (coding_test.c:290) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E402ED: gsm0503_tch_hr_encode (gsm0503_coding.c:1839) ==27652== ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x400F4E: ubits2sbits (coding_test.c:54) ==27652== by 0x401416: test_hr (coding_test.c:290) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E402ED: gsm0503_tch_hr_encode (gsm0503_coding.c:1839) ==27652== ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x5422CCE: osmo_conv_decode_scan (conv.c:394) ==27652== by 0x54231E8: osmo_conv_decode (conv.c:616) ==27652== by 0x4E3D677: osmo_conv_decode_ber (gsm0503_coding.c:469) ==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818) ==27652== by 0x40144A: test_hr (coding_test.c:336) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763) ==27652== ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x5422D08: osmo_conv_decode_scan (conv.c:403) ==27652== by 0x54231E8: osmo_conv_decode (conv.c:616) ==27652== by 0x4E3D677: osmo_conv_decode_ber (gsm0503_coding.c:469) ==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818) ==27652== by 0x40144A: test_hr (coding_test.c:336) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763) ==27652== ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x5422F91: osmo_conv_decode_flush (conv.c:509) ==27652== by 0x5423235: osmo_conv_decode (conv.c:619) ==27652== by 0x4E3D677: osmo_conv_decode_ber (gsm0503_coding.c:469) ==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818) ==27652== by 0x40144A: test_hr (coding_test.c:336) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763) ==27652== ==27652== Conditional jump or move depends on uninitialised value(s) ==27652== at 0x4E3D72C: osmo_conv_decode_ber (gsm0503_coding.c:480) ==27652== by 0x4E3FFCD: gsm0503_tch_hr_decode (gsm0503_coding.c:1818) ==27652== by 0x40144A: test_hr (coding_test.c:336) ==27652== by 0x400D62: main (coding_test.c:486) ==27652== Uninitialised value was created by a stack allocation ==27652== at 0x4E3FF30: gsm0503_tch_hr_decode (gsm0503_coding.c:1763) ==27652== tch_hr_decode: n_errors=11 n_bits_total=211 ber=0.05 tch_hr_decode: n_errors=10 n_bits_total=456 ber=0.02 tch_hr_decode: n_errors=10 n_bits_total=456 ber=0.02 tch_hr_decode: n_errors=10 n_bits_total=456 ber=0.02 pdtch_decode: n_errors=0 n_bits_total=456 ber=0.00 pdtch_decode: n_errors=132 n_bits_total=588 ber=0.22 pdtch_decode: n_errors=220 n_bits_total=676 ber=0.33 pdtch_decode: n_errors=0 n_bits_total=444 ber=0.00 pdtch_decode: n_errors=0 n_bits_total=456 ber=0.00 pdtch_decode: n_errors=132 n_bits_total=588 ber=0.22 pdtch_decode: n_errors=220 n_bits_total=676 ber=0.33 pdtch_decode: n_errors=0 n_bits_total=444 ber=0.00 Success ==27652== ==27652== HEAP SUMMARY: ==27652== in use at exit: 0 bytes in 0 blocks ==27652== total heap usage: 2,367 allocs, 2,367 frees, 397,488 bytes allocated ==27652== ==27652== All heap blocks were freed -- no leaks are possible ==27652== ==27652== For counts of detected and suppressed errors, rerun with: -v ==27652== ERROR SUMMARY: 7041 errors from 6 contexts (suppressed: 0 from 0) I paid my attention on the "Uninitialised value was created by a stack allocation" warning, and merely used memset() to fill some arrays by 0x00 in the gsm0503_tch_hr_decode(). And... it was the first time when I got successful build on Jenkins! This is the temporary solution: sbit_t iB[912], cB[456], h; ubit_t conv[98], b[112], d[112], p[3]; int i, rv, steal = 0; /** * Fix valgrind warnings: * "Uninitialised value was created by a stack allocation" * "Conditional jump or move depends on uninitialised value(s)" */ memset(iB, 0x00, sizeof(iB)); Then I started to dig deeper into the code, and used memset() one more time: http://pastebin.com/jBJT3q6R This dirty printf based debug led me closer to the problem. We are getting different results (successes and fails) because the gsm0503_tch_burst_map() refers to uninitialized value at iB[353]. Now we need to find out, where is the bug. There are two assumptions: 1) The gsm0503_tch_hr_interleave() doesn't initialize the iB[353]; 2) The gsm0503_tch_burst_map() refers to the value which it shouldn't refer to. With best regards, Vadim Yanitskiy.

2 1

Error while building osmo-bts for sysmoBTS
by Ivaylo Kostov 11 Feb '17

11 Feb '17

Hi, I was following the procedure "Compiling osmo-bts for sysmoBTS" and using poky/1.5.4/sysroots/armv5te-poky-linux-gnueabi During execution of libosmocore project it failed with: ... GEN gsm0503_conv.c Traceback (most recent call last): File "../../utils/conv_gen.py", line 26, in <module> import sys, os, math, argparse ImportError: CC oap.lo No module named argparse Makefile:735: recipe for target 'gsm0503_conv.c' failed make[2]: *** [gsm0503_conv.c] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory '/home/ivaylo/net/osmo/libosmocore/src/gsm' Makefile:460: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/home/ivaylo/net/osmo/libosmocore' Makefile:327: recipe for target 'all' failed make: *** [all] Error 2 ... I am using: Python 2.7.12+ (default, Sep 17 2016, 12:08:02) [GCC 6.2.0 20160914] on linux2 Type "help", "copyright", "credits" or "license" for more information. I think that something is broken. regards, Ivaylo -- ------------------------------ - Ivaylo Kostov <ikostov(a)sysmocom.de> <mailto:ikostov@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 ------------------------------

4 7

Re: osmo-bts-trx error with tch/h
by Vadim Yanitskiy 10 Feb '17

10 Feb '17

Hi Max and others, It seems, I faced similar problem while working on the libosmocoding. Despite the bursts_test in OsmoBTS always pass without any errors, when I merely moved some parts of GSM 05.03 code into a separate library, this test sometimes passes and fails on different machines... Thanks to tnt, who suggested me to use valgrind. Using this great tool and some tricks with memset(), I found, that the gsm0503_tch_burst_map() uses one uninitialized bit from the iB within the tch_hr_encode(). The same things happens in the tch_hr_decode(). I don't know, is it gsm0503_tch_hr_(de)interleave's bug or gsm0503_tch_burst_(un)map's one, we need to check GSM 05.03 specifications. With best regards, Vadim Yanitskiy.

2 1

Heads-Up on ongoing libosmo-sccp SIGTRAN work
by Harald Welte 10 Feb '17

10 Feb '17

Dear all, so far libosmo-sccp had some code with a partial SCCP implementation that date back to the earliest day of OsmoBSC in 2009, done by Holger. It also contained a SUA implementation which (mostly) I did last year in the wake of the Iuh and IuCS/IuPS support for the Osmocom 3G support. The latter code is already more 'modern' and uses the osmocom primitives (osmo_prim) between the SCCP User (the application) and the SCCP Provider (the library). Those primitives are modelled after the related specifications. What I'm now wokring on is to get those last SUA related patches finally merged in master, and to * add missing ASPTM and ASPSM protocol code + osmo_fsm state machines in a generic way that they can be shared by all SIGTRAN xUA variants * add M3UA while sharing more code between SUA and M3UA * introduce a MTP SAP based on osmo_prim that can be used on top of M3UA * wrap the existing sccp.c code to use the MTP SAP on the lower end and the SCCP User SAP on the upper edge In the above implementations, I am aiming for implementing SGW, ASP and IPSP roles. However, primary focus is on ASP. In the end, we will be able to stack M3UA and SCCP code using primitives, and interact with the SCCP using the exact same primitives and API as we interact with SUA currently. This will give us: * true/real IuCS/IuPS suppotr (we currently do SUA, which is not as per spec) in OsmoCSCN, OsmoSGSN and OsmoHNBGW without any real modificatin of their code * a way towards 3GPP compliant AoIP, by using the SCCP User SAP from OsmoBSC. This means that we'll also have to add that SCCP User SAP to the SCCPlite/IPA code that OsmoBSC is using for now. While all of the above sounds great, it somehow hurts me that we have already some (partial?) implementations of M3UA in cellmgr-ng (particularly the osmo-stp application). It hurts me that I'm not able to use the code that Holger wrote in recent years, but I still think it's worth-while to do an implementation centered around osmo_prim for layer-boundaries and osmo_fsm for state machines. So my apologies to Holger on this. It's not "Not Invented Here" syndrome, but I think there are reasons to take a different route than the existing code. I'm of course also looking forward to hearing other opinions on that. [... and while I'm working on this, I also think about introducing some generic inter-layer primitive logging code, so we can enable logging of the primitives at a given SAP without the specific SAP implementation having to implement anything, like we do in terms of osmo_fsm logging] 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

accelerate3g5 ML?
by Neels Hofmeyr 10 Feb '17

10 Feb '17

Will there be a separate mailing list for the accelerate3g5 "winners"? Maybe we could just make it a general osmocom-3G@ mailing list. Alternatively, we could use this list for 3G as well. What's the plan? ~N

2 1

Re: OpenBSC Digest, Vol 28, Issue 6
by Rajitha peiris 10 Feb '17

10 Feb '17

[cid:9b893015-fe6c-4d05-9933-7169f767fc97] ________________________________ From: OpenBSC <openbsc-bounces(a)lists.osmocom.org> on behalf of openbsc-request(a)lists.osmocom.org <openbsc-request(a)lists.osmocom.org> Sent: Thursday, February 9, 2017 9:00:47 AM To: openbsc(a)lists.osmocom.org Subject: OpenBSC Digest, Vol 28, Issue 6 Send OpenBSC mailing list submissions to openbsc(a)lists.osmocom.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.osmocom.org/mailman/listinfo/openbsc or, via email, send a message with subject or body 'help' to openbsc-request(a)lists.osmocom.org You can reach the person managing the list at openbsc-owner(a)lists.osmocom.org When replying, please edit your Subject line so it is more specific than "Re: Contents of OpenBSC digest..." Today's Topics: 1. Re: weekly test report (w5 2017) (Ivaylo Kostov) 2. Re: weekly test report (w5 2017) (Harald Welte) 3. Re: weekly test report (w5 2017) (Neels Hofmeyr) 4. Re: OpenBSC Digest, Vol 28, Issue 5 (Rajitha peiris) ---------------------------------------------------------------------- Message: 1 Date: Wed, 8 Feb 2017 16:33:26 +0100 From: Ivaylo Kostov <ikostov(a)sysmocom.de> To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> Cc: Harald Welte <laforge(a)gnumonks.org>, openbsc(a)lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <06726d26-d66f-d48d-cf9d-533178a13ada(a)sysmocom.de> Content-Type: text/plain; charset=windows-1252; format=flowed Hi Neels, Yes. I do have TCH/F_PDCH dynamic timeslots in the test procedure. regards, Ivaylo On 08.02.2017 16:26, Neels Hofmeyr wrote: > (found this mail stuck in my outbox, sending late) > > On Mon, Feb 06, 2017 at 10:09:23AM +0100, Ivaylo Kostov wrote: >> Hi Harald, >> >> I see. What was communicated to me was that NITB channel configuration >> TCH/F_TCH/H_PDCH is not supported with nanoBTS. >> >> I will have in mind that nanoBTS does not support HR (v1) codec. > > Yes, we discussed TCH/F_TCH/H_PDCH for the nanoBTS. I remember to be surprised > because from some discussion it appeared that the nanoBTS supports HR, and I > was expecting TCH/F only. > > While talking about codecs, the ip.access nanoBTS *should* in fact support the > TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of > your testing procedure and add it if not? > > ~N > >-- ------------------------------ - Ivaylo Kostov <ikostov(a)sysmocom.de> <mailto:ikostov@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 ------------------------------ ------------------------------ Message: 2 Date: Wed, 8 Feb 2017 16:45:57 +0100 From: Harald Welte <laforge(a)gnumonks.org> To: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> Cc: Ivaylo Kostov <ikostov(a)sysmocom.de>, openbsc(a)lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <20170208154557.2rmslkrzuqlv7xc4@nataraja> Content-Type: text/plain; charset=us-ascii Hi all, On Wed, Feb 08, 2017 at 04:26:11PM +0100, Neels Hofmeyr wrote: > While talking about codecs, the ip.access nanoBTS *should* in fact support the > TCH/F_PDCH dynamic timeslots. Ivaylo, could you check whether that is part of > your testing procedure and add it if not? libbsc should be extended to handle those restrictions, i.e. reject a configuration containing HR codec or a osmocom-style dynamic channel on a bts model 'nanobts'. Similarly, the BS11 should reject any codec except HRv1, FR and EFR (i.e. no AMR). In reality there are also older nanoBTSs that don't support AMR (as far as I remember), but that shouldn't prevent us from having at least the most basic checks in place. For osmo-bts, we need a more sophisticated hand-shaking mechanism, as there are many different hardware/PHYs (and associated versions) supported by it. This is left for further study ;) -- - 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) ------------------------------ Message: 3 Date: Thu, 9 Feb 2017 00:43:35 +0100 From: Neels Hofmeyr <nhofmeyr(a)sysmocom.de> To: Harald Welte <laforge(a)gnumonks.org> Cc: Ivaylo Kostov <ikostov(a)sysmocom.de>, openbsc(a)lists.osmocom.org Subject: Re: weekly test report (w5 2017) Message-ID: <20170208234335.GB27422(a)my.box> Content-Type: text/plain; charset="us-ascii" On Wed, Feb 08, 2017 at 04:45:57PM +0100, Harald Welte wrote: > libbsc should be extended to handle those restrictions, i.e. reject a > configuration containing HR codec or a osmocom-style dynamic channel on > a bts model 'nanobts'. i.e. checks on the VTY level. Seems like we want an issue for that: https://osmocom.org/issues/1946 ~N

2 2

osmo-bts-trx error with tch/h
by Max 10 Feb '17

10 Feb '17

Hi. There seems to be peculiar coding error with osmo-bts-trx and usrp b210: ... <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [0/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550946 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [1/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550950 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [0/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550955 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [1/0/0] <0006> scheduler_trx.c:1279 Received bad TCH frame ending at fn=1550959 ts=7 for TCH/H(1) <0006> gsm0503_coding.c:1850 tch_hr_decode(): error checking CRC8 for an HR frame (211/211 bits) [0/0/0] ... The error seems to: - happen only on 2nd subslot of TCH/H - does not prevent calls establishement - let voice to go through The visible effect though is extra delay for call establishment when BSC allocates next available subslot - see https://projects.osmocom.org/issues/1795 for details. Have anyone else seen this? It could be that tch_hr_decode() screw up bits somehow while trying to decode stolen FACCH bits but the code seems rather arcane. For instance, when calling unmap (it actually just attempts to get hu(B) and hl(B) flags from 3GPP TS 45.003 §4.3.5 located in bits 58 and 57 correspondingly) potentially stolen bits in the beginning of function, why bursts 0..3 are treated as even and 2..4 as odd? -- 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

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC