This adds some very basic rx/px rate counters to the SS7 AS and ASP
OsmoSTP> show rate-counters
SIGTRAN Application Server 0 (as-rkm-1):
rx:msu:total: 86078 (1888/s 86078/m 0/h 0/d)
tx:msu:total: 0 (0/s 0/m 0/h 0/d)
SIGTRAN Application Server Process 0 (asp-dyn-0):
rx:packets:total: 86081 (1888/s 86081/m 0/h 0/d)
tx:packets:total: 5 (0/s 5/m 0/h 0/d)
Change-Id: Idb811ca81adfe47152d484f6b981e661dc569e15
When we receive a message from an IPA/SCCPlite connection, we only
have SCCP global titles and no underlying M3UA. We since have
to introduce a fake M3UA header. While we correctly set the SI,
OPC and DPC, we didn't set the NI to what is configured as default
for the cs7 instance in the VTY. For international, this problem
was hidden by the fact that international is '0' and hence our
default memory initialization.
Change-Id: I02c618fa0a0aa2a859fcd56397df9637043c8e6e
Closes: SYS#5421
When receiving SCCP messages from an IPA peer/ASP, osmo-stp so far
unconditionally inserted origin/destination point codes int the SCCP
called / calling party addresses.
This behaviro is now made optional with the introduction of the
following per-AS configuration:
"point-code override patch-sccp (disabled|both)"
The default behavior is switched from 'both' to 'disabled' at the same
time.
Change-Id: I535e2170adadfe755d2bcbf5bbf4556bebb77737
Closes: OS#4219
If an IPA ASP is sending us a SCCP message that cannot be parsed,
we shouldn't crash but handle this gracefully.
Change-Id: Ib7a8c2a36dd1b82ca8ed472760c1682ede50cb90
Fixes: OS#4236
The IPA/SCCPlite stacking is - as the name implies - constrained to
the transport of SCCP messages. We have to reject any non-SCCP payload.
Change-Id: I5e5a2879013ee8cf08aa4199b4bee498dcb61446
Fixes: OS#4235
1: Do not call xua_msg_alloc() which is later bluntly overwritten by
m3ua_xfer_from_data().
2: After dispatching to m3ua_hmdc_rx_from_l2(), call xua_msg_free().
Related: OS#3393
Change-Id: I0918f9bbc15b036619f1c25a133b69819b2a30fa
Applications may be interested in handling data for those SCTP PPID or
IPA StreamID which libosmo-sigtran doesn't implement
natively/internally.
Let's add osmo_ss7_register_rx_unknown_cb() using which applications
can register a call-back to implement whatever behaviour they'd want for
those PPID/StreamIDs.
Change-Id: I8616f914192000df0ec6547ff4ada80e0f9042a2
When we receive a SCCPlite message from an IPA peer, it may simply
contain a SSN number but no point codes. Similarly to creating a fake
MTP routing label from override DPC and routing key OPC, we can also
add that point code information to the SCCP header. This way the rest
of the SS7 network can handle the message and route it accordingly.
Change-Id: I4a2ff063e3c060641b3fd181a1cd600da3ec568b
As IPA is a transport layer underneath SCCP, and we don't have MTP-level
OPC and DPC fields in it, we are using the "point-code override dpc"
feature for setting the pseudo-M3UA DPC on incoming Rx packets,
and we use the PC from the routing context as pseudo-M3UA OPC.
However, we were so far only storing this in the M3UA data header,
and not in the xua->mtp.{opc,dpc} members, which are consulted
during the routing decisions.
Change-Id: I5e2244620cd48f848382eb595ce59c6212069788
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
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
Harald Welte
Neels Hofmeyr