nextepc July 2019

nextepc@lists.osmocom.org

9 participants
14 discussions

Wy does the MME need a mongodb database?

by Harald Welte

Hi Sukchan and othres, I'm wondering why the MME itself is currently requiring a mongodb database? What is it used for? I'm a bit confused, I thought mongodb was only used by the HSS for subscriber storage. However, it seems that (at least with current nextepc), the MME also needs mongodb. I cannot immediately find any code that uses it? 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)

5 years, 11 months

Security research

by Holtmanns, Silke (Nokia - FI/Espoo)

Hi, I'm part of security research and we are mainly interested in the core network part and not on the UE part. What we want to do is have a PGW which has some the EPC "machinery" behind to get a TEID and have MME, HSS, SGW initialized and some not real UEs i.e. the fake UEs would sit in or next to the eNB. In the end we are interested in plugging this EPC next to a real one with a real S8 connection. We do not need real internet connection for the "fake UE" and user plane is also not that important for us. So how can we get a "fake UE" into the eNB, so that is makes all the protocol runs for data communication set-up. Any hints? Greetings silke

5 years, 11 months

License for our test suites

by Harald Welte

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)

5 years, 11 months

RE: Somebody tried this (or parts of it)

by Holtmanns, Silke (Nokia - FI/Espoo)

Maybe it goes through this time. Seems it did not make it the first time... From: Holtmanns, Silke (Nokia - FI/Espoo) Sent: Friday, July 5, 2019 12:55 PM To: nextepc(a)lists.osmocom.org Cc: Kalliola, Aapo (Nokia - FI/Espoo) <aapo.kalliola(a)nokia-bell-labs.com> Subject: Somebody tried this (or parts of it) Hi, are mainly interested in the core network part and not on the UE part. What we want to do is have a PGW which has some the EPC "machinery" behind to get a TEID and have MME, HSS, SGW initialized and some not real UEs i.e. the fake UEs would sit in or next to the eNB. We do not need real internet connection for the "fake UE" and user plane is also not that important for us. Any hints? Greetings silke

5 years, 11 months

2025

2024

2023

2022

2021

2020

2019

nextepc July 2019