OpenBSC July 2019

openbsc@lists.osmocom.org

17 participants
22 discussions

libosmocore for multi-threaded software
by Rafael Diniz 24 Jul '19

24 Jul '19

Hi all, I'm writing some tools for using with HF radio and SDR modems [1], and I'm using multi-threaded architecture. Do you know the status and/or which branch should I use of libosmocore in a multi-threaded application? Regards, Rafael Diniz [1] https://github.com/DigitalHERMES/rhizo-uuardop

2 1

OpenBSC inquiry
by tyler wood 24 Jul '19

24 Jul '19

Good evening, My name is Tyler Wood, I was wondering how much yall would charge to create a dongle with OpenBSC on it and mail it to me. If I have contacted the wrong emails please let me know who I need to contact. Thank you for your time. Very Respectfully, Tyler Wood

2 1

Re: CS Fallback in NextEPC
by Rafael Diniz 19 Jul '19

19 Jul '19

Obrigado Romeu! On 7/19/19 4:58 PM, Romeu Medeiros wrote: > Hello Rafael > > I just configure the NextEPC to connect via SGS to OSMO-MSC, like this: > > sgsap: > addr: 127.0.0.1 > port: 29118 > name: vlr.example.net <http://vlr.example.net> > tai: > plmn_id: > mcc: 724 > mnc: 21 > tac: 12345 > lai: > plmn_id: > mcc: 724 > mnc: 4 > lac: 51544 > > And the configuration in the MSC: > > sgs > local-port 29118 > local-ip 0.0.0.0 > vlr-name vlr.example.net <http://vlr.example.net> > > And configure the IMSI in the Osmo-HLR and NextEPC-HSS > > If you need more help tell me. > > > Thanks > > Romeu Medeiros > > > And > > On Fri, Jul 19, 2019 at 1:31 PM Rafael Diniz <rafael(a)rhizomatica.org > <mailto:rafael@rhizomatica.org>> wrote: > > Hi all, > > I'd also like to test SMS and CSFB in LTE. I have some experience with > the Osmocom GSM stack, but not much with the NextEPC LTE. Could you > point me which fields should I set in the configuration files? > > Thanks, > Rafael Diniz > > On 7/13/19 6:35 PM, Romeu Medeiros wrote: > > Hello Sukchan and friends. > > > > I'm trying to use the CSFB in test lab, and every time that > nextepc send > > the UEContextModificationRequest, the UE respond with an > > UEContextModificationFaliure [ Protocol-cause=semantic-error ]. > > > > image.png > > > > I'm looking why I'm getting this. Someone have any idea? > > > > Thanks > > > > Romeu Medeiros > > > > On Thu, Jul 11, 2019 at 12:15 PM Sukchan Lee <acetcom(a)gmail.com > <mailto:acetcom@gmail.com> > > <mailto:acetcom@gmail.com <mailto:acetcom@gmail.com>>> wrote: > > > > Dear Osmocom & NextEPC Community, > > > > Today I've added CS Fallback and released NextEPC v0.5.0 > > > > So, I'd just like to test this part with Osmocom project, but it > > seems to be a difficult task. The reason is why I have little > > knowledge about 2G/3G. Nevertheless, I will try to do it > > > > BTW, I don't know if there is anyone who wants to integrate > this big > > thing. > > Even though I'm not sure if this will help, but let me > introduce the > > configuration of the NextEPC. > > > > To use SGsAP, change the mme.conf as follows: > > > > # > > # <sgsap> > > # > > # o Single MSC/VLR > > # sgsap: > > # addr: 127.0.0.2 > > # plmn_id: > > # mcc: 001 > > # mnc: 01 > > # tac: 4130 > > # lac: 43690 > > # > > # o Multiple MSC/VLR > > # sgsap: > > # - addr: 127.0.0.2 > > # plmn_id: > > # mcc: 001 > > # mnc: 01 > > # tac: 4131 > > # lac: 43692 > > # - addr > > # - 127.0.0.3 > > # - fe80::2%lo0 > > # plmn_id: > > # mcc: 001 > > # mnc: 01 > > # tac: 4132 > > # lac: 43692 > > # - name: msc.open5gs.org <http://msc.open5gs.org> > <http://msc.open5gs.org> > > # plmn_id: > > # mcc: 001 > > # mnc: 01 > > # tac: 4133 > > # lac: 43693 > > # > > > > FYI, I also attach the pcap that I run with nextepc simulator > as below. > > > > $ ./tests/testcsfb > > mo-idle-test : SUCCESS > > mt-idle-test : SUCCESS > > mo-active-test : SUCCESS > > mt-active-test : SUCCESS > > All tests passed. > > > > Feel free to raise any questions about this things. > > > > Best Regards, > > Sukchan > > >

1 0

Re: CS Fallback in NextEPC
by Rafael Diniz 19 Jul '19

19 Jul '19

Hi all, I'd also like to test SMS and CSFB in LTE. I have some experience with the Osmocom GSM stack, but not much with the NextEPC LTE. Could you point me which fields should I set in the configuration files? Thanks, Rafael Diniz On 7/13/19 6:35 PM, Romeu Medeiros wrote: > Hello Sukchan and friends. > > I'm trying to use the CSFB in test lab, and every time that nextepc send > the UEContextModificationRequest, the UE respond with an > UEContextModificationFaliure [ Protocol-cause=semantic-error ]. > > image.png > > I'm looking why I'm getting this. Someone have any idea? > > Thanks > > Romeu Medeiros > > On Thu, Jul 11, 2019 at 12:15 PM Sukchan Lee <acetcom(a)gmail.com > <mailto:acetcom@gmail.com>> wrote: > > Dear Osmocom & NextEPC Community, > > Today I've added CS Fallback and released NextEPC v0.5.0 > > So, I'd just like to test this part with Osmocom project, but it > seems to be a difficult task. The reason is why I have little > knowledge about 2G/3G. Nevertheless, I will try to do it > > BTW, I don't know if there is anyone who wants to integrate this big > thing. > Even though I'm not sure if this will help, but let me introduce the > configuration of the NextEPC. > > To use SGsAP, change the mme.conf as follows: > > # > # <sgsap> > # > # o Single MSC/VLR > # sgsap: > # addr: 127.0.0.2 > # plmn_id: > # mcc: 001 > # mnc: 01 > # tac: 4130 > # lac: 43690 > # > # o Multiple MSC/VLR > # sgsap: > # - addr: 127.0.0.2 > # plmn_id: > # mcc: 001 > # mnc: 01 > # tac: 4131 > # lac: 43692 > # - addr > # - 127.0.0.3 > # - fe80::2%lo0 > # plmn_id: > # mcc: 001 > # mnc: 01 > # tac: 4132 > # lac: 43692 > # - name: msc.open5gs.org <http://msc.open5gs.org> > # plmn_id: > # mcc: 001 > # mnc: 01 > # tac: 4133 > # lac: 43693 > # > > FYI, I also attach the pcap that I run with nextepc simulator as below. > > $ ./tests/testcsfb > mo-idle-test : SUCCESS > mt-idle-test : SUCCESS > mo-active-test : SUCCESS > mt-active-test : SUCCESS > All tests passed. > > Feel free to raise any questions about this things. > > Best Regards, > Sukchan >

1 0

SNOW-3G / ZUC implementation under FOSS license?
by Paul Sutton 16 Jul '19

16 Jul '19

Hi Harald, The srsLTE implementation is taken from the ETSI specs simulation program listings: http://cryptome.org/uea2-uia2/etsi_sage_06_09_06.pdf and http://cryptome.org/uea2-uia2/snow_3g_spec.pdf https://www.etsi.org/intellectual-property-rights#mytoc3 and https://www.etsi.org/images/files/IPR/etsi-ipr-policy.pdf outline the copyright licensing details for software incorporated in ETSI standards however I have not taken legal advice on compatibility of this license with AGPLv3. >From a quick review, it looks like the CryptoMobile and NextEPC versions have taken the same approach. It would be good as you say to have a "clean copyright" implementation - perhaps this is something we could help with. Best regards, Paul > Hi! > > I'm now at a point where I would like to add SNOW-3G (EIA1/EEA1) support for > NAS integrity protection and ciphering to my upcoming TTCN-3 testsuite for the MME. > > However, it seems there is no real FOSS implementation of the SNOW-3G algoritm > around? All I could find was: > > * https://github.com/mitshell/CryptoMobile with unclear source of the code, > without a copyright statement or license annotation > > * https://github.com/rcatolino/libressl-snow3g/blob/master/crypto/snow3g/main… > without a copyright statement or license annotation > > * https://github.com/Jadson27101/SNOW_3G in go, > without a copyright statement or license annotation > > * https://github.com/KsirbJ/SNOW-3G > without a copyright statement or license annotation > > * https://github.com/open5gs/nextepc/blob/master/src/mme/snow-3g.c > without a copyright statement or license annotation. Looks rather similar > to CryptoMobile. Possible just copy+pasted from ETSI reference implementation? > > * https://github.com/srsLTE/srsLTE/blob/master/lib/src/common/snow_3g.cc > also contains no coypright statement or license, but might be construed > to be AGPLv3 like all of srsLTE. However, it states it is "adapted" > from ETSI/SAGE specifications. Does that mean it is an independent > implementation of the algorithm by just reading the specs, or does it > contain actual ETSI-copyrighted code? > > It's also odd that the 3GPP specs (35.215 / 35.216, with usual copyright statement) > don't contain any actual information but all just point to the ETSI SAGE specification > which can be found (at the very least) here: > https://www.gsma.com/aboutus/wp-content/uploads/2014/12/uea2uia2d1v21.pdf > and interestingly doesn't contain any copyright statement whatsoever. > > This discussion is not about any potentially 'essential patents' that may or may > not apply in some jurisdictions on the algorithm itself. I'm currently only interested > in a "clean copyright" implementation of any of the EIA/EEA implementations used > on the LTE NAS layer. > > I'd appreciate any useful comments. Thanks! > > -- > - Harald Welte <laforge at gnumonks.org <https://lists.osmocom.org/mailman/listinfo/openbsc>> http://laforge.gnumonks.org/ > ============================================================================ > "Privacy in residential applications is a desirable marketing option." > (ETSI EN 300 175-7 Ch. A6) -- ________________________________________________________________ Paul Sutton Ph.D. Software Radio Systems (SRS) http://www.softwareradiosystems.com paul(a)softwareradiosystems.com PGP Key ID: 3B4A5292 Fingerprint: B0AC 19C9 B228 A6EB 86E1 82B2 90C7 EC95 3B4A 5292 ________________________________________________________________

2 1

CS Fallback in NextEPC
by Sukchan Lee 13 Jul '19

13 Jul '19

Dear Osmocom & NextEPC Community, Today I've added CS Fallback and released NextEPC v0.5.0 So, I'd just like to test this part with Osmocom project, but it seems to be a difficult task. The reason is why I have little knowledge about 2G/3G. Nevertheless, I will try to do it BTW, I don't know if there is anyone who wants to integrate this big thing. Even though I'm not sure if this will help, but let me introduce the configuration of the NextEPC. To use SGsAP, change the mme.conf as follows: # # <sgsap> # # o Single MSC/VLR # sgsap: # addr: 127.0.0.2 # plmn_id: # mcc: 001 # mnc: 01 # tac: 4130 # lac: 43690 # # o Multiple MSC/VLR # sgsap: # - addr: 127.0.0.2 # plmn_id: # mcc: 001 # mnc: 01 # tac: 4131 # lac: 43692 # - addr # - 127.0.0.3 # - fe80::2%lo0 # plmn_id: # mcc: 001 # mnc: 01 # tac: 4132 # lac: 43692 # - name: msc.open5gs.org # plmn_id: # mcc: 001 # mnc: 01 # tac: 4133 # lac: 43693 # FYI, I also attach the pcap that I run with nextepc simulator as below. $ ./tests/testcsfb mo-idle-test : SUCCESS mt-idle-test : SUCCESS mo-active-test : SUCCESS mt-active-test : SUCCESS All tests passed. Feel free to raise any questions about this things. Best Regards, Sukchan

5 5

SNOW-3G / ZUC implementation under FOSS license?
by Harald Welte 12 Jul '19

12 Jul '19

Hi! I'm now at a point where I would like to add SNOW-3G (EIA1/EEA1) support for NAS integrity protection and ciphering to my upcoming TTCN-3 testsuite for the MME. However, it seems there is no real FOSS implementation of the SNOW-3G algoritm around? All I could find was: * https://github.com/mitshell/CryptoMobile with unclear source of the code, without a copyright statement or license annotation * https://github.com/rcatolino/libressl-snow3g/blob/master/crypto/snow3g/main… without a copyright statement or license annotation * https://github.com/Jadson27101/SNOW_3G in go, without a copyright statement or license annotation * https://github.com/KsirbJ/SNOW-3G without a copyright statement or license annotation * https://github.com/open5gs/nextepc/blob/master/src/mme/snow-3g.c without a copyright statement or license annotation. Looks rather similar to CryptoMobile. Possible just copy+pasted from ETSI reference implementation? * https://github.com/srsLTE/srsLTE/blob/master/lib/src/common/snow_3g.cc also contains no coypright statement or license, but might be construed to be AGPLv3 like all of srsLTE. However, it states it is "adapted" from ETSI/SAGE specifications. Does that mean it is an independent implementation of the algorithm by just reading the specs, or does it contain actual ETSI-copyrighted code? It's also odd that the 3GPP specs (35.215 / 35.216, with usual copyright statement) don't contain any actual information but all just point to the ETSI SAGE specification which can be found (at the very least) here: https://www.gsma.com/aboutus/wp-content/uploads/2014/12/uea2uia2d1v21.pdf and interestingly doesn't contain any copyright statement whatsoever. This discussion is not about any potentially 'essential patents' that may or may not apply in some jurisdictions on the algorithm itself. I'm currently only interested in a "clean copyright" implementation of any of the EIA/EEA implementations used on the LTE NAS layer. I'd appreciate any useful comments. Thanks! -- - 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

TITAN just gained basic CSN.1 support!
by Harald Welte 11 Jul '19

11 Jul '19

Dear all, I'm very happy to have received the below attached news via the Eclipse bugzilla. This is great, as it permits us to have "real" SI rest octet as well as RLC/MAC support in our TTCN3 test suites while still using declarative RAW codec syntax. Just to be clear there's no misunderstanding: This doesn't mean that CSN.1 syntax can be parsed by TITAN. It just means that we can use RAW codec annotations to describe something that matches the CSN.1 encoding. 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

License for our test suites
by Harald Welte 10 Jul '19

10 Jul '19

Dear Osmocom community, during recent years we have developed a quite extensive set of test suites for virtually all interfaces on all protocol levels of our 2G stack, and recently even extended at least with some 3G IuCS coverage. Those test suites are considerably valuable for testing any kind of implementation of 2G / 3G network elements, even beyond Osmocom. I'm a bit worried that they might be used to test proprietary implementations, which would bring no value to growing FOSS in mobile communications. Whether we license the test suites under GPL or AGPL doesn't actually change much here: Imagine "EvilCorp" developing a BSC, using our test suites against it. They neither distribute the test suite, nor do they provide "access over a network" to it, an hence they could keep any modifications/extensions/derivatives private without having to contribute those back. I think this is problematic. We develop those test suites because we care about having well-tested FOSS in cellular communications, whether Osmocom or other FOSS projects. I certainly don't want to spend my spare time, or invest sysmocom resources towards improving the test coverage of any non-FOSS implementations. If such users are out there, they should at the very least contribute to the development effort in one way (code) or another (funding). For 2G/3G, I think this discussion is quite theoretical, as there is unlikely anyone else implementing those old technologies in proprietary systems - Osmocom is probably typically the latest player in the market to do so. However, as I'm currently working on a first set of TTCN3 tests for testing a LTE MME (initially attacing to S1 and SGs), I'm wondering if we should continue to release related code under traditional copyleft licenses. One idea would be to have a license that permits the use of the test suites to test only FOSS software. In theory, that would mean that all projects we care about (such as currently srsLTE, nextepc, OAI EPC, ...) could use the test suites to test their software. On the other hand, if some vendor of proprietary MME/EPC software would want to [legally] use the tests, they would need to obtain a different (paid) license to the test suite. Of course they could simply ignore the license and we'd have little chance to learn about it - but I would argue most proper companies typically would obtain a license if they used some software they knew they had to license. This is a very double-edged sword. Drafting such a new license would cause license proliferation, which is always bad. It also raises quesetions of license compatibility with e.g. some of our common existing 'library' code that would need to be investigated. Finally, it also means that we'd no longer be writing "free software" nor "open source", as the respective relevant definitions always require "non discriminatory use for any purpose", which would no longer be the case here. This is currently an early stage brainstorming. Now is the right point in time to talk about this, before we release any LTE/EPC related tests. Let me know if you have any thoughts to share. While I'm cross-posting this to openbsc@ and nextepc@ lists, pleaes follow-up-to openbsc(a)lists.osmocom.org, as that's the main Osmocom mailing list and we don't have any specifically only for the test suites. -- - 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)

3 3

Enable gsmtap logging for TTCN3 testsuites?
by Oliver Smith 10 Jul '19

10 Jul '19

Dear ML, I'm wondering why we do not have gsmtap logging enabled for TTCN3 testsuites, and if there are any reasons against doing that. Personally I find it very useful to have gsmtap logs in pcap files, because then then there is no need to manually match the timestamps of the log file and interesting parts of the pcap dump. Especially in the TTCN3 testsuites, where we generate a separate pcap file for each test, but have one big log file of the SUT (e.g. osmo-hlr) for the entire testsuite run. Thoughts? Thanks, Oliver -- - Oliver Smith <osmith(a)sysmocom.de> https://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 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC July 2019