OpenBSC November 2017

openbsc@lists.osmocom.org

21 participants
43 discussions

osmo-mgw endpoint allocation
by Harald Welte 20 Nov '17

20 Nov '17

Hi all, we recently had some (verbal) discussions on how to handle endpoint allocations in a scenario where a single osmo-mgw shall be used by both osmo-bsc and osmo-msc (in a "NITB style" setup). There was some thinking about whether we should somehow divide fixed ranges of the rtp-bridge endpoints between the BSC and the MSC and how to avoid having to manually configure those. I think I now found the proper solution for this: The call agent must not even fully qualify the endpoint, but it can ask the MGW to allocate one! To quote from the MGCP RFC: EndpointId is the identifier for the connection endpoint in the gateway where CreateConnection executes. The EndpointId can be fully-specified by assigning a value to the parameter EndpointId in the function call or it may be under-specified by using the "any of" wildcard convention. If the endpoint is underspecified, the endpoint identifier SHALL be assigned by the gateway and its complete value returned in the SpecificEndPointId parameter of the response. When the "any of" wildcard is used, the endpoint assigned MUST be in- service and MUST NOT already have any connections on it. If no such endpoint is available, error code 410 (no endpoint available) SHOULD be returned. The "all of" wildcard MUST NOT be used. So in our concrete example, the BSC (or MSC) could simply ask for "rtpbridge/*@mgw" as end-point name in CRCX, and the MGW would then dynamically allocate a suitable free rtpbridge endpoint type and return it in the call agent in the BSC (or MSC). No shared knowledge about endpoint number allocations / ranges or the like required. Now we only need to implement this in osmo-mgw ;) Related: https://osmocom.org/issues/2631 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)

2 2

simtrace at use
by Max 20 Nov '17

20 Nov '17

Hi. I've stumbled upon awesome hack which seems to be relevant: https://ha.cking.ch/s8_data_line_locator/ It uses Simtrace to check how hw implant communicates with its sim. The guy also tried to sniff GPRS traffic but failed (because he've used OpenBTS, he-he :) - I wonder if it would work better with OsmoBTS. Anyone else played with similar device already? -- 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

news for sanitizer builds
by Neels Hofmeyr 19 Nov '17

19 Nov '17

I recently found sanitizer build failures, for example in libosmocore, which our gerrit build job doesn't catch. At first I thought something was amiss and maybe our gerrit sanitizer build were broken. Instead, it turns out my debian9 gcc -fsanitize=address -fsanitize=undefined finds many more issues that the debian8 one does not. https://jenkins.osmocom.org/jenkins/job/gerrit-libosmocore/36/a2=default,a3… I already have a long series for mem leak fixes for libosmocore, mostly in the regression testing code, but I count three real mem leak fixes in libosmocore production code. My plan is to merge the fixes and then actually move the libosmocore-gerrit to debian 9 (or at least add debian 9) to make sure we don't add insanities that the debian 9 build would find. See https://gerrit.osmocom.org/4861 to https://gerrit.osmocom.org/4875. I'm also taking a look at the other CellNet builds. The root motivation was to find out why osmo-hnbgw doesn't work for me anymore currently. ~N

3 3

osmo_fsm timer_cb fudge up
by Neels Hofmeyr 18 Nov '17

18 Nov '17

I'm finding heap use after free related to osmo_fsm: - When dispatching a timer_cb event, we want to set fi->T back to 0. (see fsm_tmr_cb()) - So that we know which timer fired, we leave fi->T at its current value for the timer_cb to be able to make decisions based on that. This is used for example in fsm_timeout_cb() in osmo-bsc/osmo_bsc_mgcp.c. - In other code, the timer_cb event may decide to fire events or call functions which effect an FSM instance teardown and deallocation, meaning that in fsm_tmr_cb(), we are *not* allowed to generally assume the fi still exists. If we set fi->T = 0 after the timer_cb() was called, we may write to freed mem. - Also, if the timer_cb effects events with their own timeout, we will also overwrite the fi->T value with zero after another timer has set its value in T, causing failures to evaluate that timer later on. Solutions so far: - set fi->T = 0 first, and pass T to the timer_cb as arg instead. I think this is the best and cleanest, but also the hardest in terms of backwards compat. I have a patch that adds timer_cb2() that features a T arg; we need to submit that, move all code that wants to use T to that timer_cb2(), and then we can move the fi->T = 0 to before the timer_cb(). Actually, this is not being backwards compatible at all, because all code trying to use fi->T as usual will need adjustment, we break API either way and might as well add T to the timer_cb directly instead... :/ - Actually not set fi->T = 0 at all. We will have T holding the value of the timer that fired last, all old code will still find this T in fi->T, and after the cb, we just leave it as it was. Does it really need to be cleared? This has no compatibility issues and solves the use after free as well as setting a new T from timer_cb() issues. Going for this one so far. Thoughts? ~N

1 0

2G and 3G authentication
by Radiarisainana Sitraka 18 Nov '17

18 Nov '17

hello, needs helps for some question : is it possible to use 2g authentication for having 3g data interconnection with osmo-iuh !?

2 1

3G AUTHENTICATION
by Radiarisainana Sitraka 18 Nov '17

18 Nov '17

Hello,Simple curiosity, it's possible to use authentication 2G and having data interconnection 3G with osmo-iuh !? Chears,

1 0

[libosmo-sccp 0.8.1.16-b393] testsuite: 4 5 failed
by ouattara jean yves 18 Nov '17

18 Nov '17

Hello, I'm trying to build openbsc for 2g from this : http://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source <http://osmocom.org/projects/cellular-infrastructure/wiki/Build_from_Source>Thank you for your work. At the "make check" of libosmo-sccp, 2 tests failed. Can you help me fix that please ? Sincerely, Jean Yves OUATTARA

2 1

build failures
by Neels Hofmeyr 12 Nov '17

12 Nov '17

I am receiving a lot of build failure mails every day for quite a while now ... not finding any time to look at them, I hope you guys are onto those? ~N

2 2

Running osmo-bsc-sccplite with osmo-msc
by Harald Welte 12 Nov '17

12 Nov '17

Dear Osmocom Community, I've spent some time the least few days to handle SCCPlite in osmo-stp, and to do some initial testing of interoperability of osmo-bsc-sccplite with osmo-msc. The result are a few commits to osmo-sccp.git and openbsc.git which I'll push into gerrit as soon as I'm on land again (sitting in an airplane right now). Once those commits are merged, we can run osmo-bsc-sccplite with osmo-msc via osmo-stp. Why is this needed? While we don't want to see or support any new osmo-bsc-sccplite deployments, we still have existing users that we need to continue to support. Supporting them is easier if we can test it better, and as Osmocom now has a MSc, it would be logical to have some [manual, automatic] testing setups this way. It also means that we hopefully can create testing setups for osmo-bsc_nat, which could so far only be tested (like osmo-bsc-sccplite) with live access to a "real" MSC at an operator. Right now, this of course only handles signaling, i.e. we should be able to test LU, SMS and call signaling, including hand-over. Voice stream handling between SCCPlite and M3UA-AoIP is unfortunately quite different and will need further code in osmo-msc as well as osmo-stp. But still this should be rather straight-forward as a later next step for full interoperability. == How to configure this === osmo-bsc-sccplite side On the osmo-bsc-sccplite side, the config file looks like this ---- msc dest 127.0.0.1 5000 0 <1> token mahlzeit <2> ---- <1> the IP address and port must be the IP:Port of where osmo-stp listens for IPA <2> this 'token' must be identical to the AS configured on osmo-stp === osmo-stp side On the osmo-stp side, the config file looks like this: ---- cs7 instance 0 xua rkm routing-key-allocation dynamic-permitted as mahlzeit ipa <1> routing-key 0 0.23.4 <2> point-code override dpc 0.23.1 <3> route-table system listen m3ua 2905 accept-asp-connections dynamic-permitted listen ipa 5000 <4> accept-asp-connections dynamic-permitted ---- <1> This defines an AS with the name 'mahlzeit' matching the osmo-bsc-sccplite token <2> The point-code on the BSC side is set to 0.23.4 <3> The point-code of the MSC side is set to 0.23.1 (the compile-time default of osmo-msc) <4> Bind IPA protocol to TCP port 5000 Please note that no point code information is configured on the BSC side in the case of SCCPlite. The SCCP calling/called party address in SCCPlite don't contain a PC but only SSN, and there is no M3UA/MTP3 label with point code information either. Hence, OsmoSTP will insert the point code information into both the SCCP level as well as the stp-internal routing label of each message. The MSC will receive a SCCP message with PC+SSN in a M3UA message with OPC and DPC in a way that enables the STP to route any responses back to the BSC. If you have multiple osmo-bsc-sccplite in such a configuration, they will all need to have a different point code, just like an AoIP speaking osmo-bsc. The difference is only that in SCCPlite the point-codes are configured on the STP side, while in the AoIP they are configured on the BSC side. === osmo-msc side No special configuration is required on osmo-msc at this point. In order to properly handle voice channels, we likely have to introduce some additional per-BSC configuration statements at a later point. 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)

2 2

SGSN rejects GMM Attach if HLR has the subscriber but no auth tokens
by Neels Hofmeyr 11 Nov '17

11 Nov '17

I found the interesting situation while trying to find the minimal network-in-the-box installation with the new split components: For CS, the MSC/VLR happily accept a subscriber that has no auth tokens in the HLR, as long as the IMSI is present in the HLR and authentication is set to optional. For PS, the SGSN on auth policy remote naturally asks the HLR for auth tuples for the subscriber. The HLR then finds the IMSI allright, but no 2G nor 3G auth tokens, and says so to the SGSN. That leads to total rejection: HLR: DLINP <0006> ../../../src/libosmo-abis/src/input/ipa.c:383 connected read/write DLINP <0006> ../../../src/libosmo-abis/src/input/ipa.c:338 message received DAUC <0003> ../../../src/osmo-hlr/src/db_auc.c:127 IMSI='901700000014701': No 2G Auth Data DAUC <0003> ../../../src/osmo-hlr/src/db_auc.c:163 IMSI='901700000014701': No 3G Auth Data SGSN: <000f> ../../../../src/osmo-sgsn/src/gprs/gprs_subscriber.c:493 SUBSCR(901700000014701) GPRS send auth info req failed, GMM cause = 'Network failure' (17) <0002> ../../../../src/osmo-sgsn/src/gprs/sgsn_auth.c:236 MM(901700000014701/ccb050ce) Missing auth tuples, authorization not possible <0002> ../../../../src/osmo-sgsn/src/gprs/gprs_gmm.c:1140 MM(901700000014701/ccb050ce) Not authorized, rejecting ATTACH REQUEST with cause 'Network failure' (17) <0002> ../../../../src/osmo-sgsn/src/gprs/gprs_gmm.c:491 MM(901700000014701/ccb050ce) <- GPRS ATTACH REJECT: Network failure It appears that in the SGSN, I either have to accept all IMSIs or also have auth tokens for each IMSI in the HLR. There's apparently no way to just accept IMSIs (without cryptographic auth) as long as the IMSIs exists in the HLR. In production networks, we usually have auth tokens for each SIM, but in open / community networks, IIUC operating without auth+ciph is an important option in Osmocom. It appears to me that we should support this case. Or do we already support it by issuing accept-all policy, and rely on the subscriber being rejected by the MSC before establishing GMM? (In that case we can't use the HLR at all, i.e. not for other IMSIs where we'd know auth tokens.) What do you guys think? Should we open an issue on it? Related: I'm often confused by the SGSN auth code and have wished before that it were a well-defined FSM instead... like the libvlr... ~N

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2017