The osmo_sccp_simple_client_on_ss7_id and osmo_sccp_simple_client
are not entirely configurable via VTY commands. The relation to
the VTY is implicit. The user may set up instance objects via
VTY (cs7/ss7, AS, ASP), which are then automatically created on
startup.
Each cs7 instance gets its own ID via the VTY configuration. When
osmo_sccp_simple_client_on_ss7_id() is called with the cs7 instance
id. (for osmo_sccp_simple_client() the ID will be hardcoded to 1),
the function automatically checks if the CS7 instance is present,
if not it will create one automatically using the caller supplied
parameters as a defult. If a CS7 instance is present, the function
checks for the presence of an AS and an ASP. These objects are
present, they will be used. If not, new objects will be created.
Both functions must not be called if an SCCP instance is already
present. Since there can only be one SCCP instance per CS7 instance,
this is an error condition.
Add additional logic that checks to detect an already existing, valid
configuration. If no or an insufficient configuration is detected,
use the caller supplied parameters as default configuration.
Change-Id: I293f3526ce6182dca74a169a23449dbc7af57c7c
Add function osmo_ss7_point_code_print2() to be able to print two point codes
in the same log message.
Change signatures of two static functions to aid logging:
add invalid ref arg to sccp_scoc_rx_inval_src_ref(),
pass conn instead of inst to sccp_scoc_rx_inval_opc().
Change-Id: Ia3243606d6cad7721f7da7f6caba2caa90ae2bbd
In osmo_ss7_route_create() as is only initalized if lset can not
be initalized. If lset can be initalized, as will not be used so
everything is fine. However, the compiler complains that as may
not be initalized. Initalizing as to NULL solves the problem.
Change-Id: Ibcb3ebf9aaa7717cb553242517abce1499bc9c2a
SCCP addresses are defined through a number of compoinents, not
just an IP-Address, there is also point code, ssn and more. To
simplify and unify the handling of such objects, this patch
introduces an addressbook functionality. The user can set up
multiple addresses per ss7 instance and give them names. Later
that name can be used to reference the address at a later point
in the config. This means that the usage of sccp-addresses from
the programmers point of view boils down to a VTY function that
reads the string name of a previously defined address. The
programmer can then use the API to get a pointer to the SCCP
address struct and use it normally.
For this feature, two additional VTY nodes are necessary,
this commit depends libosmocore change:
Change-Id I42aa29c0cccc97f284b85801c5329b015b189640
Change-Id: I068ed7f7d113dab88424a9d47bab7fc703bb7942
The 'user' argument to osmo_ss7_user_unregister() can be NULL, so let's
make sure we don't dereference it.
Change-Id: Ia34b181dcbcb179b2639e2f405364cc952069842
Fixes: coverity CID#166933
The use of m3ua_msgb_alloc() from generic code is a bit ugly, but I
really don't want to introduce yet another msgb_alloc wrapper.
Change-Id: Ic6dc9a1e7bbed2e1f73395bd18b727fa7892e25b
When we disconnect a client, make sure that we always go through
xua_cli_close_and_reconnect(), which will make sure to notify the ASP
FSM using XUA_ASP_E_SCTP_COMM_DOWN_IND.
Change-Id: I6859b8549c8cbbe2e8279da0ede562387a066d04
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
So when we create a xua_server for SUA, we must make sure to create that
associated SCCP instance, if it doesn't already exist. End-user
programs probably normally call this during their initialization anyway,
but in something like OsmoSTP, we need to auto-create it.
Change-Id: Ib575763dbd00f5bd7bfbf48f227a8f5ef9528e2a
Higher-layer code shouldn't have to worry between client and server
difference. It just wants to close the underlying connection for a
given ASP - which it now can by means of osmo_ss7_asp_disconnect().
Change-Id: I36b089abd281b8edac8830fda2d8e57cc06cd0a7
For classic xUA this is not needed, as the server doesn't have to react
to establishment of the SCTP connection. The client will start with an
ASP_UP_REQ. However, in upcoming IPA support, the FSM will need to
react on this event.
Change-Id: Ib10914b27f8761ea44a0fdba96c045821223722a
When dynamically allocating ASPs, we used the hardcoded M3UA protocol,
which is of course wrong in case of SUA or other protocols. Let's use
the xua_server's configured protocol for the created ASPs.
Change-Id: I07832cbaf1ca42f0c7df399e4f96599034b72816
When we destroy a xua_server, we would like to close and destroy any
ASPs that were established via that xua_server. In order to do so, we
need to add a list of ASPs to the xua_server, which we can iterate.
Change-Id: Iff3ed099b817e54e563b70d9ab40f63af63cc2fb
By moving this variable into the SS7 instance, we avoid one more global
variable, and we also fix a bug where the xua servers would be saved
multiple times (once per instance).
Change-Id: Icbab59d773f23cc8514cbeb6e21e25ca35dd337f
If we actually found an instance for the specified ID, return it fast
and don't (re)initialize all linked list heads, etc.
Change-Id: I91b6aabdb873ed8dd103918ee5e40b7ad3946735
This properly integrates the concept of multiple SS7 instances (each
with their own point code format, address indicator, ...) into the VTY.
At the same time, this also removes the stp-global "g_s7i" instance
that existed so far, moving the VTY code more into the direction of also
being able to be used outside the STP - which is underlined by splitting
the vty commands between those generally useful, and those useful only
for a STP or only for a simpla ASP (client).
Change-Id: I30966fbf2e143318cd9127eb8c17cccb24407106
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
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
osmo-stp is able to define multiple M3UA and/or SUA application servers
(AS) as well as application server processes (ASPs). Clients can then
connect via M3UA or SUA, perform the respective ASPSM / ASPTM state
changes and finally exchange MTP signaling such as ISUP or SCCP on top
of it. Routing is currently only based on point codes (PC). Routing table
is fully configurable with Destination PC and mask.
Shortcomings:
* xUA: only "override" traffic mode supported, no load-balance or broadcast
* xUA: no SNM supported, i.e. DAVA/DUNA/... messages are neither parsed
nor generated
* SCCP: no Global Title based Routing (GTR) yet
* SCCP: no Global Title Translation (GTT) yet
* no M2PA / M2UA sigtran dialects
* no classic CS7 based signaling links(E1/T1 TDM)
Change-Id: If32227b8d3127c6178e4ee45527ce65f69bc7b1e
In 17df5953ff we fixed endianness issues
with the Stream ID field, but at the same time mistook the PPID field
for 16bits. In reality it is 32bits, and hence our 'htons' is rendering
wrong PPID values.
Change-Id: Ief04486e752e6b7e0a853b1fa9ca525ad47800f6
In M3UA RKM we need a "Local Routing Key ID" which uniquely identifies a
given routing key locally at the node. Allocate this value and store it
in each osmo_ss7_as, as well as add a lookup function for it.
Change-Id: I89a0abcf66228ce092126a497cc7971df3a6af71
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 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
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
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
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
Philipp Maier
Neels Hofmeyr
Harald Welte