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.
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.
