If the AS is e.g. configured as broadcast, then individual ASPs cannot
be activated in loadshare or override. Everyone must agree.
Change-Id: Ic73410fbc88d50710202453f759fa132ce14db4c
RFC 4666 (SS7/MTP3/M3UA) states in isection 4.3.4.3 ASP Active Procedures:
"""
If the traffic handling mode of the Application Server is not already known via
configuration data, then the traffic handling mode indicated in the
first ASP Active message causing the transition of the Application
Server state to AS-ACTIVE MAY be used to set the mode.
"""
In section 3.6.1 Registration Request (REG REQ), no related information
is provided on how to handle it, but still makes sense to apply same
behavior as in 4.3.4.3.
Related: OS#4220
Change-Id: Iaebe3a93ad8d2d84ae01e41b02674f8ece9dfc95
Change a loglevel from NOTICE to ERROR, for when a routing key gets
re-purposed.
Add another error log for insufficient resources case.
Change-Id: Id22e3c6bab5f7b597df3514eedb162277ce0ef7d
From LeakSanitizer report:
Indirect leak of 384 byte(s) in 3 object(s) allocated from:
#0 0x7f986da27d99 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:86
#1 0x7f9868d0cb61 in _talloc_zero (/usr/lib/libtalloc.so.2+0x5b61)
#2 0x7f986ad33766 in xua_msg_add_data /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_msg.c:73
#3 0x7f986ad343c3 in xua_from_msg_common /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_msg.c:143
#4 0x7f986ad347d2 in xua_from_nested /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_msg.c:201
#5 0x7f986ad65563 in m3ua_rx_rkm_reg_rsp /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_rkm.c:431
#6 0x7f986ad65f96 in m3ua_rx_rkm /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_rkm.c:510
#7 0x7f986ad31ef7 in m3ua_rx_msg /home/pespin/dev/sysmocom/git/libosmo-sccp/src/m3ua.c:749
#8 0x7f986ad7c1e8 in xua_cli_read_cb /home/pespin/dev/sysmocom/git/libosmo-sccp/src/osmo_ss7.c:1590
#9 0x7f986a66cdb4 in osmo_stream_cli_read /home/pespin/dev/sysmocom/git/libosmo-netif/src/stream.c:192
#10 0x7f986a66e091 in osmo_stream_cli_fd_cb /home/pespin/dev/sysmocom/git/libosmo-netif/src/stream.c:276
#11 0x7f986994e795 in osmo_fd_disp_fds /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:217
#12 0x7f986994eabb in osmo_select_main /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:257
#13 0x5630cb294bd3 in main /home/pespin/dev/sysmocom/git/osmo-msc/src/osmo-msc/msc_main.c:697
#14 0x7f98678b806a in __libc_start_main (/usr/lib/libc.so.6+0x2306a)
#15 0x5630cb292649 in _start (/home/pespin/dev/sysmocom/build/new/out/bin/osmo-msc+0x185649)
Following code paths:
m3ua_rx_rkm_reg_rsp
xua_from_nested
xua_from_msg_common
xua_msg_add_data
talloc_zero (part)
handle_rkey_reg_resp
Take the chance to fix the same issue in m3ua_rx_rkm_dereg_rsp.
Change-Id: I0b15d81099a9f8274b7e39962caa339da644e0dc
A primitive allocated in lm_timer_cb() with xua_xlm_prim_alloc()
was never freed. Don't forget to free the msgb in osmo_xlm_sap_down().
Found by code inspection.
Also, assert that allocation suceeded like we do elsewhere.
Change-Id: Ie667b1b8beeda2aa4520a1413f51101435215cc0
Related: OS#2449
RKM permits multiple routing key IEs to be inside a single Routing Key
Registration message. We were trying to handle this, but the counter we
used as array index into the 'newly_assigned_as' array was actually
always kept at zero.
Change-Id: I08a962d2f242cefb67fb2dc93818c1ed532e8990
Fixes: coverity CID#166991
When RKM dynamically allocates ASs on the SGP based on RKM registration
requests, we must make sure to properly destroy those at the time the
related ASP disconnects. Also, make sure to send
XUA_ASP_E_SCTP_COMM_DOWN_IND to the layer manager (if any).
Change-Id: Ie6505680bb6890814ae36858c54a2a6d2850f5cf
The existign xua_rkm code was merged a bit pre-maturely as it was not
properly tested. This adds a lot of fixes to make it work at all in the
first place, as well as the configurable option for fully dynamic
routing key management, where ASs and routing keys must not be
configured statically by administrative means, but clients (ASPs) can
simply come and register for whatever point code they want.
Change-Id: I79a070fa7b271b44995511f7b3ff7cc6beec8278
This "default layer manager" can optionally be used by a xUA ASP. It
will handle the xUA Layer Manager (xlm) primitives and use them to
behave as follows:
* bring the ASP into state "INACTIVE"
* see if the SG can match our connection (based on IP address + port
information) to a statically configured ASP configuration with
associated AS(s). If yes, it will send us a NOTIFY message with
AS-INACTIVE.
* if the above doesn't work, try to dynamically register a routing key
using RKM for the point code that was locally confiured on the
ASP/client. If that works, the SG will now have created ASP and AS
objects as well as a routing key and be able to serve us, sending the
NOTIFY with the AS-INACTIVE state.
* After either of the two above, we will attempt to transition into
ASP-ACTIVE. The SG should send us an AS-ACTIVE notification in return
* if anything fails, abort and disconnect the SCTP connection, restart
related FSMs and start from scratch
Change-Id: I78d4623dd213b5c59007a026a6cc3cfe5c04af50
Oliver Smith
Harald Welte
Pau Espin
Neels Hofmeyr