The existing/old osmo_stream_{srv,cli}_get_ofd() API functions are
only compatible with OSMO_FD mode of libosmo-netif/stream. In the
OSMO_IO mode, there is no osmo_fd involved, and hence those functions
are illegal to call.
Let's instead migrate over to the new osmo_stream_{srv,cli}_get_fd()
which directly return the file descriptor integer value.
Change-Id: I12c66badfb4bdfdfe71f1716de960d353d3548b1
Related: OS#5752
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
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
Harald Welte
Pau Espin
Oliver Smith
Philipp Maier
Vadim Yanitskiy
Neels Hofmeyr
Neels Hofmeyr