Now that we're adding support for M3UA-over-TCP, the transport layer
role is no longer an SCTP specific paremeter, but rather a generic one.
This is also the case for the OSMO_SS7_ASP_PROT_IPA, which employs TCP,
and for which we can also choose between the client and server role.
The 'sctp-role' now becomes an alias to 'transport-role', so that
we keep backwards compatibility with old config files.
Change-Id: Iab6c898181d79a5ed2bea767ee90e55bc3af16a5
Related: SYS#5424
RFC 4666 section 1.3.1 states that "TCP MAY be used as the underlying
common transport protocol" under certain scenarios. There is even
IANA-allocated TCP port 2905 for that purpose (see section 1.4.8).
Since TCP is a stream oriented protocol, so we need to handle message
boundaries ourselves by reading the M3UA header to know the PDU length.
Change-Id: I8c76d271472befacbeb998a93bbdc9e8660d9b5d
Related: SYS#5424
The socket is reconfigured (and hence reopened) upon VTY node exit if
changes were stored in the address list of the xua_server
(osmo_stream_srv_link).
Related: OS#4607
Change-Id: I942edff7695efeea7753f22e31c2098c201290ff
The local address is removed dynamically from the socket if it is
already created. For remote addresses, it doesn't make any sense (and
there's no API to do so) because the remote address list passed to it is
only used at connect() time, when the socket is created. During the
initial hanshake, the remote provides its own list of remote addresses.
Related: OS#6077
Related: OS#4607
Depends: libosmocore.git Change-Id Ifc6e7d643c2a0c53f479bfd0d5c36d08c0c01953
Change-Id: I554aee92285bd72eb90c6daf47b37055cb3067aa
This is an initial implementation to set the local SCTP Primary address
as well as the peer's Primary Address (through SCTP ASCONF messages).
The Primary address is only set upon conn establishment (after connect()
for clients, or accept() for severs), which means no logic is
introduced to make sure that primary address is kept during the entire
operation of the SCTP association (for instance if the Primary address
becomes unavailable and the stack changes the primary, and later on that
address becomes available again, the primary addres won't be set back to
the initially configured one).
Related: OS#6076
Change-Id: I4a9fc1a4ad82ed20ece328bc53fca58299d744ca
Some apps such as osmo-bsc are accessing some of those fields, so better
add a getter API to make it easier to update the struct contents.
Change-Id: If9acfca1abc9ab7eb6d2388f548d7ee577b9c5ac
A recent commit (83db938859) changed the
behavior of default "sctp-role" and "role" values of ASPs named
asp-clnt-* which are used by osmo_sccp_simple_client_on_ss7_id(), in
order to avoid having different default values when than function is
used, which is totally confusing for end users.
As it was already informed when submitting the mentioned commit, it
changes the behavior on that specific case, and that made some users
start having problems without a proper "your config is wrong!" error.
This commit addresses it by basically forbiding that exact use case,
that is, partially defining an asp-clnt-* ASP through VTY without
explicitly configuring a "role" and "sctp-role". With this patch,
function osmo_sccp_simple_client_on_ss7_id() will print a proper error
informing the user and will return NULL, potentially triggering an early
program exit which can then easily be fixed by using proper
configuration.
Related: SYS#6486
Change-Id: I65b5fad2ec06a9d9c521f1e3ce8aab633da95a47
The VTY config defaults are "role sg" and "sctp-role server".
However, if not set explicitly in VTY,
osmo_sccp_simple_client_on_ss7_id() was replacing them to "role asp" and
"sctp-role client".
This is fine if the ASP is not defined/created at the VTY (aka
dynamically created with no config), but if the ASP is defined in the
VTY it becomes really confusing, since it's picking different defaults
than the usual ones.
Hence, follow always the same VTY defaults in
osmo_sccp_simple_client_on_ss7_id().
As a result of this change:
- Programs not defining the ASP over VTY keep the same behavior (ASP is
created with role=asp and sctp-role=client)
- Programs defining ASP over VTY (eg. "asp asp-clnt-msc-0 5000 0 m3ua")
explicitly setting "role" and "sctp-role": keep the same behavior
- Programs defining ASP over VTY but not explicitly setting "role" or
"sctp-role", will get now the usual defaults instead.
So in summary, strange cases where osmo_sccp_simple_client_on_ss7_id()
is used (osmo-bsc, osmo-hnbgw, osmo-msc) and the dynamically created
ASP is created through VTY, then the config file must also explicitly
define the following lines:
role asp
sctp-role client
This patch also changes the "show running-config" VTY cmd to also always
show the configured role and sctp-role values, which are of vital
importance to understand a given setup.
Change-Id: Ie81987265118e48173211f88b27a006115dc62d4
Right now, if a user configures an cs7 instance, as and asp (with
sctp-role server) in the VTY, then the function
osmo_sccp_simple_client_on_ss7_id() (used by osmo-bsc, osmo-msc,
osmo-hnbgw, etc.) will silently change the config to be SCTP client.
This is really confusing, since the user configured explicitly the ASP
as server but ends up running as client.
Instead, if the user explicitly configured the ASP as SCTP server,
allow it (after validating the user also properly configured a xUA
server through VTY).
Change-Id: I20de33edb8751a515d6719c49efadfc387dd85f8
So far, the optional data limit can only be modified via cs7 VTY,
because struct osmo_sccp_instance is private. Provide public API to set
this limit from C.
Change-Id: If3d22a0f65a7ed0be043027652402b32c356e322
The attempt to route message via AS which is down will fail anyway:
let's make it explicit.
Add osmo_ss7_as_down() and use it to check AS state before transferring the message.
Change-Id: I0d5f3b6265e7fdaa79e32fbc30f829ef79e7dad1
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
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
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
The code managing addresses is decoupled from xua_server since they will
also be used to manage addresses for ASPs.
Change-Id: I4af2a6915ac57c7baa67343bd9414c65154d67f7
This is like osmo_ss7_asp_find_and_create(), i.e. it's doing a full
match for an ASP within the specified SS7 instance, of the specified
port numbers. It just doesn't create it if it is missing.
Change-Id: I1ed3cf2b69ee622d6f9d8b50487f392fe913ae90
Related: OS#4271
So far, we had a static role model:
* SCTP servers (listening, such as OsmoSTP) are role SGW
* SCTP clients (connecting, such as OsmoMSC) are role ASP
While this is customary, it is not actually required by the
specification. The SGW can establish the SCTP connection to an ASP
but still remain "SG" role.
Let's make things more flexible by having the role configurable.
Related: OS#2005
Change-Id: I2df9cd9747ad5c9a05d567d9a71bab6184c53674
If the AS is e.g. configured as broadcast, then individual ASPs cannot
be activated in loadshare or override. Everyone must agree.
Change-Id: Ic73410fbc88d50710202453f759fa132ce14db4c
RFC 4666 (SS7/MTP3/M3UA) states in isection 4.3.4.3 ASP Active Procedures:
"""
If the traffic handling mode of the Application Server is not already known via
configuration data, then the traffic handling mode indicated in the
first ASP Active message causing the transition of the Application
Server state to AS-ACTIVE MAY be used to set the mode.
"""
In section 3.6.1 Registration Request (REG REQ), no related information
is provided on how to handle it, but still makes sense to apply same
behavior as in 4.3.4.3.
Related: OS#4220
Change-Id: Iaebe3a93ad8d2d84ae01e41b02674f8ece9dfc95
After this patch, Several "local-ip" and "remote-ip" lines are accepted
under "listen" and "asp" VTY nodes, allowing to configure an SCTP
connection with multiple connections, hence allowing control of SCTP
multi-homing features.
libosmo-sccp clients such as osmo-bsc and osmo-msc also gain support for
this feature with this commit.
Related: OS#3608
Depends: libosmocore.git Ic8681d9e093216c99c6bca4be81c31ef83688ed1
Depends: libosmo-netif.git I0fe62f518e195db4e34f3b0ad1762bb57ba9d92a
Change-Id: Ibd15de7a4e00dbec78ff2e2dd6a686b0f3af22de
Commit 10d4815bb1 already fixed the issue
where binding was done during L_CS7_XUA_NODE (listen) done, meaning
local-ip inside it had no effect. In that comment, binding was moved to
happen during "local-ip" VTY cmd. Furthermore, that commit added a new
osmo_ss7_bind_all_instances() and related APIs to allow osmo-stp to have
all xua servers bound if no "local-ip" was provided.
These APIs have only been used so far by osmo-stp (which lays in the
same git repo that libosmo-sccp) since it's the only program using the
xua server features.
In the present commit, let's drop the APIs added by commit described
above, and instead let libosmo-sccp code to internally bind the xua
server upon exit of the VTY node. As a result, the previously introduced
APIs can be dropped (not used by anyone anymore) and it will provide
ways to support multiple "local-ip" commands in the future, hence
supporting SCTP multi-home features.
It's recommended to require libosmocore.git Ia6d88c0e63d94ba99e950da6efbc4c1871070012
since it fixes a bug where go_parent_cb was not called for nodes at the
end of the file.
Related: OS#3608
Change-Id: I2cff17b5e2e2fbfd4591e23a416e510e94e173d6
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
We were printing the mask of the route, but not the point code itself.
Best would probably be to print both?
Closes: OS#3835
Change-Id: Ifa4fdbad953d40f222beb470a082eed8c20991ef
That's useful for external programs veryfying pointcode validity. For
example if used as part of BSS-related identity in GCR construction by
LCLS code we should be able to double.check that no significant bits off
pointcode are lost/ignored.
Change-Id: I5a9981dd2c1d78966c61a3f6b50c7c0d9b542caf
When saving the current VTY config to a configuration file,
do not write out AS/ASP configuration items which are generated
as a fallback by osmo_sccp_simple_client_on_ss7_id().
Since the user did not explicitly configure these configuration
items they should not be saved to the user's configuration file.
Change-Id: Id8a3afc6dee29ae1ee9c862cbe404a61fe979dba
Related: OS#3616
Instead of allocating ss7->sccp in various places, unify that in one common
function. We shouldn't spread the decision what to pass as priv pointer around
everywhere. There is no functional difference.
This is preparation for a patch where the sccp_instance gets allocated from the
telnet VTY: I would prefer to hide all allocation details from that code; which
also makes sense for the other callers of osmo_sccp_instance_create().
Change-Id: Ie912898c66d31ce4ac8eeeea5a6ddc3f821c06f7
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
There is a naming dilemma: though the osmo_ prefix is now reserved for
libosmocore, all surrounding API already has the osmo_ prefix.
This will be used by osmo-hnbgw's VTY 'show cnlink' command.
Change-Id: Ia0d15a2814b08bc3f052a1ed12dbb68bade55309
In osmo-stp, cmd "local-ip" inside node "listen m3ua 2905" was actually
not being applied, because the server was created + bound at "listen" command
time using NULL as IP, and at "local-ip" time the IP was changed but the
server was not re-bound using the new IP, so it kept listening at
0.0.0.0.
With this patch, we defer binding the socket to "local-ip" cmd time,
after the IP has been applied.
As a result, if no "local-ip" command is provided, then the bind never
happens, which means it is now mandatory that users of osmo_ss7_xua_server_create
API not using osmo_ss7_xua_server_set_local_host call new provided API
osmo_ss7_xua_server_bind. Another new API osmo_ss7_bind_all_instances is
provided to easily make sure all servers are bound after configuration
process. This is specially important for servers which doesn't contain
the "local-ip" parameter.
Users of osmo_sccp_simple_server API are not affected by this change,
and they not requrie to call any new API.
Furthermore, using osmo_ss7_xua_server_bind in VTY code ensures the xUA
server is automatically bound to the new address if the operator changes
the "local-ip" cmd at runtime.
Related: OS#2647
Change-Id: I79738963d633bec70705ff159c5b2127cd498aa2
The simple client takes certain parameters (pc, ip and port
numbers) which serve as a fallback default in case the user
did not configure any suitable parameters via the VTY.
Prefix all default variables with default_ to make the
purpose clear to the API user
Change-Id: Id9e697e8b198e4f58a79e59aaf2e649e84a3eb63
Introduce OSMO_SS7_PC_INVALID to mark an unset point code.
Add static osmo_ss7_pc_is_valid() (name matches schema of
osmo_ss7_pc_is_local()).
In osmo_ss7_pointcode_print(), return "(no PC)" if !osmo_ss7_pc_is_valid(), for
convenient printing of any PC state.
Subsequent patches will use this for
osmo_ss7_instance (I7f0f0c89b7335d9da24161bfac8234be214ca00c)
as well as osmo_sccp_user (I8684c9b559712072c772012890bbf7efa7c8eb35).
Rationale:
Currently, in osmo_ss7_vty.c we had "if (inst->cfg.primary_pc)" suggesting 0 is
invalid, but in struct osmo_sccp_user we have flag pc_valid suggesting 0 is
indeed valid. All known point code formats are <= 24bit, so we can easily use
0xffffffff as indicator for an unset PC, which removes the need to remember to
set a second field for validity and keeps the structs nice and lean.
Change-Id: Ib5715bf03a4de7713a7a809dfd821c700255ba8c
Drop the separate osmo_ss7_set_vty_alloc_ctx() because we are likely to forget
calling it. Instead, incorporate into osmo_ss7_vty_init_*() with a new ctx arg,
and set the static context var in vty_init_shared().
Change-Id: Id4e7f47979001f7856b0b3665c9e94982e75e490
The osmo_sccp_simple_client_on_ss7_id and osmo_sccp_simple_client
are not entirely configurable via VTY commands. The relation to
the VTY is implicit. The user may set up instance objects via
VTY (cs7/ss7, AS, ASP), which are then automatically created on
startup.
Each cs7 instance gets its own ID via the VTY configuration. When
osmo_sccp_simple_client_on_ss7_id() is called with the cs7 instance
id. (for osmo_sccp_simple_client() the ID will be hardcoded to 1),
the function automatically checks if the CS7 instance is present,
if not it will create one automatically using the caller supplied
parameters as a defult. If a CS7 instance is present, the function
checks for the presence of an AS and an ASP. These objects are
present, they will be used. If not, new objects will be created.
Both functions must not be called if an SCCP instance is already
present. Since there can only be one SCCP instance per CS7 instance,
this is an error condition.
Add additional logic that checks to detect an already existing, valid
configuration. If no or an insufficient configuration is detected,
use the caller supplied parameters as default configuration.
Change-Id: I293f3526ce6182dca74a169a23449dbc7af57c7c
osmo_sccp_simple_client() and osmo_sccp_simple_server() are binding
on the ss7 instance with the id 1 by default. If the instance does
not exist, it is created automatically.
Allow choosing the ss7 instance by supplying the id number as
function parameter. Add two new functions:
osmo_sccp_simple_client_on_ss7_id()
osmo_sccp_simple_server_on_ss7_id()
Change-Id: I62e608253212415bddbb4c7dcf5d3b5e79c8d28e
Vadim Yanitskiy
Pau Espin
Neels Hofmeyr
Max
Harald Welte
Philipp Maier