When we accept SCTP connections from clients for whose IP/port we have
no matching local configurations, and it is permitted by local
configuration, we dynamically allocate osmo_ss7_asp's in this case.
Make sure to properly destroy them at the time the SCTP connection is
lost.
Change-Id: I07d69a0cd52a049a7a4bb0d996e95d39fee9a106
When we destroy a linkset, it make sense to remove all associated routes
pointing to the linkset, as they would point to nowhere anyway.
Change-Id: I393400bc758c28997e16bc78e3142719b6a61be8
We cannot use osmo_talloc_replace_string() together with
osmo_sock_get_name(), as the latter already creates a dynamically
allocated string, and the former will then make a copy of that
allocation.
Change-Id: I6798221ccb3c70186c1c51dd34b7823fefd6df58
The M3UA RFC defines this primitive to the layer manager, but we so far
didn't generate it. Let's inform the Layer Manager about such events,
in case it wants to take appropriate action.
Change-Id: I4e4e86f9b9d8ef4639c835878749ce8d8cc76f7c
If we don't do this, we get some nasty packet delays, which are
sufficient enough to trigger re-transmissions of an M3UA ASP-UP packet
even over loopback/localhost on an otherwise unloaded system.
Change-Id: I6aa4eb421ecb483d3da1b0ce3aa6511d161c3750
In case there is no user data in a CONNECT.conf primitive (or other CO
primitives), we must make sure that msgb->l2h = msgb->tail so that the
SCCP User can use msgb_l2len(msg) == 0 as indicator to verify if user
data is present or not.
Change-Id: Ie512fe063391e3a634097f555b9b0089d2981de9
When sending messages like CC (or SUA COAK) without user data, we must
make sure to not include the optional data part - as opposed to
including one with zero length.
Change-Id: If91edb526cbcd792ec5ebcb4518cf848feb69391
In their infinite wisdom, the inventors of SCTP designed an API (the
sockets API described in RFC6458), where some members are in host byte
order (like the stream identifier), while other members are in network
byte order (like the PPID).
Let's handle this properly (we assumed both are network byte order), and
also use 16-bit htons/ntohs fo the PPID, rather than htonl/ntohl.
Change-Id: I51c87314ef9ba6415e7e89980699ab07e787ed5d
This was discovered (and fix validated) using m3ua-sgp-mtr-i-003 of
Michael Tuexen's m3ua-testtol.
Change-Id: I7498f606b031f5a6dfb538d9900c744da6aed36f
According to the RFC, Stream ID 0 MUST not be used for XFER/DATA
messages.
This was discovered (and fix validated) using m3ua-sgp-mtr-v-003-alternate
of Michale Tuexen's m3ua-testtool.
Change-Id: I80b941426b5106e091bd1becff0ae97958aff97c
This was discovered (and fix validated) using m3ua-sgp-asptm-i-005 of
Michael Tuexne's m3ua-testtool.
Change-Id: I217ae287e22371e36dda0f87a7737b62fb1bf2d6
This was discovered (and fix validated) using m3ua-sgp-asptm-o-003
of Michale Tuexen's m3ua-testtool.
Change-Id: If231072655170fe52dae738882dd63b1d0a60cf9
This was discovered (and fix validated) using m3ua-sgp-asptm-o-001 of
Michael Tuexen's m3ua-testtool.
Change-Id: I6d254f7a33856e036329aa717a9c03efb1f1289d
This was discovered (and fix validated) using m3ua-sgp-asptm-i-004 of
Michael Tuexen's m3ua-testtool.
Change-Id: I76c01189b75ff3084cd4d3944314ec9b9f811dbf
This was discovered (and fix validated) using m3ua-sgp-aspsm-i-003
of Michale Tuexen's m3ua-testtool.
Change-Id: I8b63e7b5e39a7ef8dd66bf014110a04f5f3dc2a2
When we crate a sccp address with PC+SSN, we should also set the routing
indicator accordingly (OSMO_SCCP_RI_SSN_PC).
Change-Id: Ie179df7158624520e90093da063c57f1e3efa0bd
After verifying the routing context of an incoming M3UA message, remove
the routing context before passing into MTP routing. In the forwarding
case, we might want to set a new routing context on the outbound link,
and we don't want the routing context IE to show up twice.
Change-Id: I7a534cb1da275369c70766c059aaae8157ce6833
osmo_ss7_pointcode_print() osmo_ss7_pointcode_parse() etc. now support
passing a NULL ss7-instance which will lead to application of the
default ITU 3.8.3 point code format.
Change-Id: Ifb739e92e31eaaa0343dc57c9af8c9164d00175f
if osmo_xua_server.cfg.accept_dyn_reg is set, then ASPs are permitted
to connect without having a pre-configured matching ASP definition in
the vty. This helps particularly in cases where RKM is used for
dynamica registration of a RC (and hence AS).
Change-Id: Ie48898202acbdbfe144fdd5851dfedbb554b11aa
as 'struct osmo_sccp_instance' is opaque to the user application, it is
useful to have an accessor function that resolves the ss7 instance used
by the SCCP instance.
Change-Id: I8057a6d69584239b9781c5cece42066293ea1dd6
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
The RFCs say we *must* always respond to the optional heartbeat message,
and we must return a verbatim copy of the heartbeat data IE.
This was discovered (and fix validated) using m3ua-sgp-asptm-v-011 of
Michael Tuexen's m3ua-testtool.
Change-Id: I836e0940a8dbb0f55ddf132202a5f0d51473b82d
As 'struct osmo_sccp_user' is private, we need this accessor functions
for the SCCP User so it can set and get the 'priv' data.
Change-Id: Ia68a36dc18a7d754d63ae29c86d68e495b5c4134
We don't really need those thre log messages, and we can thus do away
with the library-internal log-subsystem of DXUA. The rest of
libosmo-sigtran uses the new globa DL... subsystems anyway
Change-Id: Iea0d3db34a3674a9c6422b174a879bfdaa25786f
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
We fill in the data structures of a xua_msg_dialect and make use of it
for generic mandatory IE checking and messageheader printing.
Change-Id: I966103f30b9be247ba6905ba8e06b87654d9981a
This is what aims to be a rather complete/proper implementation of the
SIGTRAN + SS7 protocol suite. It has proper abstraction between the
layers with primitives, finite state machines for things like the AS and
ASP state machines, support for point code routing, etc.
What's not implemented at this point:
* re-integration of pre-existing SUA (pending)
* actual MTP2 and physical E1/T1 link support
* different trafic modes like broadcast/fail-over/load-balance
Change-Id: I375eb80f01acc013094851d91d1d3333ebc12bc7
msg_event_maps facilitate the mapping from a xUA message (class + type)
to an integer event. This is useful when passing xUA messages to a
osmo_fsm.
Change-Id: Iee1c7fc2bf64219ebb71a0dbe6fd210749332413
libosmo-sigtran is GPLv2-or-later, there were some files that
accidentially had an AGPLv3 license header, which was a copy+paste
mistake at that time.
Change-Id: I67dfd0ae6157afafd3873a3baaa4c6107c04ddfd
A xua_msg_class repreents one xUA message class (like M3UA XFER
or SUA CL). A dialect is then something like SUA or M3UA, each
consisting of as many as 256 message classes. Each class contains
value_strings of the individual messages, as well as constraint
information on mandatory IEs for each message.
Change-Id: Ib538aca295b7b50132bc814b2d7b56cbe5d65bfc
Sometimes one already has the xua_msg_part and thus can avoid the
lookup that's done by xua_msg_get_u32().
Change-Id: Ie11c35f9528313d0b35786a361d853addd17364f
Move here unchanged first, so we're able to see the modifications in diffs.
Pending changes will follow in subsequent patches.
Moved from osmo-iuh 3da8608b6ad014fc74536dbb49019704fd425b8c, which was before
the rename of osmo_sua_link and osmo_sua_user to osmo_sccp_link and
osmo_sccp_user, so this will not compile.
Change-Id: Iae0c58c5f1eb00a685de70add0d5257e4316c6d5
For the N-DISCONNECT prim, parse CREF, RLC and RLSD from the proper parameter
struct type: osmo_scu_disconn_param instead of osmo_scu_connect_param.
Before this, the conn_id ended up in the wrong place and the other side always
received a zero conn_id.
Tested only for the RLSD case, which fixes Iu-Release message evaluation for
all except the very first SUA conn received by the CN components.
In all three cases, set:
* param->responding_addr to conn->called_addr.
* param->originator to OSMO_SCCP_ORIG_UNDEFINED.
Change-Id: I446f2fe57cc3b7c52723f3ab82836513a5d37752
In order to receive a Paging command with a valid RANAP SSN, decode the SCCP
source and destination address IEs. This is used by hnbgw to forward a Paging
from CN to RNC.
This may be done more generally as soon as more IEs need parsing of their sub
parts. For now, iterate the higher level IE's data chunk and obtain the address
sub part IEs without storing sub part locations.
Change-Id: I03d0c2a9003fda59c5b88c8738df009c30fbc11c
disconnect is not a class3/4 operation. We simply generate + send the
DISCONNECT.ind message to the remote side and drop all local state about the
connection.
Change-Id: I4e336f9dfd4ebd0122cd9e5a70db3d05e9dc1764
... which can be resolved from the primitive call back prim_cb() by
calling osmo_sccp_link_get_user_priv().
Change-Id: If4c0f96f0621fb2adf4c78dc5994d3398431d92f
When server creation failed, besides closing the fd also return an error,
instead of continuing to use the NULL srv.
Change-Id: Iabfae7e5a880d10e4050da4945200ce9b848e577
Fixes: coverity CID#57684
presumably, sock->gti_len is always zero when sock->gti is NULL, but ensure
with a check and make coverity scan happy.
Change-Id: I6cf195a3fbda1d9eacbbaec9a0e7f5b4c154f428
Fixes: coverity CID#57683
There are some compiler warnings about other unused variables which we
rather keep as a reminder that the SUA code is partially incomplete and
should be finished at some day.
Change-Id: I42b76351f1bbdfb7fe339d5fad98c5a065822a45
hwelte requested this change for the addition of libiu in openbsc. In a
conversation we came to the conclusion that a rename of these two opaque
structs would suffice.
This is the "upstream" rename and will require adaptation of:
* the sysmocom/iu branch in this repository
* the iu related branches in openbsc.git
* the hnbgw and dummy_cn code in osmo-iuh.git
See https://gerrit.osmocom.org/#/c/192/2/openbsc/src/libiu/iu.c@57
Change-Id: Icbf64dd96f8e0e27695df73d1144519b88360b94
The fixme is about an actual message sent back, not about the error log.
Change-Id: I6de8fb202c7beb025232e9b97605e9f46778506a
Reviewed-on: https://gerrit.osmocom.org/228
Tested-by: Jenkins Builder
Reviewed-by: Harald Welte <laforge@gnumonks.org>
At the time a SCCP CREF is sent there is no context anymore
and the user of the API might not know where to return the
message to. Allow to specify the incoming context and use it
on the way out.
There are no more callers of _send_msg which passes a NULL
connection and a NULL context.
Harald Welte
Neels Hofmeyr
Neels Hofmeyr
Alexander Huemer