OpenBSC November 2017

openbsc@lists.osmocom.org

21 participants
49 discussions

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

osmo-bsc access lists semantics are confusing
by Neels Hofmeyr 10 Nov '17

10 Nov '17

I'm just now looking through osmo-bsc libfilter, and I would have expected a kind of top-down behavior like for firewalls: imsi-deny .* imsi-allow 12345.* imsi-deny 1234567.* imsi-allow 123456789.* imsi-deny .*[13579] i.e. start out denying everything. Except allow IMSIs starting with 12345. Except deny those that continue with 67. Unless they continue with 6789, allow those. Finally only service even-numbered IMSIs here. That would be quite powerful. Instead, what I see is that first, we go through the entire access list regarding only the allow-imsi entries. If any one of them matches, break the loop and return acceptance *right away*. If no accept rule matched, go through the list again, and see if any deny rule matches. If there is one, break and return failure right away. This was for the "local" per-msc rules, we also have a "global" rule set on the bsc level, which follows after that. For that, we currently actually completely ignore all allow rules, and only return error if any deny rule matches. In the end, if nothing matched, return acceptance. A code comment says that for the "global" rules, we want to deny first and accept second, so precisely reverse from the "local" level, but as a user I would find that rather confusing. See auth_imsi() in bsc_msg_filter.c. So in short, to get the intended behavior outlined above, you are forced to cram all rules into a single regex, sort of like imsi-allow 12345$<not>67\|6789$.*[02468] imsi-deny .* which I don't actually know how to express as you can see... or maybe imsi-allow 12345[^6].*[02468] imsi-allow 123456[^7].*[02468] imsi-deny .* My questions are: - Is it implemented this way for performance considerations? - Are we not going to change this, even assuming that we regard changes being useful, because we don't want to break with previous configs? - When looking in auth_imsi(), the access list names are: auth_imsi() name | comments | osmo-bsc passes bsc_lst "local" vty 'msc' level access rules nat_lst "global" vty 'bsc' level access rules Needless to say that "local", "global", "nat", "bsc" and "msc" are quite hard to follow. From the osmo-bsc filter code's perspective, there may be multiple MSCs configured, and per-msc config could be seen as more specific ("local") than bsc level, which applies to all MSCs ("global")... Was that the intention or is the local/global actually swapped by accident? (I notice that this feature seems to be intended for osmo-bsc-nat, and there's also a concept of a super-global blacklist that is always NULL in osmo-bsc.) Here's a patch to add imsi-allow evaluation on the "global" level; other than the comment says, I use the same order of 'allow' first and 'deny' second to be consistent: https://gerrit.osmocom.org/4750 Otherwise I believe this could benefit from some refactoring, but probably we don't have time/funding to care about that, do we... ~N

2 2

OsmoBSC now *requires* an OsmoMGW to run alongside it
by Neels Hofmeyr 09 Nov '17

09 Nov '17

There has been a profound change in RTP handling by OsmoBSC: we now require an OsmoMGW to run alongside it to manage RTP streams, and to be able to provide intra-BSC handover. Kindly refer to https://osmocom.org/news/80 ~N

2 1

GPRS EXperiments
by Keith 08 Nov '17

08 Nov '17

Hi List! As there isn't so much about GPRS on here, I though I might write something about experiments over the last couple of weeks with data inside and outside of the lab. I've installed up to date versions of osmo-bts and osmo-pcu on sysmobts 2050 hardware and it's working great! Dynamic channels are really nice, with half rate TCH and AMR working perfectly. Thanks for all that work! The question for this experiment was if it was going to be feasible to actually do anything with several hundred data hungry spying devices.... I mean mobile phones on the network. For the traffic control, I setup a local blacklisting or whitelisting dns server. I've tried both. Blacklisting the worst culprits would be nice, but in practice I think I'll have to go for whitelisting only the intended permitted services. I configured pcodns1 in the ggsn to point to this DNS server, AND I setup a port 53 redirect to catch quite a lot of traffic from android that likes to just talk directly to 8.8.8.8 anyway. In the wild, some dns request analysis reveals the worst culprits (this is a very basic analysis) appear to be all the google update stuff, play store etc, facebook iCloud, (all to be expected) , and certain CDNs. Some research shows that these CDN companys specialize in delivery of advertising content inside apps such as mobile platform games. Such is the sad state of affairs on today's internet. Fortunately, we have iptables and ip sets and we have AS blocks assigned to certain bandwidth hungry corporations :-) So turns out it seems quite feasible to supply service for text messages with certain popular IM services to many phones. Short voice clips worked quite well in the lab tests, although support for media such as pictures and videos was not so great. I have yet to successfully send an image (sourced via device camera within the app) over a "secret" chat with Telegram messenger. As this is not a very low level report, rather intended as some light reading :) I also have a question in a similar light vein. I'm still getting to grips with the log messages available in the pcu , the sgsn and not so much the ggsn, and I'm observing and learning the sequence of events, so at some point I should be able to present a better report about this with some relevant traces and better analysis. For now, In the lab tests I am constantly monitoring the RF uplink; I observe that a phone will attach and then go quiet. A foreground running app may report that it is "connecting" or some such, and the little arrows may be flashing to show that apparently we are transmitting data, but there is nothing on the uplink. My guess here is the OS has sent something and the baseband is saying yes yes doing it.. but the baseband at the same time is waiting for something from the network (and not getting it)? This situation can persist for some time.. several minutes. I have observed that if I initiate any data transfer from the network side then the uplink is established. By the same token, If I transfer a file from the network (http download or some such), the same applies. The link stays active and the IM chat session is very responsive alongside the file transfer. Shortly after the file transfer completes, the uplink is quiet again and the latency in the IM session becomes a problem. >From a UX point of view.. Let me put it this way.. I can start an IM chat, send a message.. but then we get to this quiet uplink sitation and the messages stop sending.. so from the user's point of view it's frustrating. the phone looks like it's transmitting.. until there are timeouts and disconnections and the app may show some indication to the user that it is having trouble connecting to the network. However if I run something on the network side like a script that sends one ping to the phone every ten seconds, this keeps the connection 'alive' and the IM session is much more satisfactory for the user. I should note I believe I observe this also on commercial networks in some places like certain Berlin U-bahn stations where you can still find (only) GPRS data coverage. Also, a more scientific report is needed, but I seem to observe some phones behaving "better" than others, as in being a little more active on the uplink. Maybe it is related to power saving configuration? The not very low level and scientific question here is: Is this kind of thing tunable with gprs parameters? Any tips on which ones to play with? ( Quite happy to wait until I can send a more useful report too! ) Thanks! Keith.

2 3

Range of "ipa unit-id" site_id vty config
by Pau Espin Pedrol 08 Nov '17

08 Nov '17

Hi, I see the range for ipa unit-d site_id range of values is 0-65534 as configured in the VTY: osmo-bts/src/common/vty.c 397: "ipa unit-id <0-65534> <0-255>", However, being it a uint16_t having 2^16=65536 values, I would expect the range to be 0-65535 (finished in 5, not 4). The only reason I can think of is that the last address is somehow reserved and must not be used. Does somebody know if that's the case? I couldn't find any documentation and as far as I can tell our code doesn't seem to handle the site_id=65535 case specially. If it is not reserved, then I can send a patch to change the range to be 0-65535. I actually see the same range pattern in lots of places around osmocom vty parameters, which makes me think somebody may have initially introduced the wrong number and then people have been copy-pasting the same number over and over again when adding new parameters: $ ag "0-65534" libosmocore/src/gb/gprs_ns_vty.c 269: "nse <0-65535> nsvci <0-65534>", libosmo-sccp/src/osmo_ss7_vty.c 420: "listen " XUA_VAR_STR " <0-65534>", 442: "no listen " XUA_VAR_STR " <0-65534>", osmo-sgsn/src/gprs/gb_proxy_vty.c 149: "sgsn nsei <0-65534>", 364: "secondary-sgsn nsei <0-65534>", 532: "delete-gbproxy-peer <0-65534> bvci <2-65534>", 553: "delete-gbproxy-peer <0-65534> (only-bvc|only-nsvc|all) [dry-run]", 626: "delete-gbproxy-link <0-65534> (tlli|imsi|sgsn-nsei) IDENT", 698: "delete-gbproxy-link <0-65534> (stale|de-registered)", osmo-bsc/src/libbsc/bsc_vty.c 1850: "ip.access unit_id <0-65534> <0-255>", openbsc/openbsc/src/libmgcp/mgcp_vty.c 294: "bind port <0-65534>", 337: "rtp bts-base <0-65534>", 350: "rtp bts-range <0-65534> <0-65534>", 360: "rtp net-range <0-65534> <0-65534>", 370: "rtp net-base <0-65534>", 378: "rtp base <0-65534>", 383: "rtp transcoder-range <0-65534> <0-65534>", 393: "rtp transcoder-base <0-65534>", 596: "number endpoints <0-65534>", 755: "transcoder-remote-base <0-65534>", 1119: "tap-call <0-64> ENDPOINT (bts-in|bts-out|net-in|net-out) A.B.C.D <0-65534>", openbsc/openbsc/src/libbsc/bsc_vty.c 1803: "ip.access unit_id <0-65534> <0-255>", osmo-mgw/src/libosmo-mgcp-client/mgcp_client_vty.c 130: "mgw bts-base <0-65534>", 140: "mgcpgw bts-base <0-65534>", osmo-mgw/src/libosmo-legacy-mgcp/mgcp_vty.c 294: "bind port <0-65534>", 337: "rtp bts-base <0-65534>", 350: "rtp bts-range <0-65534> <0-65534>", 360: "rtp net-range <0-65534> <0-65534>", 370: "rtp net-base <0-65534>", 378: "rtp base <0-65534>", 383: "rtp transcoder-range <0-65534> <0-65534>", 393: "rtp transcoder-base <0-65534>", 606: "number endpoints <0-65534>", 765: "transcoder-remote-base <0-65534>", 1130: "tap-call <0-64> ENDPOINT (bts-in|bts-out|net-in|net-out) A.B.C.D <0-65534>", osmo-mgw/src/libosmo-mgcp/mgcp_vty.c 264: "bind port <0-65534>", 297: "rtp net-range <0-65534> <0-65534>", 509: "number endpoints <0-65534>", 947: "tap-rtp <0-64> ENDPOINT CONN (in|out) A.B.C.D <0-65534>", osmo-bts/src/common/vty.c 397: "ipa unit-id <0-65534> <0-255>", Regards, -- - Pau Espin Pedrol <pespin(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

3 4

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC November 2017