OpenBSC

openbsc@lists.osmocom.org

10 participants
4172 discussions

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)

6 years, 1 month

Enable gsmtap logging for TTCN3 testsuites?

by Oliver Smith

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

6 years, 1 month

Missing git tags in osmo-pcap

by Pau Espin Pedrol

Hi Holger, I was planning to add osmo-pcap recipes to meta-telephony soon, and first of all I wanted to make a new release since last tag (0.0.6) looked quite old. But then I found in debian/changelog that actually a lot of new releases exists, but their git tags are missing in the osmo-pcap git repository. So after making sure I updated my tag list from the server (gerrit). I got: $ git tag 0.0.1 0.0.2 0.0.3 0.0.4 0.0.5 0.0.6 but according to git log from debian/changelog, releases 0.0.7-0.0.11 do exist. Interestingly, tags 0.0.5 and 0.0.6 point to the same commit. Commits adding new releases without tags, see for instance: a316c9394aa27d25b3d7fba004563890a43ab1bc (0.0.7 added) fbdcf593f80d4fe5330376674136fd76fcef5ea2 (0.0.8 added c016b5d3824923c2b35c67cfb9930a30e564f07e (0.0.9 added) fdebd88059df3a8f717614548dcd7247e8890f9a (0.0.10 added) 17f5b005066a15312525e53e7b4a574d40011f96 (0.0.11 added) 4776b2972e84ef75b3a1c884da19604d87fc7f68 (a new commit added to 0.11 section?) So, I want to ask if there's some explanation for those tags missing or you simply forgot to push them when creating the releases (or they got somehow lost in the server). Do you happen to have the tags locally and can push them? or otherwise generate the tags now and push them. I can also do it if you want, I'll push tags on the commits from the list I wrote above. BTW, in case you run into a Make error while building current master, it may be fixed here: https://gerrit.osmocom.org/c/osmo-pcap/+/14666 Regards, Pau -- - 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

6 years, 1 month

Samsung and PS problems

by Mykola Shchetinin

Hello, Has anybody tested PS (either 2G or 3G) with Samsung phones? Have you experienced any problems? (like having no internet though at the same time PDP is active and GTP traffic is flowing in both directions) Kind regards, Mykola Shchetinin

6 years, 1 month

OpenBSC installed but missing ipaccess and abisip-find

by ty

Hello. I just followed the step by step procedure outlined in the wiki to compile OpenBSC on Ubuntu 16.04 LTS for the ip.access nanoBTS. My problem is that the folder ipaccess which has the ipaccess.config is missing and so is the abisip-find file. Any leads on why this is happening? I had seen somewhere that the above can be found in the osmocom-ipaccess-utils from the repo but that too is unavailable. Many thanks -tyrus

6 years, 2 months

Errors from git.osmocom.org

by Oliver Smith

Hello ML, cloning from git.osmocom.org is sporadically failing. From one CI job that ran today: > Cloning into 'osmo-bsc'... > error: garbage at end of loose object 'b5511145af6213e2d23a3e9890fd42b8aaa0dc1b' > fatal: loose object b5511145af6213e2d23a3e9890fd42b8aaa0dc1b (stored in <https://jenkins.osmocom.org/jenkins/job/Osmocom_OBS_latest/ws/osmo-bsc/.git…)> is corrupt > Build step 'Execute shell' marked build as failure https://jenkins.osmocom.org/jenkins/job/Osmocom_OBS_latest/628/display/redi… Another job failed today with: > + git -C osmo-bts fetch > fatal: unable to access 'https://git.osmocom.org/osmo-bts/': The requested URL returned error: 504 I've restarted the CI jobs. Regards, 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

6 years, 2 months

URGENT: OsmoMSC is broken by the recent changes in libosmocore

by Vadim Yanitskiy

Hi Harald! Unfortunately, your change [1] breaks some osmo-* projects. I am getting the following segfault with OsmoMSC: [1] https://git.osmocom.org/libosmocore/commit/?id=b3f94eb39e19366c3458643ee329… [1] https://gerrit.osmocom.org/#/c/libosmocore/+/14361/ ERROR: osmo_log_info == NULL! You must call log_init() before using logging in log_check_level()! Assert failed osmo_log_info logging.c:184 backtrace() returned 10 addresses /usr/local/lib/libosmocore.so.12(+0x16f6b) [0x7ffff72dff6b] /usr/local/lib/libosmocore.so.12(osmo_panic+0xc0) [0x7ffff72dff20] /usr/local/lib/libosmocore.so.12(+0x14487) [0x7ffff72dd487] /usr/local/lib/libosmocore.so.12(log_check_level+0x1a) [0x7ffff72de82a] /usr/local/lib/libosmocore.so.12(osmo_fsm_register+0xef) [0x7ffff72d81bf] /home/wmn/osmocom/osmo-msc/tests/msc_vlr/msc_vlr_test_ss() [0x692e03] /home/wmn/osmocom/osmo-msc/tests/msc_vlr/msc_vlr_test_ss() [0x9b6aad] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7ffff595fed5] /home/wmn/osmocom/osmo-msc/tests/msc_vlr/msc_vlr_test_ss() [0x4215cc] gdb-peda$ bt #0 0x00007ffff5974c37 in __GI_raise (sig=sig@entry=0x6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff5978028 in __GI_abort () at abort.c:89 #2 0x00007ffff72dff25 in osmo_panic_default (args=0x7fffffffda48, fmt=0x7ffff72e8cb9 "Assert failed %s %s:%d\n") at panic.c:49 #3 osmo_panic (fmt=fmt@entry=0x7ffff72e8cb9 "Assert failed %s %s:%d\n") at panic.c:84 #4 0x00007ffff72dd487 in assert_loginfo (src=<optimized out>) at logging.c:184 #5 0x00007ffff72de82a in log_check_level (subsys=subsys@entry=0xffffffff, level=level@entry=0x7) at logging.c:1033 #6 0x00007ffff72d81bf in osmo_fsm_register (fsm=0xcc6c20 <msc_a_fsm>) at fsm.c:261 #7 0x0000000000692e03 in msc_a_fsm_init () at msc_a.c:1003 #8 0x00000000009b6aad in __libc_csu_init () #9 0x00007ffff595fed5 in __libc_start_main (main=0x517540 <main>, argc=0x1, argv=0x7fffffffdcb8, init=0x9b6a60 <__libc_csu_init>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffdca8) at libc-start.c:246 #10 0x00000000004215cc in _start () As can be seen, this happens when we register 'msc_a' FSM, which of course has .allstate_event_mask == 0x00, and dummy .allstate_action == msc_a_fsm_allstate_action(), which basically does nothing. The registration happens even before the main() is called, since we use '__attribute__((constructor))', and logging is not yet initialized at that time. We need to fix the FSM definition, but right now I think we have no other way than reverting [1]. With best regards, Vadim Yanitskiy.

6 years, 2 months

OsmoSGSN: optional / mandatory authentication

by Vadim Yanitskiy

Hi Pau, today I cannot sign in to Gerrit for some magic reason, so I would like to post some notes about your change [1]. [1] https://gerrit.osmocom.org/#/c/osmo-sgsn/+/14445/ > [...] it changed the default logic for remote policy to not require > authentication, which broke TTCN3 tests because sgsn no longer > tries to authenticate the users. My bad, sorry for that. > let's enable it by default when on auth-policy remote. ACK. > doc/manuals/vty/sgsn_vty_reference.xml > Allow MS to attach via GERAN without authentication > (default and only possible value for non-remote auth-policy) Actually, no. My motivation for introducing this VTY parameter was exactly the ability to use remote auth-policy (i.e. OsmoHLR) to check if a subscriber is known, but not to require authentication, just like we can do in CS-domain. In other words, 'authentication optional' should work with 'auth-policy remote'. > src/gprs/sgsn_vty.c > DEFUN(cfg_authentication, cfg_authentication_cmd, > [...] > Allow MS to attach via GERAN without authentication > (default and only possible value for non-remote auth-policy) Same here. It *is* possible for 'auth-policy remote' too. > src/gprs/gprs_sgsn.c > struct sgsn_instance *sgsn_instance_alloc(void *talloc_ctx) > [...] > inst->cfg.auth_policy = SGSN_AUTH_POLICY_CLOSED; > /* only applies if auth_policy is REMOTE */ > inst->cfg.require_authentication = true; > [...] Are you sure this wouldn't break non-remote auth-policy use cases? AFAIR, the GMM layer requests authentication regardless of the 'auth-policy', so then in 'gprs/sgsn_auth.c' we conditionally perform authentication or immediately return SGSN_AUTH_ACCEPTED. An alternative solution is to invert 'cfg.require_authentication', e.g. to 'cfg.omit_authentication', so by default we will require authentication since it's initialized to false. With best regards, Vadim Yanitskiy.

6 years, 2 months

RFC: Quoted strings with spaces in CTRL protocol?

by Harald Welte

Hi! I've been working on a patch for OsmoBSC which generates CTRL traps from OML Failure Event Reports as received from BTSs. This is quite obvious, of course we want failures generate traps, right? The problem starts with the fact that Failure Event Reports can contain arbitrary strings ("Additional Text IE"), and that such text of course can contain spaces. My current patch (https://gerrit.osmocom.org/#/c/osmo-bsc/+/14177) would produce TRAPs like this: b'TRAP 0 bts.0.oml_failure_report "processing failure","failure ceased","TC_pcu_oml_alert"' [where the b'' part is from python as I used osmo_ctrl.py to print the above] As we never formally specified anything about the CTRL protocol apart from using ',' as a separator between fields, this is a somewhat grey area. What do you guys think? Do you know of existing CTRL interface usage where spaces are present in the 'value' part of the message? Do you know of existing code that would break should we introduce support for quoted strings with spaces inside the 'value' part? 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)

6 years, 3 months

New features without tests :/

by Harald Welte

Dear fellow Osmocom developers, I just would like to use this as a gentle reminder that we shouldn't be merging new features without having automatic tests for them in place. What comes to my mind immediately right now (but I'm sure there are other examples) is the "subscriber create on demand" feature. I couldn't find any tests in HLR_Tests.ttcn about this feature. What this means is, that it will *eventually* break unnoticed, particularly until somebody is using that feature and updating frequently to master, which is unlikely to happen. Either you run a production system and then you don't follow master, or you're just playing around and then that feature is probably not something you'd be using in many cases. What actually bugs me most about it, is that the tests should have been written first. For most of our development [1], the existing infrastructure in terms of TTCN3 Modules is very strong, and adding related tests is rather quick. This means it's *very* feasible to write the tests first and then the actual code. In fact, my own experience shows that development is much faster this way, as maual testing of the entire stack with phones is sloooow. This is not to complain to Oliver or any single person, but just a general reminder to all of us. That includes first and foremost myself as I'm merging most of the development, but is addressed to all of the developers and reviewers: IF something doesn't have a test, but could reasonably be tested without spending a multitude of the development time on tests, we should mandate that tests are available at the time of merge. We of course cannot mandate or enforce that developers write the tests first and follow test-driven development methodology. But I would at least strongly encourage everyone to try that. If you first spend tons of time with manual testing and then write a test case, it's much less efficient as you spend time for both. OTOTH, if you first invest the time into writing the test, then the development can make very quick progress and you save a lot of time that would otherwise be wasted with manual testing. Regards, Harald [1] I'm referring to rather self-cntained, small features. For sure, e.g. testing inter-MSC-HO requires lots of new tsting infrastructure to be developed, as does testing of the PCU. So yes, there are exception. -- - Harald Welte <hwelte(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

6 years, 3 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC