This switches osmo_stream_{cli,srv} over to using the OSMO_IO
mode instead of the classic OSMO_FD mode. The difference is that
we no longer read/write directly to a file descriptor, but we pass
message buffers to/from the library.
This in turn allows the library to use more efficient I/O mechanisms
as osmo_io backend, for example the Linux kernel io_uring.
This re-introduces Change-Id: I7d02037990f4af405839309510dc6c04e36c3369
which was previously reverted due to regressions caused by a missing
change in libosmo-netif.
Depends: libosmo-netif.git I6cf5bad5f618e71c80017960c38009b089dbd6a1
Depends: libosmocore.git I89eb519b22d21011d61a7855b2364bc3c295df82
Closes: OS#5752
Change-Id: Ia1910f3b99d918ec2a34d5304c3f40ba015c25c9
This reverts commit d4ec8e7f9f
which caused severe regressions in the TTCN-3 tests: All STP_Tests_M3UA
are failing, as are STP_Tests.* and SCCP_Tests_RAW.TC_process_rx_ludt
Change-Id: I708a5fe0481b14e1b0cdc86149ffc86ee7b5be59
This switches osmo_stream_{cli,srv} over to using the OSMO_IO
mode instead of the classic OSMO_FD mode. The difference is that
we no longer read/write directly to a file descriptor, but we pass
message buffers to/from the library.
This in turn allows the library to use more efficient I/O mechanisms
as osmo_io backend, for example the Linux kernel io_uring.
Change-Id: I7d02037990f4af405839309510dc6c04e36c3369
Depends: libosmo-netif.git I6cf5bad5f618e71c80017960c38009b089dbd6a1
Depends: libosmocore.git I89eb519b22d21011d61a7855b2364bc3c295df82
Closes: OS#5752
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 Remote Address is by far the potentially largest column, as well as
the one with more variable length, so move it to the end for better formatting.
Change-Id: I4854219f8898266ae47b9117ef79dbad30a5b0fd
Until now we simply printed back the configured set of IP addresses, not
the one retrieved from the socket at the time, because we didn't have
any easy means to retrieve multiple addresses from a socket.
This is possible since recently using libosmocore APIs. Use them.
Depends: libosmo-netif.git Change-Id I1bd3f790d93af74c150938a59108b882ad2820f3
Depends: libosmocore.git Change-Id I18a0e1a652a3e8ef3e97154355eb1d07a14ef0bd
Related: SYS#6636
Change-Id: I331b6e2fe11cd97e286b7ba684d4a17b8055f9d4
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 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
Support to enable AUTH/ASCONF in the SCTP socket was added recently in
libosmocore and libosmo-netif, in order to support the Peer Primary
Address features used by the libosmo-sccp code.
The code to request the AUTH/ASCONF support through setsockopt() was
internally applied transparently by lisbosmo-netif's osmo_stream. This
is not 100% disarable since other users of the library may not need/want
that behavior.
As a result, libosmo-netif's osmo_stream no longer enables the SCTP
AUTH/ASCONF support by default, but it must be enabled through
the new osmo_stream_{cli,srv_link}_set_param() API.
This change in behavior of the API/implementation can be done because
all these new features are pretty new and no release of
libosmocore/libosmo-netif/libosmo-sccp has been released yet.
Related: SYS#6501
Related: SYS#6558
Depends: libosmo-netif.git Change-Id I2607c1c926a625986cd851adc65dd8b4de83d6ab
Change-Id: I16c97fc148792aa3e39b7414899660990c39dfff
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
Since libosmo-netif.git Change-Id
I4cb94d264109f1b763cccd44c6ba049cc7509319, we receive SCTP notifications
in both client and srv, so there's no real need to use sctp_recvmsg()
directly.
Change-Id: If3d78b636e8e224aa9c8597d0b242e29d3e3c84e
Upon connect/accept, update the name to contain both the ASP and the
sockname of the established socked. This allows easily identifying the
stream based on IP layer as well as upper xUA layer.
Example logs:
"""
stream.c:1193 SRV(m3ua,::1:2905) accept()ed new link from ::1 to port 2905
stream.c:1672 SRVCONN(asp-dyn-0,(r=::1:43568<->l=::1:2905)) connected read/write (what=0x1)
stream.c:1589 SRVCONN(asp-dyn-0,(r=::1:43568<->l=::1:2905)) message received
"""
"""
stream.c:521 CLICONN(asp0){CONNECTING} connection established
stream.c:552 CLICONN(asp0,(r=::1:2905<->l=::ffff:127.0.0.2:35911)){CONNECTED} connected read
stream.c:401 CLICONN(asp0,(r=::1:2905<->l=::ffff:127.0.0.2:35911)){CONNECTED} message received
"""
Depends: libosmo-netif.git I539a0d29d11348efe702f971965a55cf56db5c59
Change-Id: I05bc5f6c7795f62c1814c1c774287b41ee85a475
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
I would like to tweak the names for the recently added functions, so
that they are more clear -- quickly before we release it or anyone uses
these.
Depends: libosmocore I9f43428af654a5674ac3035fe4db1394aac7a7af
Related: I4c1998fd7fee7282d107846dae2cff4b5ceb3a7b
Change-Id: If381f537ab91af1feef7f0e51921217f27e18e6a
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
Harald Welte
Vadim Yanitskiy
Pau Espin
Neels Hofmeyr
Max