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
The ipv4 addr in addr->ip.v4 is already in network byte order, as it's
usual in struct in_addr (see sua_addr_parse_part()).
So the code in there was simply calling ntohl() because
msgb_t16l16vp_put_u32() is calling htonl() on the given parameter before
storing it. Let's simply use msgb_t16l16vp_put() directly and avoid a
double byte swap which only adds confusion.
Change-Id: I70a94ee1b459d56116f0c6a6c7c3b778a939b7ea
Harald Welte
Pau Espin
Oliver Smith
Philipp Maier
Vadim Yanitskiy
Neels Hofmeyr