Remove OpenSUSE bug report link, set version to 0.0.0, make it build with
CentOS 8 etc.
Do not try to build libsscp, libmtp and libxua as shared libraries. The
imported spec file patched the source with "0001-build-fixes.patch" (not
imported) and packaged resulting so files. However, these libraries are
legacy and built statically on purpose, as it's stated on the wiki page:
https://osmocom.org/projects/libosmo-sccp/wiki
Related: OS#4550
Change-Id: Id1d77a79b43a9cb967fe3fe10394cca24757af85
As pointed out at https://github.com/libexpat/libexpat/issues/312
libtool does not play nice with clang sanitizer builds at all.
For those builds LD shoud be set to clang too (and LDFLAGS needs the
sanitizer flags as well), because the clang compiler driver knows how
linking to the sanitizer libs works, but then at a later stage libtool
fails to actually produce the shared libraries and the build fails. This
is fixed by this patch.
Addtionally LD_LIBRARY_PATH has no effect on conftest runs during
configure time, so the rpath needs to be set to the asan library path to
ensure the configure run does not fail due to a missing asan library,
i.e.:
SANS='-fsanitize=memory -fsanitize-recover=all -shared-libsan'
export CC=clang-10
ASANPATH=$(dirname `$CC -print-file-name=libclang_rt.asan-x86_64.so`)
export LDFLAGS="-Wl,-rpath,$ASANPATH $SANS $LDFLAGS"
Change-Id: I292c303840a76c5042dc077829c5df46158ca8ba
When 'cs7' was added, it was generally possible to get the full automatic
configuration spelled out by using 'show running-config'. Later, the vty was
modified so that automatically configured parts were omitted.
Since figuring out the 'cs7' configuration is far from trivial, it is very
convenient to get the program's current configuration spelled out in detail,
whether it is automatic or not. For this purpose, add a new 'show' command
which simply calls the ss7 VTY's write function with a new switch to disable
all omissions.
Change-Id: I84707561a6f54851c5599c39ea9bf1d971a2a1d7
Those values (except for XUA_T_ACK_SEC) are not used at all, and anyway
they already exist as timers in osmo_sccp_timer_defaults (sccp_scoc.c).
Change-Id: Id5902e809e02b2651e381cd58ef97b77c1143dc2
All other code paths moving to state DISCONN_PEND seem to stop them, and
anyway that state doesn't permit event SCOC_E_T_IAS_EXP:
DLSCCP DEBUG SCCP-SCOC(0){ACTIVE}: Received Event T(iar)_expired (sccp_scoc.c:346)
...
DLSCCP DEBUG SCCP-SCOC(0){ACTIVE}: state_chg to DISCONN_PEND (sccp_scoc.c:1095)
...
DLSCCP DEBUG SCCP-SCOC(0){DISCONN_PEND}: Received Event T(ias)_expired (sccp_scoc.c:339)
DLSCCP ERROR SCCP-SCOC(0){DISCONN_PEND}: Event T(ias)_expired not permitted (sccp_scoc.c:339)
Change-Id: Ieb02dedba312ab76890e943934ce6a1e2fe61f74
When using osmo_sccp_simple_client(), it will create an sccp instance if
none exists. The sccp instance identifier starts with 0.
The implicit created instance should use sccp instance 0 (the
first connection).
This is basically a counterpart of much older commit
3884eb68d9, were same logic was applied to
osmo_sccp_simple_client().
Change-Id: I85d2680ac65a552d7b2824ec41cd8fc669782079
Passing a config file is still optional, and both client and server work
out of the box with providing any. It's still goot allowing to pass a
config file to be able to configure easily stuff like logging, VTY ip
address binding, etc.
Change-Id: Ie75d004a0e9f24309060f241f22209df1bbe358e
Wrong type was used when the function was introduced a few commits ago.
Fixes: 5a7eb34f735e0ae93a74da3bc8361454457e49cdi
Closes: CID#207712
Change-Id: Ie9b89483158dd6b988e4c34b497bf3b231c15cd3
first, xua_msg is allocated internally in the function. Then depending
on msg type different functions are called. All of those functions
either return the same input xua msg pointer or NULL. If they return
NULL due to parsing failure, we need to free the internally allocated
xua pointer.
Change-Id: I4189fbd66e7e05ce466b3e716a357c56d788b64c
Detected while running a TTCN3 sending malformed SCCP message in
SCCP_Tests_RAW.ttcn:
sccp_user.c:174:12: runtime error: member access within null pointer of type 'struct xua_msg'
ASAN:DEADLYSIGNAL
=================================================================
==6==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x7f2a11f93c5c bp 0x7ffefcf05c50 sp 0x7ffefcf05c10 T0)
#0 0x7f2a11f93c5b in mtp_user_prim_cb /tmp/libosmo-sccp/src/sccp_user.c:174
#1 0x7f2a11fb48f9 in deliver_to_mtp_user /tmp/libosmo-sccp/src/osmo_ss7_hmrt.c:94
#2 0x7f2a11fb4c8a in hmdt_message_for_distribution /tmp/libosmo-sccp/src/osmo_ss7_hmrt.c:133
#3 0x7f2a11fb5c90 in m3ua_hmdc_rx_from_l2 /tmp/libosmo-sccp/src/osmo_ss7_hmrt.c:275
#4 0x7f2a11f6f5c2 in m3ua_rx_xfer /tmp/libosmo-sccp/src/m3ua.c:586
#5 0x7f2a11f70480 in m3ua_rx_msg /tmp/libosmo-sccp/src/m3ua.c:739
#6 0x7f2a11faee35 in xua_srv_conn_cb /tmp/libosmo-sccp/src/osmo_ss7.c:1623
#7 0x7f2a0f46d082 (/usr/lib/x86_64-linux-gnu/libosmonetif.so.8+0xb082)
#8 0x7f2a1186c0be (/usr/lib/x86_64-linux-gnu/libosmocore.so.12+0xc0be)
#9 0x7f2a1186c735 in osmo_select_main (/usr/lib/x86_64-linux-gnu/libosmocore.so.12+0xc735)
#10 0x557378718219 in main /tmp/libosmo-sccp/examples/sccp_demo_user.c:264
#11 0x7f2a105ad2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#12 0x557378717059 in _start (/usr/local/bin/sccp_demo_user+0x6059)
Change-Id: Idafa8c9693d98ecd214b62155372e4db69e2a4a4
* Introduce check to make sure we don't write out of peer->host bounds.
* Clean up any/specific address checks, it should be more clear now.
Change-Id: I3ecb94267acbec6ecf2134b08110f24f131cd8cf
Server addresses (and remote added ones) were not being copied to the
ASP and hence connections were not matches against the ASP when
connecting:
osmo_ss7.c:1820 (r=127.0.0.2:2905<->l=127.0.0.1:2905): m3ua connection
without matching ASP definition and no dynamic registration enabled, terminating
Related: OS#4355
Change-Id: I77d4f4d733cb46eaaacc7dc32259c9851c79d78e
The code managing addresses is decoupled from xua_server since they will
also be used to manage addresses for ASPs.
Change-Id: I4af2a6915ac57c7baa67343bd9414c65154d67f7
It doesn't really change old behavior since it's impossible the child
function returned an error with current implementation, but let's better
return the return code in case new error paths are added.
Change-Id: I24747578b3412b385c1ea1a14922f543f9023a27
It seems that our TTCN3 VTY/Telnet module no longer supports '-'
inside prompts. Let's make sure the SCCP_Tests can again be executed
by removing them from our promt name here.
Change-Id: I4b6d7dd6fdf7521a4a9071e50ac1dcb2993c74bb
Old commit of mine successfully fixed a memory leak, but apparently
after some more investigation it seems to have introduced a double free
of xua object in other code paths.
Nowadays, it seems scrc_rx_mtp_xfer_ind_xua() is called from 3 different places:
mtp_user_prim_cb()
sua_rx_cl()
sua_rx_co()
Before present patch, first caller is not freeing the xua message and my
old commit made scrc_rx_mtp_xfer_ind_xua() free it (by passing
ownsership of the object). But the other 2 callers do free the xua
object afterwards (actually the grandparent caller sua_rx_msg() does
it), which means it would double-free the xua object.
Let's move ownership out of scrc_rx_mtp_xfer_ind_xua() and let the
caller free the xua object (only changes need on the first caller). This
way everybody is happy and we keep the free() closer to the alloc().
Change-Id: Ia550b781b97adbdc0a0ad58a1075e5467e056f1e
Related: OS#4348
Fixes: 9c3baa89fb
This reverts commit ffb248dd78.
Reason for revert: ttcn-msc-tests fail, apparently there are lots more
xua_msg_free() in scrc_rx_mtp_xfer_ind_xua() that need to be dropped
Change-Id: I008bcb6d5bad9e6347e7cd670159816f51331189
After dispatching to scrc_rx_mtp_xfer_ind_xua(), free the xua_msg.
Do not free the xua_msg in any of the code paths triggered within
scrc_rx_mtp_xfer_ind_xua(), i.e. remove xua_msg_free() from:
sccp_scoc_rx_from_scrc()
+->sccp_scoc_rx_unass_local_ref()
+->tx_coerr_from_xua()
+->tx_relco_from_xua()
Before this, some code paths would free the xua_msg, while most code paths
would not, causing mem leaks.
Change-Id: I72b3c6a6f57ba32d9ba191af33b4b236492174e0
let's avoid messages like
DLSS7 <000c> xua_asp_fsm.c:600 XUA_ASP(asp-client0){ASP_DOWN}: transition to state ASP_DOWN not permitted!
Change-Id: Iabbcf92e3022a4c3f165ce19be929915f92b455c
Make build and external tests work with python3, so we can drop
the python2 dependency.
This should be merged shortly after osmo-python-tests was migrated to
python3, and the jenkins build slaves were (automatically) updated to
have the new osmo-python-tests installed.
Related: OS#2819
Depends: osmo-python-tests I3ffc3519bf6c22536a49dad7a966188ddad351a7
Change-Id: I344c49001fba23bdcfdef06ab174c52b60edd01c
If we are running in ASP (client) role, and we are about to transmit an
ASPAC or ASPIA to the SG, we must make sure to include any applicable
routing contexts.
Change-Id: Iee4f0d553d6845a9ae08cb5e4f57fdec443e4ef9
Related: OS#4285
When a client (ASP) sends an ASPAC to the server (SG), it should include
the traffic-mode configured for it's ASs, if any.
Change-Id: Ia850df22df529dab74959e8666f85976002c482c
Related: OS#4285
we handle this correctly in not writing the actual "asp" configuration,
but we have a bug when writing the list of asps within one "as". Let's
make sure to skip the dynamically-created ASPs there, too.
Change-Id: I1a184f3ddec2e91ced8c95ada224da8b490407a8
Closes: OS#4284
Oliver Smith
Philipp Maier
Harald Welte
Eric Wild
Neels Hofmeyr
Pau Espin
Neels Hofmeyr