In Change-Id Ia1910f3b99d918ec2a34d5304c3f40ba015c25c9 we introduced
osmo_io support for xUA + IPA. However, when we did that, the msgb
allocation sizes of libosmo-sigtran were neglected, and rather the
defaults of osmo_io used.
This commit returns libosmo-sigtran to the exact msgb allocation +
headroom sizes used before the osmo_io migration.
Related: OS#5752
Closes: OS#6403
Depends: libosmo-netif.git Change-Id Ie19c8294ddb12dfe5e0fd44e047c47e6f9cbd384
Change-Id: I0c6dcff4523e4c04aae43a4585b5e0c3617ef1a6
Before this patch, the code generating a DUNA or DAVA message would
potentially generate a ROUTE_CTX IE with zero-length content, rather
than skipping such an IE altogether if no routing context[s] are given.
Change-Id: I19d0382cd2d428a91ac716182b9d86dcdc2c2ebd
Related: SYS#6511
If we receive any M3UA/SUA SNM SCON mesasages, distribute them
to any other active ASP to make everyone aware of the congestion
situation.
This makes STP_Tests_M3UA.TC_ssnm_distribution_scon pass and hence
should turn the entire osmo-stp test suite "green"
Change-Id: Iac7aeba980fbbd8b58f8872a29ba10745eb0a730
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
Fix wrong header and swapped user / cause values (see RFC 4666). This
makes TC_ssnm_distribution_dupu pass.
Change-Id: I717b64d13d12a2781c90e4d2f83643331797bed4
m3ua_tx_xua_asp will at some point convert the xua msg to a msgb by
copying and then send it, the xua msg still needs to be freed by the
caller.
Closes: OS#5185
Change-Id: Id8584b99f30f2db602d4d129e4114821697272ab
This quirk allows the M3UA + SUA code to accept SSNM/SNM traffic despite
being in AS-INACTIVE state. This is forbidden by the RFCs but there
are some implementations that apparently just don't care what is
specified.
Change-Id: I193dd546b3e3c00e29f192d0d1bf7819b3e194be
Closes: OS#5148
The M3UA RFC talks about this message being used in ASP->SG direction,
not the other way around.
Closes: OS#5147
Change-Id: I36ff172b47142a877b37bbd149073bef35b36a74
A DUPU message in SUA and M3UA indicates the unavailability of
a (MTP-level) user, i.e. the entire SCCP, ISUP, ... is not available.
If we receive a DUPU (destination user part unavailable) message in ASP
role, then we must
* distribute it to any other ASPs for which we operate in SG mode
* pass it as MTP-STATUS.ind to SCCP, which can then generates
N-PCSTATE.ind to the SCCP User
Change-Id: I1559ed0f761a8495b222df48c6bd43798e220471
M3UA and SUA have one sub-protocol called [S]SNM, through which the
SG informs the ASP about certain destinations (point codes) becoming
available (DAVA) or unavailable (DUNA) in the SS7 network.
This patch adds support for
* generating DAVA/DUAN on a SGP when the AS FSM changes to/from AS-ACTIVE
* receiving DAVA/DUNA on an ASP and informing other "SG role" AS/ASP
* processing DAUD from ASP received by SG, generating relate DAVA/DUNA
responses
Related: OS#2623
Change-Id: Id92be4691b0fd77598a6edb642c028bbd8c5b623
Let's factor-out the lookup of the AS into the separate function
find_as_for_asp(). This enables us to reuse this code in upcoming
support for SNM messages.
Change-Id: If58ea24efe7d54994a7ca2f0a97944bd297a8cc6
There are some M3UA implementations out there who use a routing context
during the ASPAC procedure, but who then don't use it in subsequent DATA
transmission.
This behavior seems to be at the edge of what's possible within the
spec; if you don't configure a routing context, The RCTX IE it is not
required to be sent. And if you have multiple routing contexts/AS within
one ASP, it *must* be sent. But the situation where a routing context
has been configured (but not multiple) is not explicitly covered.
Change-Id: I59f47a999f40411aadc88b8f362d8d2b89a66332
Closes: OS#4594
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
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
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-aspsm-i-003
of Michale Tuexen's m3ua-testtool.
Change-Id: I8b63e7b5e39a7ef8dd66bf014110a04f5f3dc2a2
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
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
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