OpenBSC June 2019

openbsc@lists.osmocom.org

6 participants
17 discussions

Osmocom Village at CCC Camp 2019
by Harald Welte 31 Jul '19

31 Jul '19

Dear all, I've been asked by a number of pepole about a possible Osmocom village at the CCC Camp 2019. I personally didn't really have any plans, but given related e-mails and "encouragement" I went ahead and registered an "Osmocom Village", see https://signup.c3assemblies.de/assembly/3b8f7aa2-95d5-4c44-aadc-de8f2680e9c3 I also created a wiki page (as nobody else did, despite earlier discussion on IRC, SCNR) for coordinating related efforts at https://osmocom.org/projects/osmo-dev-con/wiki/CCC_Camp_2019 One of the bigger questions is about having a tent as well as some tables/benches to sit on and work. The Camp orga team nas been negotiating rates with a tent rental company, but to be honest I'm rather surprised by the extremely steep pricing. The smallest possible tent (6m x 3m) would cost 825 EUR. I'm not sure we want to raise that amount of money? Even if we'd be 10 people sharing it, its still 82.50 EUR per person. And that excludes any tables/chairs. I'm attaching the relevant parts of a mail from the assemblies orga team FYI. Please note there also is some kind of fragmentation / overlap with the team planning to run the GSM/3G networks at the camp, see Lynxis' related post at https://lists.osmocom.org/mailman/private/osmocom-event-orga/2019-June/0003… It's questionable whether it makes sense to have tow distinct 'villages', but given that e.g. I don't know anyone of that singularity city, I'm not sure if we'd either be welcome there, nor whether we'd want to associate us with them? Also, while the GSM network operation for sure has good reasons to mingle with the POC and whatever facilities they have, I'm not sure if the wider Osmocom community attendees unrelated to the GSM network operation wouldn't just be a disturbance/nuisance. In the end, to be honest, I personally do not feel I have the time and mental capacity to take on any additional tasks in terms of organizing anything. I just created the entry in c3assemblies as I was asked to, and I similarly created the related mailing list and wiki page. So please, anyone interested in making an Osmocom village happen one way or another, step up [and continue this discussion on the camp2019-village(a)lists.osmocom.org mailing list, without crossposting everywhere else :) 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)

3 3

OpenBSC on 3rd party MSC
by wyao＠corrections.com 29 Jul '19

29 Jul '19

Hello All, I am working on get OpenBSC connected to a 3rd party MSC, I read from the Osmo document that I can use the bsc only mode and the osm-bsc instead of the osmo-nitb. Currently I had osmo-trx-uhd, osmo-bts-trx, osmo-bsc, and osmo-stp configured and and running, but I see a lot of below error logs in the osmo-stp console: ``````````````````````````` DLSS7 <000c> osmo_ss7.c:1468 asp-asp-dyn-0: xua_srv_conn_cb(): sctp_recvmsg() returned 56 (flags=0x80) DLM3UA <000f> m3ua.c:722 asp-asp-dyn-0: Received M3UA Message (XFER:DATA) DLM3UA <000f> m3ua.c:541 asp-asp-dyn-0: m3ua_rx_xfer DLM3UA <000f> m3ua.c:580 asp-asp-dyn-0: m3ua_rx_xfer(): M3UA data header: opc=337=0.42.1 dpc=185=0.23.1 DLSS7 <000c> osmo_ss7_hmrt.c:278 m3ua_hmdc_rx_from_l2(): dpc=185=0.23.1 not local, message is for routing DLSS7 <000c> osmo_ss7_hmrt.c:258 MTP-TRANSFER.req for DPC 185: no route! ```````````````````````````` On the BSC console, I am seeing a lot of: ``````````````````````````````` <0007> a_reset.c:106 A-RESET(msc-0)[0xb76ce0]{DISC}: (re)sending BSSMAP RESET message... <0007> osmo_bsc_sigtran.c:93 Sending RESET to MSC: RI=SSN_PC,PC=0.23.1,SSN=BSSAP ``````````````````````````````` Can anyone identify what is the issue here? Appreciates! Regards, Weiqi

3 4

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

OpenBSC installed but missing ipaccess and abisip-find
by ty 28 Jun '19

28 Jun '19

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

5 8

Errors from git.osmocom.org
by Oliver Smith 18 Jun '19

18 Jun '19

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

1 0

URGENT: OsmoMSC is broken by the recent changes in libosmocore
by Vadim Yanitskiy 15 Jun '19

15 Jun '19

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.

1 0

OsmoSGSN: optional / mandatory authentication
by Vadim Yanitskiy 14 Jun '19

14 Jun '19

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.

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

OpenBSC June 2019