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
Role and SCTP Role are now printed. Several formatting issues are fixed
or improved.
Related: SYS#6488
Change-Id: Id22bd4e74fb6f79950adba58862d379203d36760
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
Add a new function similar to osmo_sccp_addr_by_name, but search in a
specific ss7 instance's addressbook instead of searching in the global
address book. This is needed for osmo-bsc-nat, which uses two separate
instances at the same time.
Related: SYS#5560
Change-Id: I0f38b0d038b0dd8cd355e7284e5b56d438811bd9
Allow user apps to relay the decision of proper default local/remote
hosts values to the library. Proper configuration of these addresses can
be quite cumbersome to get correctly, or confusing at least. That's due
to the multi-homing feature of SCTP where both IPv4 and IPv6 are
involved.
We were already doing this kind of automatic setup in
osmo_ss7_vty_go_parent(), where we do validations and assign addresses
based on IPv6 availability.
On the other hand, apps using osmo_sccp_simple_client_on_ss7_id() API
usually pass "localhost" as default address. In Linux, when IPv6 is enabled
localhost is resolved as "::1", and "127.0.0.1" when IPv6 is disabled.
Let's instead allow apps to relay the setup to the lib, so same addresses
can be applied both during VTY command as well as if there was no VTY
setup at all.
Related: OS#5186
Change-Id: I82e203612571b7651d758d8148661f706a1642ba
When libosmo-sigtran runs in ASP role, then the entire routing table
introspection (show) and routing table configuration VTY commands are
not present. Editing the routing table manually only makes sense in SG
role, but it is still useful to be able to inspect the routing table in
ASP and SG mode.
Change-Id: Ieaef4f0344b5b77ff5047013e9da1e938004e97c
Related: SYS#5392
Operators may set up a routing key in each AS node. However, this does
not mean that there is also a route added to the routing table. If the
default route is not sufficient (e.g. if multiple AS are defined), then
operators are epected to put matching routes into the routing table.
However, when libosmo-sigtran runs in ASP role, the VTY commands that
allow to routing table changes are not present.
In an ASP role we are in an endpoint situation, so no complex routing
is required, in most cases (single AS) even the default route is enough
but to ensure that each AS will get a route, add routing tables
automatically when running in ASP role.
Change-Id: Ic60b36983232308250e591dbad576aaafdd6b586
Related: SYS#5392
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
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
Otherwise it would end up attempting to connect "::" -> "1.2.3.4" which
would fail during osmo_sock_init2_multiaddr(). If local address is unset
(default), but only IPv4 addresses are set on the remote, then one must
use "0.0.0.0" instead.
Change-Id: I33faf1291e9105bba2e816c01a6b4854cf13d5e0
This patch is a fixup or extension of commit
96d348efbf, which only fixed the default
values for "asp" VTY node, but not for the xua server's "listen" node.
As a result, without this patch, by default the SCTP server socket will
only listen on IPv4's "0.0.0.0", since NULL is resolved by getaddrinfo
to it instead of "::" as first candidate.
Fixes: 96d348efbf
Change-Id: Ifbc8df854d1f1e9b07b11911ad5da8cdf9f2080a
Previous commit changed the default bind/listen address of the server
from NULL (0.0.0.0) to 127.0.0.1, hence breaking some setups where no
"local-ip" was defined and hence from then on were only listening on
localhost by default.
Let's instead bind to "::" if IPv6 is available, which covers any IPv6
and/or IPv4 address. If not available, keep binding to 0.0.0.0.
Similarly, if IPv6 is available set default remote to both ::1 and
127.0.0.1 to allow it working against processes listening on IPv4 or
IPv6 addresses.
Change-Id: Id4718267df2390f70cec519042dc12bac0cd2876
This reverts commit 0b39f2cf7b.
Reason for revert:
Breaks ttcn test suites (at least for osmo-bsc) with osmo-stp error log:
"MTP-TRANSFER.req for DPC 187: no route!"
The breakage is fixed by only reverting the NULL -> "localhost" change
back to NULL. But the commit log indicated a reason for this, so rather
reverting the entire commit for now.
Change-Id: Ia97832f4e3ed646457d5c6eeba27352f1153edec
In osmo_ss7_vty_go_parent, "127.0.0.1" is changed to "localhost" to let
local NSS decide whether to use IPv4 or IPv6. In newish systems, IPv6
::1 will be selected since IPv6 takes precedence over IPv4.
Similarly, the default source addr needs to be changed from NULL to "localhost"
since for some yet unknwon reason, getaddrinfo(AF_UNSPEC, NULL) returns
first IPv4 "0.0.0.0" and later "::", which is inconsistent with
getaddrinfo("localhost") result, resulting in src=IPv4(0.0.0.0) and
dst=IPv6(::1), which is incompatible and will fail.
In any case, this change doesn't affect users of osmo_sccp_simple_client
because the APIs set both src and dst addresses.
Change-Id: I69c48819b70635c92fa404cafd917af7802d517c
Depends: libosmo-netif.git Change-Id Ie6bb17a9af6ca21d5e350f9c9d2d74c97c5a00af
As per RFC4666 it is optional whether or not a traffic-mode IE is
part of ASPAC requests from ASP to SG. We implemented that so far
by having none as default, unless the user specified an explicit
traffic-mode in the VTY. However, we had no command to remove that
explicit configuration and return to the implicit one.
Change-Id: Ibe2b298dd76dc4b02521dc411ae9d570eaf5a9a2
When 'cs7' was added, it was generally possible to get the full automatic
configuration spelled out by using 'show running-config'. Later, the vty was
modified so that automatically configured parts were omitted.
Since figuring out the 'cs7' configuration is far from trivial, it is very
convenient to get the program's current configuration spelled out in detail,
whether it is automatic or not. For this purpose, add a new 'show' command
which simply calls the ss7 VTY's write function with a new switch to disable
all omissions.
Change-Id: I84707561a6f54851c5599c39ea9bf1d971a2a1d7
we handle this correctly in not writing the actual "asp" configuration,
but we have a bug when writing the list of asps within one "as". Let's
make sure to skip the dynamically-created ASPs there, too.
Change-Id: I1a184f3ddec2e91ced8c95ada224da8b490407a8
Closes: OS#4284
The ASP role must be saved in lowercas as the parser during config file
reading only understands it in lowercase.
Change-Id: I38b8e4d73121f8bf001037fdd2dd164113544d94
Closes: OS#4270
The code to set the default role (SG) and default SCTP role (server)
must only be executed when the ASP node is first created. Subsequent
times entering the pre-existing ASP node should not overwrite
those role settings [or any other configuration for that matter]
Change-Id: I068996a5e0d870043b652fb69a3c300adc6fda7c
Closes: OS#4271
Similar to what we do with local address. Should fix creating the stream
when no remote address is provided on an ASP configured through VTY.
Related: OS#4260
Change-Id: I33672e76a51a5d5a483906749d30e4c4e08b66ce
The M3UA specification states that either of the two roles should
be the SCTP client and the other the server. It also states that
the default for the SGP is to operate as server. However, it permits
other configurations. Let's allow this to be configured by the VTY.
We need to ensure that while in ASP role, we don't send any NOTIFY
messages to the peer SG.
Change-Id: I7452a862d45da35dcd58654ca17222eb52d26f1f
Closes: OS#2005
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
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
Several parts of the code expect an operative ASP to always have at
least one local ip addr, be it INET_ANY (NULL, 0.0.0.0) or any specific
IP address.
This allows osmo_ss7_asp_find_by_socket_addr() matching incoming
connectiongs against ASPs defined through VTY "asp" node with no
"local-ip" cmd option specified. In that case, we assume the user wants
it to bind/match against INET_ANY.
Related: OS#3608
Fixes: 80b1355819
Change-Id: Id4da0c778890c90cf5bfcf0fd3a7ecf165f2a6df
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
The IPA protocol doesn't have the context of routing-keys. We are only
permitting routing key '0' (as the default routing key) when configuring
via VTY.
Change-Id: I3f166f44903d0b93963cc5d0cca73d277d2b7215
Fixes: OS#4234, OS#4233
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
Pau Espin
Harald Welte
Oliver Smith
Philipp Maier
Vadim Yanitskiy
Neels Hofmeyr
Neels Hofmeyr