OpenBSC

openbsc@lists.osmocom.org

19 participants
4282 discussions

New build.opensuse.org (OBS) project for network:osmocom
by Holger Freyther 09 Mar '16

09 Mar '16

Hi guys, while I am super happy that people move libosmocore and other libraries and projects into the distributions I think it makes sense to provide some packages ourselves as well (e.g. if we want to add Long Term Support, or make nightly builds available). The OpenSUSE folks created "network:osmocom" for us and currently both Harald and me have the necessary privileges to add packages (and probably subprojects). kind regards holger

1 0

Redmine theme
by Вадим Яницкий 09 Mar '16

09 Mar '16

Dear all, I suggest to change a stock Redmine theme to something more beautiful, for example gitmike: https://github.com/makotokw/redmine-theme-gitmike which used by srlabs.de and looks like pretty. Furthermore, the Osmocom logo will look better on light background. Opinions? С наилучшими пожеланиями, Яницкий Вадим.

5 8

patchwork "fork" at freedesktop.org/intel
by Holger Freyther 09 Mar '16

09 Mar '16

Hi guys, the three issues I have with patch work: 1.) No integration with testing (some machine could apply, build and run make check before I do) 2.) Tracking of patches and not series (we seldomly want a single patch) 3.) No feedback if something has been applied Now Intel[1] seems to have had some of the same concern because: 1.) Their patchwork has a "pull"/"stream" API to wait for changes and execute them. It is in their manual. For us this means we need to somehow figure out where the patch applies to. We can either have the discipline to put this into the subject (git send-email can do it) or we try to see which repository has the specific base commit. It also supports sending back mails with the patch result. 2.) They track series now. 3.) This seems to be unsolved. But we can probably do something ourselves with a little discipline (and in a how-to-contribute documentation). We can use the Change-Id concept that is used by Gerrit. This is a simple local hook that adds a "Change-Id: " line with a unique number. so we will probably end up hosting our own patchwork and try to get intel help/work on 3rd. Could we get a consensus how we know where to apply the patch to? kind regards holger [1] http://damien.lespiau.name/2016/02/augmenting-mailing-lists-with-patchwork.…

2 2

command for location update
by robert 08 Mar '16

08 Mar '16

Hi, Is it possible to have the virtual BTS start a location update at a specific time. In other words, can I add a command that asks all phones to request a location update at any desired time ? Best regards, Robert,

2 1

Public Osmocom User Manuals
by Harald Welte 08 Mar '16

08 Mar '16

Dear all, some of you may have already seen it on the RSS feed, on Twitter or on planet.osmocom.org[1]: sysmocom has decided that we will re-release our existing formerly sysmocom-internal User Manuals and VTY reference manuals under GNU GFDL. The hope is that with better documentation we can enable more people to use Osmocom software more easily, leading to more adoption. While those manuals are far from being complete or perfect, I had spent a lot of time in February on further polishing them for the upcoming public release. I do believe they provide a better stasting point than what all of what we had in the wiki (whether old trac or new redmine). The manuals are written in asciidoc[2], with the occasional use of mscgen[3] and graphviz[4], which I believe together are a pretty good set of tools to very efficiently and productively work on documentation, whilst focussing on actual content and not on formatting/syntax like when using docbook-xml or LaTeX. The osmo-gsm-manuals.git repository is pulled by our jenkins installation, which then builds the PDF manuals and pushes them to http://ftp.osmocom.org/docs/latest/ I seriously do hope that we will receive improvements and extensions for the manuals. As the asciidoc source is in yet another git repo, sending patches is as easy as it gets. Holger always states nobody ever contributes to manuals, and I would love to prove him wrong ;) In terms of overlapping information in the wiki and in the manuals: I'm in favor (and in the process) of removing outdated old wiki command line reference and VTY reference sections, and simply referring to the manuals instead. Please do read through the manuals and do send patches, whether it's a spelling fix, improved wording, adding missing information or fixing actual technical mistakes. In tems of further dccumentation improvements, Holger has volunteered to ensure that the Doxygen API of libosmocore is also automatically generated+pushed in a similar fashion to make it publicly web-visible. I'd also encurage everyone to contribute patches to covert those parts of libosmocore.git that don't hve doxygen annotation yet. Thanks in advance! Regards, Harald [1] http://projects.osmocom.org/news/47 [2] http://asciidoc.org/ [3] http://www.mcternan.me.uk/mscgen/ [4] http://www.graphviz.org/ -- - 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 1

[PATCH] Remove unused auth code and add comment
by Neels Hofmeyr 08 Mar '16

08 Mar '16

As commented in the code, the GSM_SECURITY_AUTH_FAILED path is never invoked by the gsm48_secure_channel() function as it is today. Note that the upcoming Iu auth will probably add a GSM_SECURITY_AUTH_FAILED status. In that case, sending a LU Reject immediately may be desirable, but arguably a bit of timeout could make life harder for auth attackers. The code removed by this patch doesn't send out a LU Reject ever, since a call to release_loc_updating_req() only releases the connection. To reject, a call to gsm0408_loc_upd_rej() would be necessary, as seen in loc_upd_rej_cb(). And finally, if _gsm0408_authorize_sec_cb() doesn't do anything about anything, the same loc_upd_rej_cb() will be run by a timeout and send a LU Reject properly (as commented in the code). --- openbsc/src/libmsc/gsm_04_08.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/openbsc/src/libmsc/gsm_04_08.c b/openbsc/src/libmsc/gsm_04_08.c index d9d7390..47f3fa7 100644 --- a/openbsc/src/libmsc/gsm_04_08.c +++ b/openbsc/src/libmsc/gsm_04_08.c @@ -340,10 +340,6 @@ static int _gsm0408_authorize_sec_cb(unsigned int hooknum, unsigned int event, int rc = 0; switch (event) { - case GSM_SECURITY_AUTH_FAILED: - release_loc_updating_req(conn, 1); - break; - case GSM_SECURITY_ALREADY: LOGP(DMM, LOGL_ERROR, "We don't expect LOCATION " "UPDATING after CM SERVICE REQUEST\n"); @@ -354,6 +350,19 @@ static int _gsm0408_authorize_sec_cb(unsigned int hooknum, unsigned int event, rc = finish_lu(conn); break; + case GSM_SECURITY_AUTH_FAILED: + /* + * gsm48_secure_channel() will pass only + * GSM_SECURITY_NOAVAIL in case of failure. If future + * code should add a GSM_SECURITY_AUTH_FAILED status in + * this code path, letting the Location Update time out + * will do all necessary error messaging and logging, + * see loc_upd_rej_cb(). + */ + LOGP(DMM, LOGL_ERROR, + "Authorization failed for subscriber %s\n", + subscr_name(conn->subscr)); + /* fall through */ default: rc = -EINVAL; }; -- 2.1.4

1 0

libosmo-sccp: branch sysmocom/iu
by Neels Hofmeyr 08 Mar '16

08 Mar '16

I've created a branch sysmocom/iu based on the laforge/wip branch currently used for 3G dev. I've added minor commits and rebased the branch onto current master. The tendency should be to use sysmocom/iu in libosmo-sccp for 3G development (and coverity @Holger). ~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

SMPP Routes
by Hendrik Schmidt 06 Mar '16

06 Mar '16

Dear all, I am currently playing around with the new SMPP feature, but struggling a bit on routing in direction of esme. Of course, when using default-route, all customers will be routed to the esme which are not in the database; but what if I just want to route specific prefixes (or single numbers?). Currently, when using "route" and some combinations of international/national prefixes, I dont get it working. Is there a documentation to this, without reading all numbering plans of gsma etc? E.g. what I want to do: - only route number 1234 via SMPP - route everything via SMPP which starts with a "1" Thanks & Best, Hendrik -- Hendrik Schmidt ERNW GmbH - Carl-Bosch-Straße 4 - 69115 Heidelberg - www.ernw.de Central Back Office Tel. +49 6221 480390 - Fax 6221 419008 - Cell +49 151 16227562 Handelsregister Mannheim: HRB 337135 Geschaeftsfuehrer: Enno Rey ======================================================= Blog: www.insinuator.net<http://www.insinuator.net/> || Conference: www.troopers.de<http://www.troopers.de/> =======================================================

2 1

Fwd: New Defects reported by Coverity Scan for Osmocom
by Holger Freyther 01 Mar '16

01 Mar '16

Hi guys, FYI after adding the do{} while and the log_check_level call coverity has found some dead code. The found_partial is a funny case of dead code. :) holger > Begin forwarded message: > > From: scan-admin(a)coverity.com > Subject: New Defects reported by Coverity Scan for Osmocom > Date: 29 February 2016 at 17:47:54 GMT+1 > To: holger(a)freyther.de > > > Hi, > > Please find the latest report on new defect(s) introduced to Osmocom found with Coverity Scan. > > 3 new defect(s) introduced to Osmocom found with Coverity Scan. > 1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent build analyzed by Coverity Scan. > > New defect(s) Reported-by: Coverity Scan > Showing 3 of 3 defect(s) > > > ** CID 70677: Control flow issues (DEADCODE) > /source-iuh/osmo-pcu/src/gprs_rlcmac_ts_alloc.cpp: 907 in alloc_algorithm_b() > > > ________________________________________________________________________________________________________ > *** CID 70677: Control flow issues (DEADCODE) > /source-iuh/osmo-pcu/src/gprs_rlcmac_ts_alloc.cpp: 907 in alloc_algorithm_b() > 901 dl_slots, 'D'), > 902 single ? ", single" : ""); > 903 > 904 /* assign downlink */ > 905 if (dl_slots == 0) { > 906 LOGP(DRLCMAC, LOGL_NOTICE, "No downlink slots " >>>> CID 70677: Control flow issues (DEADCODE) >>>> Execution cannot reach this statement "do { > if (log_check_level...". > 907 "available\n"); > 908 return -EINVAL; > 909 } > 910 slotcount = pcu_bitcount(dl_slots); > 911 first_ts = ffs(dl_slots) - 1; > 912 avail_count = pcu_bitcount(reserved_dl_slots); > > ** CID 70676: Control flow issues (DEADCODE) > /source-iuh/libosmo-netif/src/rtp.c: 124 in osmo_rtp_get_payload() > > > ________________________________________________________________________________________________________ > *** CID 70676: Control flow issues (DEADCODE) > /source-iuh/libosmo-netif/src/rtp.c: 124 in osmo_rtp_get_payload() > 118 return NULL; > 119 } > 120 } > 121 if (rtph->padding) { > 122 if (payload_len < 0) { > 123 DEBUGPC(DLMUX, "received RTP frame too short for " >>>> CID 70676: Control flow issues (DEADCODE) >>>> Execution cannot reach this statement "do { > if (log_check_level...". > 124 "padding length\n"); > 125 return NULL; > 126 } > 127 payload_len -= payload[payload_len - 1]; > 128 if (payload_len < 0) { > 129 DEBUGPC(DLMUX, "received RTP frame with padding " > > ** CID 70675: Control flow issues (DEADCODE) > /source-iuh/libosmo-netif/src/channel.c: 57 in osmo_chan_create() > > > ________________________________________________________________________________________________________ > *** CID 70675: Control flow issues (DEADCODE) > /source-iuh/libosmo-netif/src/channel.c: 57 in osmo_chan_create() > 51 LOGP(DLINP, LOGL_ERROR, "unsupported channel type `%s'\n", > 52 cur->name); > 53 return NULL; > 54 } > 55 if (found_partial) { > 56 LOGP(DLINP, LOGL_ERROR, "Sorry, channel type `%s' does not " >>>> CID 70675: Control flow issues (DEADCODE) >>>> Execution cannot reach this statement "do { > if (log_check_level...". > 57 "support subtype `%u'\n", cur->name, subtype_id); > 58 return NULL; > 59 } > 60 > 61 c = talloc_zero_size(osmo_chan_ctx, > 62 sizeof(struct osmo_chan) + cur->datasiz); > > > ________________________________________________________________________________________________________ > To view the defects in Coverity Scan visit, https://scan.coverity.com/projects/osmocom?tab=overview > > To manage Coverity Scan email notifications for "holger(a)freyther.de", click https://scan.coverity.com/subscriptions/edit?email=holger%40freyther.de&tok… >

1 0

milestone: 3G CS Location Update Accept
by Neels Hofmeyr 01 Mar '16

01 Mar '16

Hi list, I've just seen my first Location Update Accept from our UMTS UE+femtoCell using osmo-cscn as IuCS network core :D The Identity Request (IMSI) that the UE used to not answer is now being answered, and I am getting a successful Location Update Accept from osmo-cscn after that. The reason why it didn't work last time isn't entirely clear. All I changed since is the *test* program that simulates the UE+hNodeB, and I merely verified that osmo-cscn works (as far as LU is concerned). A hint is, Daniel told me that the IuPS setup had one day stopped to reply with a message that used to work before, and has since again started working. So it might've been a timing issue in the reply towards UE. Next steps: Next I will briefly try to run Daniel's 3G SGSN together with CSCN to see whether the premature Iu Release (?) he sees still happens when CS is connected successfully. There is also still a segfault in osmo-hnbgw, triggered by reconnecting a second time with our hnb-test that simulates an hNodeB. That's next on the hacking todo list. According to the specs, proper Authentication is mandatory for UMTS, which osmo-cscn should initiate. That's not happening yet. It seems our testing UE is fine with that, so I'll see when I'll get to that. ~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 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC