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
A recent patch fixed a long problem where the ASP name (instead of
expected AS name) was used as ipa_unit_name in IPA based ASPs.
For server side it doesn't matter much, sense anyway the ipa_unit_name
is actually restored on the struct with what's received in IPA GET_RESP
message (see ipa_asp_fsm_wait_id_resp()). So the fix was actually for
the client side in the scenario where a non-dynamic ASP with an assigned
AS was configured in the VTY.
However, dynamic ASPs usually have no assigned AS (because in general it
is really not created/configured, as the ASP is created on the flight).
As a result, the recent patch (see "Fixes" below), broke dynamic ASPs
case because from then one ipa_asp_fsm_start() would fail and terminate
the FSM because ipa_find_as_for_asp() was returning NULL.
So improve the recent patch by applying the previous logic for dynamic
ASPs:
* On the server side, it really doesn't matter since as mentioned, the
field will be repopulated later on, but allows the code to avoid
terminating the FSM and hence be brought up and be ready to receive
clients.
* On the client case, this is how dynamic IPA ASPs were ment to be used
when they were introduced anyway (use ASP as ipa_unit_id, meaning
"AS name" == "ASP name").
Furthermore, on the client side, the non-dynamic IPA ASPs need their
bring up be delayed until assigned to an AS, because the AS name is sent
in ipa_unit_name field in Tx IPA ID RESP.
This usually happens at a later point than ASP (FSM) creation, because
first the ASP object is created (through VTY or API) and then assigned
to an AS through osmo_ss7_as_add_asp() usually from a later "asp" vty
command in the "as" node.
Fixes: 65741dca05
Change-Id: I0a741449450c998253b1e44a76a3b7fc224e0903
Related: SYS#5914
Allow printing only a specific asp by name. Useful when user is only
interested in a uniqe ASP and there's lots of them configured.
Related: SYS#6636
Change-Id: I08426272069ce5f3c8403b08dcaf686547bee336
Until now, we were in general printing the list of remote addresses that
were stored in config, because we didn't have an easy way to retrieve
the addresses from the socket. Since recently some libosmocore APIs make
that easy, so use them now.
If the socket is not yet created, then log the addrress list from the config.
Furthermore, take the chance to print now both local and remote
addresses.
Related: SYS#6636
Change-Id: I607e4c2dd37f07bf1c07c88681918184e92202ea
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
This was broken since ever. The client was submitting the ASP name
in the unit_id field during IPA handshake, and the server was
expecting it to contain the AS, so it failed with message:
"Cannot find any definition for IPA Unit Name '%s'" in
ipa_asp_fsm_wait_id_resp().
Fixes: 5f0a8df34c
Change-Id: I249964e171f578726439c40e01ae85aa447afada
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
Scenario: RUA Connect triggers SCCP CR towards peer, and we move to
CONN_PEND_OUT state where we expect to receive CC.
However, if some timer (like X31) times out before we receive CC (eg
because CC takes a long time to come), we end up in state
WAIT_CONN_CONF.
In that state, according to Figure C.2/Q.714 (sheet 2 of 7), among other
possibilite we wait for CC, and if it arrives, we send an RLSD to the
peer to inform him that we released the conn, and wait
for the peer to ack the RLSD, then release all state.
Given the scenario above, scoc_fsm_wait_conn_conf() was not assigning
the received OPC from the CC to the conn->remote_pc (unlike
scoc_fsm_conn_pend_out() which does it properly). As a result, when
trying to send teh RLSD it would fail and never transmit RLSD, taking
then a long time to release through T(rel) (10-20 seconds), and probably
longer in the peer (T(iar) or similar?).
Rua Connect triggers tx of SCCP CC:
Received SCCP User Primitive (N-CONNECT.request)
XUA_AS(as-clnt-msc-0)[0x55f11c7df980]{AS_ACTIVE}: Received Event AS-TRANSFER.req //Tx CC
SCCP-SCOC(929)[0x55f11c909c90]{IDLE}: State change to CONN_PEND_OUT (no timeout)
...
X31 timeout triggers state change:
map_sccp(...-SCCP-929)[0x55f11c909820]{wait_cc}: Timeout of X31
SCCP-SCOC(929)[0x55f11c909c90]{CONN_PEND_OUT}: Received Event N-DISCONNECT.req
SCCP-SCOC(929)[0x55f11c909c90]{CONN_PEND_OUT}: State change to WAIT_CONN_CONF (no timeout)
...
CC arrives, but conn_remote_pc is not properly assigned and tx of RLSD fails:
SCCP-SCOC(929)[0x55f11c909c90]{WAIT_CONN_CONF}: Received Event RCOC-CONNECT_CONFIRM.ind
MTP-TRANSFER.req from SCCP without DPC?!? called=RI=0 // PROBLEM HERE!!!!
SCCP-SCOC(929)[0x55f11c909c90]{WAIT_CONN_CONF}: State change to DISCONN_PEND (no timeout)
...
SCCP-SCOC(929)[0x55f11c909c90]{DISCONN_PEND}: Received Event T(rel)_expired
Related: SYS#6616
Change-Id: I9f9f78c92dd95f38af7b03037e60a1c993d7e5b0
This allows starting SCCP conns from within sccp_demo_user, which in
turn allows testing more scenarios in osmo-ttcn3-hacks.git
SCCP_RAW_Tests testsuite.
Related: SYS#6616
Change-Id: I7d5b3534c496dca8a3f3e66025af554bbe860c04
When operating an IPA ASP in server mode, we were not counting the
packets using the related stat item:
For example:
OsmoSTP# show stats
Ungrouped counters:
SIGTRAN Application Server Process (6)('asp-dyn-5'):
Total number of packets received: 0 (0/s 0/m 0/h 0/d)
Total number of packets transmitted: 235370503 (129/s 7682/m 442447/h 11342653/d)
This patch adds the missing counter increment.
Change-Id: I75881d115b5c2c2567c4731bcf2cabe11f367117
Closes: SYS#6600
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 makes it easier to find out where the AS struct is allocated, plus
also split between inst code looking up + checking + allocating and the
code doing the allocation and initialization of the AS.
Change-Id: Ie237ec8ac4b2e15b76fce3b3a56f47a59fdcc76e
* LUDT/LUDTS is now properly received and passed along to the app.
* LUDT/LUDTS is now used if the data to transmit spans more than 255
bytes.
Related: SYS#6566
Change-Id: Ic91abfc921f5e4f36045bfa325333112cddd9fa6
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 allows having a clearer picture of the several entities involved,
as well as simplifying the files.
In the future, we can do the same for AS, route, etc. and leave osmo_ss7
for the "instance" object.
Change-Id: I3d43268459d61b0b9f9bec34bf31dc0851fa5e48
when IPA/SCCPlite traffic traverses the osmo_ss7 stack, so far the
SLS of the MTP3 label was always set to 0 (default initialization).
However, in order to achieve a better distribution of signaling traffic
in SS7 networks that actually utilize the SLS to select any links (or
ASPs), it makes sense to use non-zero values.
Instead of introducing some kind of new, configurable attribute for
each ASP (IPA client connection), let's simply use the lower 4 bits of
the file descriptor integer. Those file descriptors should have a
roughly equal distribution, resulting in traffic (from multiple IPA
clients) to be spread across the 4-bit SLS number space.
Also, this mechanism ensures that traffic from one IPA client will
always get the same SLS and hence routed the same way in any underlying
CS7/SS7 network.
Change-Id: Ice7bab997b84cfed00c7d6d780c70f4e9fac6002
Related: SYS#6543
The kernel doesn't store state about a "always-preferred" Primary
address, it simply applies the requested one at the time the request is
done. If afterwards the remote address becomes unavailable, the kernel
will end up giving up on it and selecting anoter one as primary address.
If the VTY-configured Primary Address become available after a while
(signaled by the kernel in the SCTP_PEER_ADDR_CHANGE), make sure to
apply it again.
Similary, if the peer sends us an ASCONF changing our Primary Address,
we should discard that and apply/overwrite *iff* the user explicitly
VTY-configured one (kernel announces the change through
SCTP_ADDR_MADE_PRIM in this scenario).
Related: OS#6076
Change-Id: I2e54e6f9e424350474db6dec6ab604b33a03f88b
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
Andreas Eversberg
Harald Welte
Vadim Yanitskiy
Pau Espin