OpenBSC June 2019

openbsc@lists.osmocom.org

6 participants
22 discussions

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