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
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
IF we cannot activate the ASP in response to an ASPAC, we should
return just the error and not an error + ASPACK_ACK.
Change-Id: I681021a13af9b91d8b2b849bd7149d6b1f783865
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
Otherwise default OSMO_SS7_AS_TMOD_OVERRIDE=0 value is always set
regardless of the VTY config "traffic-mode" under AS node.
Related: OS#4220
Change-Id: I5d24772f07e77cc3ba6edfa819bb9bc0266a1064
This function is used for both actual SIGTRAN (M3UA, SUA over SCTP)
as well as for IPA/SCCPLITE (over TCP). Having a static "SCTP"
string in the log lines is confusing.
Change-Id: Ic34ddbcd528cd871d9772665e1d0863896f33203
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
If no IP addr is assigned yet, until know it'd print "(:3456". Let's
print ":34456" in that scenario.
Change-Id: Iae85d231093b6f3ce6b969324699858e525c14ea
Config file sets omo-stp instance to bind on 2 IP addresses, and then
the test verfies through linux /proc/net/sctp/* that binding is done
correctly and that it can be reached from another remote address to one
of the configured addresses.
Change-Id: Ifa11b1fc882dff415405f62024e94bed67228866
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
If an IPA ASP is sending us a SCCP message that cannot be parsed,
we shouldn't crash but handle this gracefully.
Change-Id: Ib7a8c2a36dd1b82ca8ed472760c1682ede50cb90
Fixes: OS#4236
The IPA/SCCPlite stacking is - as the name implies - constrained to
the transport of SCCP messages. We have to reject any non-SCCP payload.
Change-Id: I5e5a2879013ee8cf08aa4199b4bee498dcb61446
Fixes: OS#4235
Consider them as lost by the lower layer, otherwise lots of old messages
and retransmissions can end up queued in there until stream becomes
connected, and then will flood the peer with all those messages.
Depends: libosmo-netif.git 962bf9a48eed418354685dc733b8271d2dd62c27
Related: OS#4188
Change-Id: Ic7d3571848faf28221dcfa8eb8b33b42964d988e
When using osmo_sccp_simple_client(), it will create an sccp instance if
none exists. The sccp instance identifier starts with 0.
The implicit created instance should use sccp instance 0 (the
first connection).
Change-Id: I9d9f65555b9cdc1e3c697c8b834528d51878e1ae
Since March 15th 2017, libosmocore API logging_vty_add_cmds() had its
parameter removed (c65c5b4ea075ef6cef11fff9442ae0b15c1d6af7). However,
definition in C file doesn't contain "(void)", which means number of
parameters is undefined and thus compiler doesn't complain. Let's remove
parameters from all callers before enforcing "(void)" on it.
Related: OS#4138
Change-Id: Iedd11f816002b686f0ddb54c0cf7ba4e229e21e3
Run "make maintainer-clean" after publishing manuals, not the other way
around. Otherwise jenkins.sh fails when running for the master branch,
because docs/manuals/Makefile gets deleted although it is still needed
to publish the manuals.
Related: OS#3047
Fixes: 55f03b898a ("contrib/jenkins.sh: run "make maintainer-clean"")
Change-Id: I8bcee9069743b76966a78e1c13d0be9ba62d992c
In Id0789c4946929b783c54220de439958001f94992 I introduced the VTY
commands for talloc-context introspection, but forgot to expose
the root talloc-context.
Change-Id: Id2bf6cdae112f9791c93411c1837de488cab9ee3
Pau Espin
Harald Welte
Alexander Couzens
Oliver Smith
Daniel Willmann