There are implementations out there which send us traffic, specifically
in this case SCMG (SST) that has only SSN in both Called and Calling
Party. This means the inbound SST message is routed correctly to the
local SCCP user of libosmo-sigtran. But when that local SCCP user
responds with inverting Called/Calling Party, the new destination again
just contains a SSN.
As a result, we don't know where to route the message (we always need a PC).
Change-Id: Id66ae960ebe3cb3b09c6dd5454f9ac9c073f46d7
Closes: OS#5146
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
Anywhere else in the Osmocom code base, we arrange headers in
include/osmocom/foo/ and pass -I ${root_srcdir}/include/.
This way including an osmocom header always has the format
#include <osmocom/foo/bar.h>
whether we are including from the local source tree or from $prefix.
For some reason not clear to me, the mtp and sccp folders, even though they are
being installed to $prefix/include/osmocom/, were kept *next* to the osmocom/
dir, instead of inside it. Fix that weird situation.
The motivation is that I wanted to use a definition from sccp_types.h in a
public-API header. That is impossible if it requires
#include <sccp/sccp_types.h>
in a local build, but
#include <osmocom/sccp/sccp_types.h>
for any other source tree using libosmo-sccp. After this patch, both are
identical and including works without quirks. (The other patch that needed this
has changed in the meantime on and no longer needs this, but this still makes
sense for future hacking.)
The installed result does not change, since both mtp/*.h and sccp/*.h have
always been installed to $prefix/include/osmocom/{mtp,sccp}/. This merely
changes their position in the source tree.
The most curious situation before this is that any patch #including
<osmocom/sccp/sccp_types.h> might not get a notice that the header didn't
exist, but might instead include an older system-installed file.
Change-Id: I1209a4ecf9f692a8030b5c93cd281fc9dd58d105
Fixes following error provided by LeakSanitizer:
Indirect leak of 1496 byte(s) in 11 object(s) allocated from:
#0 0x7f1eb3332d99 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:86
#1 0x7f1eae617b61 in _talloc_zero (/usr/lib/libtalloc.so.2+0x5b61)
#2 0x7f1eb063e365 in xua_msg_alloc /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_msg.c:49
#3 0x7f1eb0650ee3 in osmo_sccp_to_xua /home/pespin/dev/sysmocom/git/libosmo-sccp/src/sccp2sua.c:1298
#4 0x7f1eb0668d6a in mtp_user_prim_cb /home/pespin/dev/sysmocom/git/libosmo-sccp/src/sccp_user.c:173
#5 0x7f1eb068ba86 in deliver_to_mtp_user /home/pespin/dev/sysmocom/git/libosmo-sccp/src/osmo_ss7_hmrt.c:94
#6 0x7f1eb068bf00 in hmdt_message_for_distribution /home/pespin/dev/sysmocom/git/libosmo-sccp/src/osmo_ss7_hmrt.c:133
#7 0x7f1eb068d345 in m3ua_hmdc_rx_from_l2 /home/pespin/dev/sysmocom/git/libosmo-sccp/src/osmo_ss7_hmrt.c:275
#8 0x7f1eb063c08f in m3ua_rx_xfer /home/pespin/dev/sysmocom/git/libosmo-sccp/src/m3ua.c:586
#9 0x7f1eb063cea6 in m3ua_rx_msg /home/pespin/dev/sysmocom/git/libosmo-sccp/src/m3ua.c:739
#10 0x7f1eb0687188 in xua_cli_read_cb /home/pespin/dev/sysmocom/git/libosmo-sccp/src/osmo_ss7.c:1590
#11 0x7f1eaff77db4 in osmo_stream_cli_read /home/pespin/dev/sysmocom/git/libosmo-netif/src/stream.c:192
#12 0x7f1eaff79091 in osmo_stream_cli_fd_cb /home/pespin/dev/sysmocom/git/libosmo-netif/src/stream.c:276
#13 0x7f1eaf259795 in osmo_fd_disp_fds /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:217
#14 0x7f1eaf259abb in osmo_select_main /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:257
#15 0x55666c1bebd3 in main /home/pespin/dev/sysmocom/git/osmo-msc/src/osmo-msc/msc_main.c:697
#16 0x7f1ead1c306a in __libc_start_main (/usr/lib/libc.so.6+0x2306a)
#17 0x55666c1bc649 in _start (/home/pespin/dev/sysmocom/build/new/out/bin/osmo-msc+0x185649)
The code path is the following, starting from mpt_user_prim_cb:
mtp_user_prim_cb
osmo_sccp_to_xua
xua_msg_alloc
scrc_rx_mtp_xfer_ind_xua
sccp_scoc_rx_from_scrc
scrc_node_6
scrc_node_4
scrc_translate_node_9
So the xua_msg is created in mtp_user_prim_cb through osmo_sccp_to_xua
and then handed over to scrc_rx_mtp_xfer_ind_xua which transfers the
xua_msg and thus should take ownserhip of it, and consecuently freeing
it once it's done using it.
Change-Id: I43e159c82b64bd85b185f77ee19b6455a96e082f
We don't implement routing by global title address.
When processing an SCCP message which is routed by global title,
don't recurs indefinitely until the stack is exhausted.
Instead, return an error with cause SUBSYSTEM_FAILURE, which we
also do in other routing failure cases.
Change-Id: I24621e77ffc979bc337775f9c6a4ad9a9068625a
Related: OS#2666
Initialize osmo_ss7_instance.cfg.primary_pc = OSMO_SS7_PC_INVALID.
Adjust all code paths using primary_pc to ensure it is indeed valid.
Rationale:
It looks like we are going to use the primary point-code of an SS7 instance to
derive a local SCCP address, e.g. for osmo-bsc and osmo-hnbgw.
cs7-instance 1
point-code 1.2.3 ! sets osmo_ss7_instance.primary_pc = 1.2.3
sccp-address msc
point-code 0.0.1
routing-indicator PC
hnb
iucs
remote-addr msc ! derives cs7 instance 1 and local pc 1.2.3
If 'point-code 1.2.3' is omitted, this becomes '0.0.0' without the user
noticing, and this happens for each client that omits it. I would like to barf
when no local PC is set.
Change-Id: I7f0f0c89b7335d9da24161bfac8234be214ca00c
translate function is always present in the same file, thus we can
remove this check.
Fixes following warning:
warning: the address of ‘translate’ will always evaluate as ‘true’ [-Waddress]
if (translate &&
As requested by Harald, leave a comment there stating that there are some
checks missing and yet to be implemented. The translate function check
was used for this purpose.
Change-Id: I48a711f3a43496e2c0c637f34f56784f765938c4
This tries as good as possible to fit the IPA/SCCPlite stacking into the
existing SIGTRAN/SS7 code architecture/model. To the user, the IPA
protocol looks like yet another protocol on the same level as the choice
between SUA and M3AU. On the inside, things are obviously quite
different.
We need to handle TCP with IPA framing instead of SCTP for both server
and client. We also implement an alternative "ASP FSM" for IPA, which
takes care of the CCM handshake (ID_REQ/ID_RESP/ID_ACK/ID_ACK2) for both
client and server mode.
In server mode, we use the 'unit name' as identifier to look up the AS,
similar to how we use a routing context to look up the AS in the xUA
case.
We also have to bypass activating the default layer manager in the
simple client to make sure we don't run into even more complexity.
What's missing right now is some way to manually override/set the point
codes. As IPA/SCCPlite is missing any routing label, we currently
simply generate one with SPC=0/DPC=0, which will obviously not work in
most configurations.
Change-Id: I9098574cddeba10fcf8f1b6c196a7069a6805c56
The general rule for 'struct xua_msg' is now that it is free'd by the
function that also allocates it in the first place. Any downstream
consumer of the xua_msg may interpret it, but not hold any references or
free() it.
Change-Id: I708505d129da5824c69b31a13a9c93201929bada
If we use the infrastructure provided by osmo_ss7 on the lower layer and
the SCCP SCRC, SCLC and SCOC code on the upper side, not much of the
original sua.c code remains. It looks much like the M3UA code now.
Change-Id: I193b74f58aa70c443ae17e78b5604246d6bc3f71
This is an implementation of SCCP as specified in ITO-T Q.71x,
particularly the SCRC (routing), SCLC (Connectionless) and SCOC
(Connection Oriented) portions. the elaborate state machines of
SCOC are implemented using osmo_fsm, with one state machine for each
connection.
Interfaces to the top (user application) are the SCCP-USER-SAP and on
the bottom (network) side the MTP-USER-SAP as provided by osmo_ss7.
Contrary to a straight-forward implementation, the code internally
always uses a SUA representation of all messages (in struct xua_msg).
This enables us to have one common implementation of all related state
machines and use them for both SUA and SCCP. If used with real SCCP
wire format, all messages are translated from SCCP to SUA on ingress and
translated from SUA to SCCP on egress. As SUA is a super-set of SCCP,
this can be done "lossless".
Change-Id: I916e895d9a4914b05483fe12ab5251f206d10dee
Harald Welte
Pau Espin
Neels Hofmeyr
Neels Hofmeyr