OpenBSC January 2016

openbsc@lists.osmocom.org

11 participants
44 discussions

Re: [PATCH] Enable address sanitizer for tests.
by Holger Freyther 20 Jan '16

20 Jan '16

> On 20 Jan 2016, at 16:57, suraev(a)alumni.ntnu.no wrote: > > From: Max <msuraev(a)sysmocom.de> Hi, > Some tests are leaky which is ok since it's one-shot programs > anyway. For them mem. leak sanitizer is explicitly disabled via > env. variables. I think it is best to use the OpenBSC mailinglist for libosmocore and other libraries. From my point of view it really makes sense to have ASAN build and run the tests (and include leak check if we can ignore some globals) but I have a couple of issues with the specific patch: 1.) not all compilers we use support ASAN 2.) Just compiling the test doesn't help us to verify the library itself. It needs to be instrumented too! So my proposal would be: 1.) We get a gcc 5.x or clang on one of the linux builders (or I will create one) 2.) We use your AT_CHECK check so we can pass this variable from the outside too. 3.) We have a Jenkins nightly job that does make CFLAGS+="-fsanitize.." CXXFLAGS+=.. check on all dependencies > +AT_COLOR_TESTS What does this give us? > -AT_CHECK([$abs_top_builddir/tests/msgfile/msgfile_test], [0], [expout]) > +AT_CHECK([ASAN_OPTIONS="detect_leaks=0" $abs_top_builddir/tests/msgfile/msgfile_test], [0], [expout]) Did you have a look at osmo-bts and how I sneaked in support for using qemu to execute the tests?

1 0

dbi deprecation
by Neels Hofmeyr 19 Jan '16

19 Jan '16

Hi, I'm just noticing warning: ‘dbi_initialize’ is deprecated (declared at /usr/include/dbi/dbi.h:169) called from openbsc/openbsc/src/libmsc/db.c:db_init() (and a couple more dbi deprecations) Should we do something about it? ...rather: who and when? ;) ~Neels -- - 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: Holger Freyther, Harald Welte

3 3

trx-bench results for AMD G-T40E
by Harald Welte 18 Jan '16

18 Jan '16

Hi Thomas, in case you'd like to add it to your benchmark results, below is a run of trx-bench on a Debian stable (jessie) system on a G-T40E CPU @ 800MHz. What I find surprising is that it appears to be comparable than the Atom D2500 @ 1.86GHz, despite the Atom running at twice the clock rate... More details see attachments. 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

Help Bts3900B
by yasith Guette Oliveros 15 Jan '16

15 Jan '16

Hi buy a bts3900B on Ebay. I have a project similar to yours. I want to know if it was possible to open the connection with BSC. I also want my users to browse internet through my mobile network. I appreciate your help in my project.

1 0

[PATCH 1/7] sgsn: Remove tlli_foreign2local
by Jacob Erlbeck 15 Jan '16

15 Jan '16

Currently foreign TLLI are sometimes mapped to local TLLI in the hope that they will match. This seems to sometimes introduce inconsisties, possibly leading to a failing assertion in _bssgp_tx_dl_ud. This mapping should probably reduce the allocation of additional LLME during routing area changes. This commit removes tlli_foreign2local. Sponsored-by: On-Waves ehf --- openbsc/src/gprs/gprs_llc.c | 24 ++---------------------- openbsc/tests/sgsn/sgsn_test.c | 5 ----- 2 files changed, 2 insertions(+), 27 deletions(-) diff --git a/openbsc/src/gprs/gprs_llc.c b/openbsc/src/gprs/gprs_llc.c index 936354a..06ccd4c 100644 --- a/openbsc/src/gprs/gprs_llc.c +++ b/openbsc/src/gprs/gprs_llc.c @@ -39,20 +39,6 @@ static struct gprs_llc_llme *llme_alloc(uint32_t tlli); /* If the TLLI is foreign, return its local version */ -static inline uint32_t tlli_foreign2local(uint32_t tlli) -{ - uint32_t new_tlli; - - if (gprs_tlli_type(tlli) == TLLI_FOREIGN) { - new_tlli = tlli | 0x40000000; - LOGP(DLLC, LOGL_NOTICE, "TLLI 0x%08x is foreign, converting to " - "local TLLI 0x%08x\n", tlli, new_tlli); - } else - new_tlli = tlli; - - return new_tlli; -} - /* Entry function from upper level (LLC), asking us to transmit a BSSGP PDU * to a remote MS (identified by TLLI) at a BTS identified by its BVCI and NSEI */ static int _bssgp_tx_dl_ud(struct msgb *msg, struct sgsn_mm_ctx *mmctx) @@ -72,9 +58,7 @@ static int _bssgp_tx_dl_ud(struct msgb *msg, struct sgsn_mm_ctx *mmctx) /* make sure we only send it to the right llme */ OSMO_ASSERT(msgb_tlli(msg) == mmctx->llme->tlli - || msgb_tlli(msg) == mmctx->llme->old_tlli - || tlli_foreign2local(msgb_tlli(msg)) == mmctx->llme->tlli - || tlli_foreign2local(msgb_tlli(msg)) == mmctx->llme->old_tlli); + || msgb_tlli(msg) == mmctx->llme->old_tlli); } memcpy(&dup.qos_profile, qos_profile_default, sizeof(qos_profile_default)); @@ -175,10 +159,6 @@ struct gprs_llc_lle *gprs_lle_get_or_create(const uint32_t tlli, uint8_t sapi) if (lle) return lle; - lle = lle_by_tlli_sapi(tlli_foreign2local(tlli), sapi); - if (lle) - return lle; - LOGP(DLLC, LOGL_NOTICE, "LLC: unknown TLLI 0x%08x, " "creating LLME on the fly\n", tlli); llme = llme_alloc(tlli); @@ -204,7 +184,7 @@ static struct gprs_llc_lle *lle_for_rx_by_tlli_sapi(const uint32_t tlli, /* Maybe it is a routing area update but we already know this sapi? */ if (gprs_tlli_type(tlli) == TLLI_FOREIGN) { - lle = lle_by_tlli_sapi(tlli_foreign2local(tlli), sapi); + lle = lle_by_tlli_sapi(tlli, sapi); if (lle) { LOGP(DLLC, LOGL_NOTICE, "LLC RX: Found a local entry for TLLI 0x%08x\n", diff --git a/openbsc/tests/sgsn/sgsn_test.c b/openbsc/tests/sgsn/sgsn_test.c index 859223f..01e94c7 100644 --- a/openbsc/tests/sgsn/sgsn_test.c +++ b/openbsc/tests/sgsn/sgsn_test.c @@ -203,11 +203,9 @@ static void test_llme(void) { struct gprs_llc_lle *lle, *lle_copy; uint32_t local_tlli; - uint32_t foreign_tlli; printf("Testing LLME allocations\n"); local_tlli = gprs_tmsi2tlli(0x234, TLLI_LOCAL); - foreign_tlli = gprs_tmsi2tlli(0x234, TLLI_FOREIGN); /* initial state */ OSMO_ASSERT(count(gprs_llme_list()) == 0); @@ -221,9 +219,6 @@ static void test_llme(void) lle_copy = gprs_lle_get_or_create(local_tlli, 3); OSMO_ASSERT(lle == lle_copy); OSMO_ASSERT(count(gprs_llme_list()) == 1); - lle_copy = gprs_lle_get_or_create(foreign_tlli, 3); - OSMO_ASSERT(lle == lle_copy); - OSMO_ASSERT(count(gprs_llme_list()) == 1); /* unassign which should delete it*/ gprs_llgmm_assign(lle->llme, lle->llme->tlli, 0xffffffff, GPRS_ALGO_GEA0, NULL); -- 1.9.1

2 8

[PATCH 1/5] log: Add log_check_level function
by Holger Hans Peter Freyther 15 Jan '16

15 Jan '16

From: Jacob Erlbeck <jerlbeck(a)sysmocom.de> This commit adds this predicate function which can be used to avoid the execution of code if a certain log level is not enabled. The function will only return 0 (false), if it is sure that a logging call for the same facility and level will not produce any output. This safety criterion shall ensure, that no logging output is lost due to the use of this predicate as a guard. On the other hand, even if the predicate returns != 0 (true), no logging output might get generated by a similar logging command. Note that the current implementation is not focussed on performance, which could be improved by using a lookup table instead of iterating through every target. Sponsored-by: On-Waves ehf --- include/osmocom/core/logging.h | 1 + src/logging.c | 39 +++++++++++++++++++++++++++++++++++++++ 2 files changed, 40 insertions(+) diff --git a/include/osmocom/core/logging.h b/include/osmocom/core/logging.h index 1c159d0..290b33d 100644 --- a/include/osmocom/core/logging.h +++ b/include/osmocom/core/logging.h @@ -198,6 +198,7 @@ void logp2(int subsys, unsigned int level, const char *file, int line, int cont, const char *format, ...) __attribute__ ((format (printf, 6, 7))); int log_init(const struct log_info *inf, void *talloc_ctx); +int log_check_level(int subsys, unsigned int level); /* context management */ void log_reset_context(void); diff --git a/src/logging.c b/src/logging.c index 876964a..c7b1999 100644 --- a/src/logging.c +++ b/src/logging.c @@ -865,4 +865,43 @@ int log_init(const struct log_info *inf, void *ctx) return 0; } +/*! \brief Check whether a log entry will be generated. + * \returns != 0 if a log entry might get generated by at least one target */ +int log_check_level(int subsys, unsigned int level) +{ + struct log_target *tar; + + if (subsys < 0) + subsys = subsys_lib2index(subsys); + + if (subsys > osmo_log_info->num_cat) + subsys = DLGLOBAL; + + /* TODO: The following could/should be cached (update on config) */ + + llist_for_each_entry(tar, &osmo_log_target_list, entry) { + struct log_category *category; + + category = &tar->categories[subsys]; + /* subsystem is not supposed to be logged */ + if (!category->enabled) + continue; + + /* Check the global log level */ + if (tar->loglevel != 0 && level < tar->loglevel) + continue; + + /* Check the category log level */ + if (tar->loglevel == 0 && category->loglevel != 0 && + level < category->loglevel) + continue; + + /* This might get logged (ignoring filters) */ + return 1; + } + + /* We are sure, that this will not be logged. */ + return 0; +} + /*! @} */ -- 2.6.3

1 4

Some patches
by Alexander Huemer 15 Jan '16

15 Jan '16

Hi, here are some patches that I produced while compiling some osmocom projects and its dependencies on a new box. Most of them are trivialities that prevent compiler warnings. The patch for openbsc though fixes a bug that prevents the build when libgtp from openggsn is not present on the system. Kind regards, -Alex

3 35

error in Sponsored-by tag
by Neels Hofmeyr 14 Jan '16

14 Jan '16

Hi list, during my gtphub development, I marked numerous commits as Sponsored-by: On-Waves ehi which is wrong. The ehi should have been ehf: Sponsored-by: On-Waves ehf It's in the history now, so unless we rebase kazillion of commits on openbsc master, the ehi is gonna stick. So ... why didn't any reviewer catch that a bit sooner? ;) Opinions welcome. And thanks, ☭, for spotting this, at last! ~Neels -- - 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: Holger Freyther, Harald Welte

1 0

Using Gerrit for libosmocore/lib../OpenBSC?
by Holger Freyther 11 Jan '16

11 Jan '16

Hi, I like code-review around mailinglists (mostly everybody can read and learn from comments or code), it shows that people collaborate and that we move forward. What I don't like about the current workflow is that we need to manually close things in patchwork after applying/rejecting/ignoring a patch and that to see if it compiles and works are done after the review and by the person that applies the changes. In other projects I have used Gerrit and besides it being a Java monster found it quite okay to use. One strength is that one can directly push the changes for a branch for review, the other is that Jenkins and Gerrit can collaborate. This means that after a commit is pushed make, make check, make distcheck can be executed. Comments will always be attached to a line and not be lost due me quoting and removing parts of the mail. What I am not sure about: * How do the email notifications look like? E.g. do we just get a "Somebody has commented" mail or do we get diff + comment sent here? In OpenOCD I see there is an email with the diff[1] but no mail with the comments. * Shall we support direct pushes? I think specially in the beginning we should but the branch name for that would change. * A change that impacts libopenbsc+OpenBSC is difficult to represent. It would break "the" build but I don't see any other way. Is there enough consensus to give it a try? holger [1] http://sourceforge.net/p/openocd/mailman/message/34646766/

5 5

How to test the debian packages?
by Holger Freyther 07 Jan '16

07 Jan '16

Good Morning, Max has brought up the topic of somehow testing the debian packages and I wonder what aspects we need to test it. Ideally we would test: (a) Building a new version of everything against the last packages we have built to find wrong minimum versions. (b) Create source packages and build everything. (c) Try to upgrade services and check something is respawned and the config file is compatible. (a) is a complicated mess. We do add new interfaces, versions to the development version of libraries and we don't want to bump the SO_VERSION and such until we make a release. So this item will always break. (b) Is quite easy. When making a release we should open the changelog with version+1 and not being released and then make nightly source packages and upload them to the OpenSUSE build service and see how it fails. (c) Is possible but a bit tricky again. We need to do this for each service (e.g. nitb and bsc share the same VTY, OML, RSL port and are mutual exclusive). Max is probably aiming for (b) and I think it is not that needed. I tend to make releases and build packages and the breakage is quite small from release to release. I think there would be real value in (c) but that requires some work that we will probably not have time for in Q1. holger

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC January 2016