We had used + derefernced the 'prim' pointer before checking its
validity.
Change-Id: I0ca5026091e91926924b297f9342bda5f9fd38c9
Fixes: coverity CID#166946
When receiving an unknown primitive, we end up de-referencing an
unassigned/uninitialized pointer for 'conn'. Let's properly catch that
case and print an error message.
Change-Id: Id1f5f293ea9bce8601d45164be670a7062d91802
Fixes: coverity CID#166947
The missing break statement leads to an unintended fall-through which in
turn prints a wrong ERROR message.
Change-Id: I6618fa247b889d4162118278cd05dee85cf21899
Fixes: coverity CID#166948
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
If for some reason we cannot resolve the file descriptor for a given
FSM, we shouldn't attempt to send data through it.
Fixes: coverity CID#167155, CID#167154, CID#167153, CID#167152, CID#167151, CID#167151
Change-Id: I8b1a676b653bcdad21cb7927d549f499950a2b73
As an IPA SCCPlite message arrives without any MTP routing label, we
simply construct one artificially for all inbound IPA/SCCPlite packets:
* we set the SPC to the point-code of the routing key of the AS
(as this is the PC we route to this IPA/SCCPlite client anyway)
* we set the DPC to a point-code from a new vty config command
"point-code override dpc"
Change-Id: Id556398e1ded3e613cfde7ea8b71aff7a414ff90
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
I don't think the order of messages is that important (and specified in
the RFC), but let's do this to make the m3ua-testtool case happy.
Change-Id: I2e150e941a6fcfd203944f5b20bd07c07193f44a
Depending on whether or not any ASP is INACTIVE, we need to go to
AS_INACTIVE or AS_DOWN after T(r) expiry in the xua_as_fsm.
Found by m3ua-testtool testcase m3ua-sgp-aspsm-o-003
Change-Id: Iad6b176a5c95a28fbd5ba437696c2e6e160bdb00
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
When an AS goes "down" it first entres a recovery state, in which any
to-be-transmitted messages are enqueued until the timer T(r) expires.
Once the timer expires, the messages are discarded. If the AS goes
ACTIVE before timer expiration, queued messages are sent.
Change-Id: I22725bf35306299a00c66d7b3637f5e198c26247
If we add more xUA variants/protocols, we want to avoid having to touch
too many parts of the code with copy+pasted strings.
Change-Id: I085b884d98fb4c45ac15910a8ebf82b91e861fd4
This is not really needed by the state machines internally, so we have
to artificially add it to the sccp_connection. We don't use it yet, but
upcoming code for VTY introspection of SCCP connections will be able to
use it.
Change-Id: Ic3c85152665abfb613e197b098c97392d16d16bf
If RKM has dynamically generated some AS definitions on the fly, or if
we accepted auto-creation of ASPs on SCTP connect time, then we don't
wnat to save such objects during vty config file store.
Change-Id: I9d0b0b61737a30b9d6e76cecbe42ec071bcddeeb
Using this command one can specify if ASP connections should be refused
if there's no matching configuration, or whether ASPs should simply be
create on-demand.
Change-Id: Ic93b99047fb566cdb25a2f4139ebef54849dece9
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 way it is systematic and doesn't clash with other optional
arguments we may introduce sooner or later at the end of the commands
Change-Id: I5c1050b0564791b5684619d3737d1cb6c4539d63
RFC3868 states clearly that DATA messages MUST be sent o a stream other
than stream '0'. So at the receiver side, we should validate that (just
like we do in M3UA.
Change-Id: I0784e221ef791557a69be04f7d246de059ea84c8
Now that the VTY has no static dependencies like a global ss7_instance
anymore, we can move it back to libosmo-sigtran and make use of it in
other programs outside osmo-stp.
This requires Change-Id I184a7e3187b48c15c71bf773f86e188fe1daad15 in
libosmocore
Change-Id: I2e549f1eadbfb28dde79f620b130cbf022312c42
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
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
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
The SCCP spec clearly defines which optional information element each of
the messages supports. We must make sure to not include any other
options when converting from SUA. SUA has more relaxed rules about
this, and e.g. supports SRC and DEST ADDR in the COAK, while the SCCP CC
only permits a CalledParty, but not CallingParty.
This was found when interoperating against the Ericsson TTCN-3 SCCP
implementation for Eclipse Titan.
Change-Id: I7d9e23dec1d3e786d291abd270a261704593befc
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 are on the ASP (client) side, we must initialize the routing key
of the AS with the proper primary point code of the system. Only this
way, the correct point code will be used during dynamic routing key
registration via RKM.
Change-Id: If586ac9f3449254973a19654dd13dce5793f285f
Harald Welte
Max