The behavior here since to have changed at least a couple times in
history, always apparently breaking some compatibility:
* libosmo-sccp.git a0dd986f55
(SCCPLite MSC sends IPA ID ACK at startup) [10th July 2018]
* libosmo-sccp.git 9c0fae14d1
(Reverts back to sending IPA ID GET at startup [29th April 2021]
* osmo-ttcn3-hacks.git 3bf31d216a18c1d6a6e298a592f873beea322939
(Changes server emulation to send IPA ID ACK when BSC connects to it) [24th August 2018)
So it seems the proper way is to start handshake:
CLI <- SRV: IPA ID GET
CLI -> SRV: IPA ID RESP
CLI <- SRV: IPA ID ACK
CLI -> SRV: IPA ID ACK
However, it seems some SCCPLite MSCs (acting as IPA srv) skip the first
ID GET + ID RESP handshake and go directly for ACKs:
CLI <- SRV: IPA ID ACK
CLI -> SRV: IPA ID ACK
So, let's make everybody happy and support both cases in the client FSM.
If server sends us IPA ID ACK first, simply send back an IPA ID ACK and
be done with it, otherwise if it sends us an IPA ID GET, go for the full
handshake.
Change-Id: Ie9968ce8cd8582deb583024ff3e46736a07883fe
Reorder functions to follow usual order in FSM files:
1- structs and helper functions
2- for each state: first _oneneter, then the action func
3- generic state fsm functions (timers, all_state)
4- struct osmo_fsm_state
5- FSM allocator and public functions
Change-Id: Ic143db3dda48750effddaa0cafadf960f5b5c38c
There are implementations out there which send us traffic, specifically
in this case SCMG (SST) that has only SSN in both Called and Calling
Party. This means the inbound SST message is routed correctly to the
local SCCP user of libosmo-sigtran. But when that local SCCP user
responds with inverting Called/Calling Party, the new destination again
just contains a SSN.
As a result, we don't know where to route the message (we always need a PC).
Change-Id: Id66ae960ebe3cb3b09c6dd5454f9ac9c073f46d7
Closes: OS#5146
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 quirk is an implementation work-around in order to establish
interoperability with another implementation, either a buggy one or
one that follows a different interpretation of a given spec.
For now, we introduce a first quirk affecting when we (in ASP role)
send an ASP-ACTIVE message to the SG.
Closes: OS#5145
Change-Id: Idd947ea39d743eb1bc9342ad9d098036821da45b
We currently use the local connection ID on the SCU SAP also as local
reference on the wire-line SCCP messages. However, the latter only has
a 24 bit range, so we should make sure to wrap accordingly on
allocation.
Change-Id: I414d29271da48ac0b05a688ce9e949a66e4d0d92
Closes: OS#3921
Related: OS#3871
In IPA, unlike M3UA/SUA, we often have clients connecting from
random/unknown ports. In such cases, the configured remote port is '0'.
Let's use getsockname to determine the actual source ip/port of the
connected client (if any) during "show ... asp"
Change-Id: I1327a46d0b74c572d2ad828a958090af53b9fa37
Closes: SYS#5429
It's confusing to keep around a string representation of what peer the
socket was previously connected to.
Change-Id: I00d47fc355bfe24915653767ad75c1f491c060d5
The IPA server worked as expected, but the IPA client has some clear
logic bug that prevented it from working. It shows that we never
really use any of that IPA/SCCPlite stuff after years in spec-compliant
SIGTRAN land.
A client now first waits for the IPA_REQ, sends its IPA_RESP, then
waits for the ACK, ...
Change-Id: Icfc32cad7d65c94dc21754b8f879afcf34d34a92
The current code would potentially delete a route that was statically present in the
configuration in the following situation:
* route exists in config
* identical route is attempted to be added at AS-ACTIVE time, but fails
* route is unconditionally deleted at AS-DOWN time
* user now does 'write file' and has lost a route
Let's make sure we only delete the route if we added it previously.
Change-Id: I9ad5f7ebe0790e6c186b8ea1b12f204860a00cd2
Related: SYS#5422
Otherwise we run into the problem that a route with mask 0xffffff
differs from one with a mask of 0x3fff despite having only 14 bit
point code length and them being logically equal.
Change-Id: I5d5c828de45724d93a0461bb0dd7858fd8378acd
Related: SYS#5422
SS7 routes operate on AS level, not ASP level. However, the
automatic SS7 route creation/destruction for IPA was implemented
at the ASP level. This works for single-connection ASs, but
obviously fails in load-share situations: We attempt to add the
same route several times, and we delete it at the first ASP
disconnect, even while other ASPs still exist.
This patch moves the IPA route creation/deletion from the ASP level
to the AS level. When the AS becomes active, the route is added;
when it goes to DOWN state, it is removed.
Change-Id: Idb602beae3e9bc19f7bd96355c02ec8dfd9c5d6c
Contrary to proper SIGTRAN, IPA/SCCPlite cannot support multiple
AS within one ASP. When looking up the AS from the ASP, we cannot
blindly use routing context 0 to find the AS, as there may very well
be multiple IPA AS, and all of those have routing context 0.
As a result, the exiting look-up by osmo_ss7_as_find_by_rctx(inst, 0)
will return the wrong AS, and we will try to add/delete routes for
a completely different AS when ASPs are coming up or going down.
Instead, we need to use xua_find_as_for_asp() in order do the look-up:
It will resolve the single AS within the ASP.
Change-Id: Id295daf84f6ba1cc56cbe1761f874bea329e17ea
Cloess: SYS#5422
The xua_srv_conn_closed_cb() function is shared/generic. Let's simply
write "connection closed" to avoid any confusion. As the ASP name is
printed, it should be clear which L4 protocol was used.
Change-Id: I506ccc2665a6b0af0fde3961e7e7937af7a81219
Let's inform the user about situations in which we'd want to delete
the route for an IPA client, but we run into some problem and
bail out early.
Change-Id: Ie3f57d22901f169afb2c844476b5839cc36752aa
Related: SYS#5422
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
Previous code relied on abort() switching sigaction to SIG_FDL +
retriggering SIGABRT in case the signal handler returns, which would
then generate the coredump + terminate the process.
However, if a SIGABRT is received from somewhere else (kill -SIGABRT),
then the process would print the talloc report and continue running,
which is not desired.
Change-Id: Idca8e360968cb6998591737348ce520954e251b2
Fixes: OS#4865
Rremove osmo-stp_vty_reference from the source tree.
In manuals/Makefile.am use the new BUILT_REFERENCE_XML feature recently added
to osmo-gsm-manuals, and add a build target to generate the XML using the new
osmo-stp --vty-ref-xml cmdline switch.
Change-Id: I5bcbbdf7b737d2ce36ea877bc78c8cf191a64e1b
Depends: I613d692328050a036d05b49a436ab495fc2087ba
Related: OS#5041
Let's disable category here since we don't care about its formatting here.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Change-Id: I899e63ab2702bf25514f6585fb45f5bbf60a9ac9
Related: OS#5034
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
When a SSP (Subsystem Prohibited) or SSA (Subsystem Available) SCMG
message is received, we must generate the respective primitives towards
the SCCP user.
Change-Id: I149166a25113f5d3e3536f9297bf89ff3139b9e3
Unlike M3UA, in SUA a DUNA/DAVA message can contain not just the point
code that became available / unavailable, but it can also include a SSN.
In that case, it is just the SSN that became available/unavailable, and
not the entire point code. Hence, a N-STATE.ind and not a N-PCSTATE.ind
must be delivered to the SCCP user.
Change-Id: Ie9a45b905bc17e7b695e15fe12ba4bbadcd032bf
SCMG (SCCP Management) is a special sub-system that normally resides
at SSN=1. In Osmocom we so far ignored its existence. However,
in terms of interop with other implementation, we should implement
at least some basic features.
The only procedure implemented in this initial commit is the response
to an incoming SST (Subsystem Test) message. If we don't respond to
this message, a remote SCCP entity could assume the SSN is dead on
our side, rendering communication impossible.
Change-Id: I04b162476f7652ef0540b5ea7299e9447efd1d09
* add N-PCSTATE.ind and N-STATE.ind definitions to SCCP user SAP
* add minimal SCMG (SCCP Management) and LBCS (Local Broadcast)
* generate MTP-PAUSE.ind/MTP-RESUME.ind based on received xUA DUNA/DAVA
* generate N-PCSTATE.ind towards the local SCCP users
Change-Id: Idb799f7d7ab329ad12f07b7cbe6336da0891ae92
Related: OS#2623, OS#3403, OS#4701
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
When receiving user-data (connectionless / connection-oriented),
we must make sure that there either
a) no routing context IE in the message, and only one AS within the ASP, or
b) a valid routing context IE for an AS within the ASP
This important input validation has been done in M3UA for a long time,
but somehow never been implemented on the SUA side so far.
Change-Id: Icc232250513009137add3b45fecbb5d2a07c0645
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
We copy the contents to a static thread-local buffer to ensure
zero termination of the string received by a remote entity.
Change-Id: I8cbb7aeaf0cb64db0ce01c21e5fca9ab3cd932b6
Fix 'error: initializer element is not constant' with debian 8's gcc
4.9.2, triggered by XUA_HDR. Create a new _XUA_HDR without the type cast,
and use it inside of const struct definitions in xua_test.c. The new
macro is needed, because removing the type cast from the original
XUA_HDR would break other uses.
Related: OS#5004
Change-Id: I890432ee976043d012b01023f7dd2cfecf79d115
Pau Espin
Vadim Yanitskiy
Harald Welte
Oliver Smith