In order to catch invalid CS7 configurations, It is necessary
to check if sccp addresses contain plausible address data.
Change-Id: Ic6245288b0171eae10aa708403c1ddb584c92f38
The most important parts of an SCCP address are the routing
indicator and the pointcode. The latter one is always available
via the SS7 instance, so a basic local address can be derived
from there.
Add function osmo_sccp_local_addr_by_instance() to derive a basic
local SCCP address from a given SCCP instance
Change-Id: I371dc9132871aad3d8321ea13cf9fd69d76eff8f
The sccp-addressbook only allows defining addresses for a specific
ss7 instance. It is not possible to use an sscp-address, that is
defined in the one ss7 instance in another ss7 instance.
Add a second global list where all sscp-addresses are added,
regardless on which instance they are defined.
Fixup the search functions so that they always search the global
list.
Change the API, so that the address data is written to a
destination pointer. This protects the stored address from
unintentional changes. Also return the ss7 instance, where the
address is associated with.
Change-Id: I5acc1e5abc3b3081149a9f476038e4e53d23b763
SCCP addresses are defined through a number of compoinents, not
just an IP-Address, there is also point code, ssn and more. To
simplify and unify the handling of such objects, this patch
introduces an addressbook functionality. The user can set up
multiple addresses per ss7 instance and give them names. Later
that name can be used to reference the address at a later point
in the config. This means that the usage of sccp-addresses from
the programmers point of view boils down to a VTY function that
reads the string name of a previously defined address. The
programmer can then use the API to get a pointer to the SCCP
address struct and use it normally.
For this feature, two additional VTY nodes are necessary,
this commit depends libosmocore change:
Change-Id I42aa29c0cccc97f284b85801c5329b015b189640
Change-Id: I068ed7f7d113dab88424a9d47bab7fc703bb7942
as 'struct osmo_sccp_instance' is opaque to the user application, it is
useful to have an accessor function that resolves the ss7 instance used
by the SCCP instance.
Change-Id: I8057a6d69584239b9781c5cece42066293ea1dd6
As 'struct osmo_sccp_user' is private, we need this accessor functions
for the SCCP User so it can set and get the 'priv' data.
Change-Id: Ia68a36dc18a7d754d63ae29c86d68e495b5c4134
This is an implementation of SCCP as specified in ITO-T Q.71x,
particularly the SCRC (routing), SCLC (Connectionless) and SCOC
(Connection Oriented) portions. the elaborate state machines of
SCOC are implemented using osmo_fsm, with one state machine for each
connection.
Interfaces to the top (user application) are the SCCP-USER-SAP and on
the bottom (network) side the MTP-USER-SAP as provided by osmo_ss7.
Contrary to a straight-forward implementation, the code internally
always uses a SUA representation of all messages (in struct xua_msg).
This enables us to have one common implementation of all related state
machines and use them for both SUA and SCCP. If used with real SCCP
wire format, all messages are translated from SCCP to SUA on ingress and
translated from SUA to SCCP on egress. As SUA is a super-set of SCCP,
this can be done "lossless".
Change-Id: I916e895d9a4914b05483fe12ab5251f206d10dee
libosmo-sigtran is GPLv2-or-later, there were some files that
accidentially had an AGPLv3 license header, which was a copy+paste
mistake at that time.
Change-Id: I67dfd0ae6157afafd3873a3baaa4c6107c04ddfd
This is more natural to most application code, so simply go for ASCII
string with NUL-termination rather than an array with explicit length.
Change-Id: I6312208cdfa83184be41157a473c96e9120c63db
By accident, I already fixed this typo in osmo-iuh, breaking the build. Instead
of reverting there, fix it here.
Change-Id: I4076fb37c0d94be7adff46e76465884a61c54c9a
143 is actually the SSN for RNSAP. Wireshark displayed a RNSAP message type
and malformed packet warning until I fixed this to 142. Now I get the proper
RANAP and id-Paging reported.
There has been a reallocation for RANAP and RNSAP SSNs, though the old SSN for
RANAP is apparently 32 (seen in a pcap from a real 3G network). When I send 32
instead of 142, wireshark also decodes the message as valid RANAP.