libosmo-netif (not yet released) stream_{cli,srv} osmo_io read_cb API was
updated to provide read result status. Hence, now API users (ss7_asp)
can account for lower layer errors and act properly, like it used to
do with the previous ofd backend.
This commit partially reverts some error code paths removed in
9257cd896e when converting code to use
osmo_io osmo_stream backend.
Change-Id: I579f4101a9e2874e310ff78e4571f38cfe8dfab0
Depends: libosmo-netif.git Change-Id I395c75ff1e9904757ce1d767a9ac2f779593c4c8
The event case handling (ignore it) was added in a commit some time ago,
but it forgot to add it to the allstate_event_mask in the xua_fsm (it
was added only in the ipa_fsm, which is the one using it).
This bug should in theory be harmless since the only code dispatching
the signal is not checking the return code of osmo_fsm_inst_dispatch().
Related: SYS#5914
Fixes: 5744469021
Change-Id: Iaead46bbc40b923763bc3dbe4d24d8952822de4a
This unused variable causes failures in Jenkins master build job.
Change-Id: Ifc563a7fe9006b6e412f1104cbc7e4d9b8ccae3f
Fixes: 2c9ba16 "ipa: Use pseudo-random number for SLS in IPA->M3UA direction"
In Change-Id Ice7bab997b84cfed00c7d6d780c70f4e9fac6002 we introduced
code that would make the LSB of the file descriptor be used as SLS
when passing packets from IPA in M3UA direction.
This did however not achieve sufficient entropy in real-world use cases.
In this change, we change over to allocating a pseudo-random SLS to each
IPA connection at the time it is established; We then assign that SLS
to each packet received on that IPA connection.
Change-Id: Ia4e66d660b6057338f66a47fffc8a0d32759f733
Related: SYS#6543
Closes: SYS#6802
In Change-Id Ia1910f3b99d918ec2a34d5304c3f40ba015c25c9 we introduced
osmo_io support for xUA + IPA. However, when we did that, the msgb
allocation sizes of libosmo-sigtran were neglected, and rather the
defaults of osmo_io used.
This commit returns libosmo-sigtran to the exact msgb allocation +
headroom sizes used before the osmo_io migration.
Related: OS#5752
Closes: OS#6403
Depends: libosmo-netif.git Change-Id Ie19c8294ddb12dfe5e0fd44e047c47e6f9cbd384
Change-Id: I0c6dcff4523e4c04aae43a4585b5e0c3617ef1a6
libosmo-sccp/src/osmo_ss7_asp.c:1019:16: error: 'rc' may be used uninitialized [-Werror=maybe-uninitialized]
1019 | return rc;
Change-Id: I3b1ace12eb5bb6d6b37f3374bf9986026796e166
The old/existing name says it is a connection call-back, but not what
kind of all-back; let's introduce 'rx' to indicate it is a receive
call-back.
Change-Id: Iaaef8128d4a26ea75fbce7067a8ab935a319beb4
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
This fixes a problem found by TTCN-3 testcases: two ASPs can have
identical socket address/port, but different transport protocols.
We need to take this into account in ss7_asp_find_by_socket_addr().
Change-Id: I28aab37e8967de51ad2714543fd235d407e304c5
Related: osmo-ttcn3-hacks.git I1e2a887aa22f317783b3207494fd707d7b426439
Related: SYS#5424
We saw some fall-out in automatic testing where configs with sctp-role
would suddenly save as transport-role. Let's avoid this by keeping
sctp-role for users of SCTP.
Change-Id: Ic666b62948880445e030c637298d4e369b4c7e8e
Fixes: 4d7e201 "VTY: rename 'sctp-role' to 'transport-role', add an alias"
Related: SYS#5424, OS#6380
Now that we're adding support for M3UA-over-TCP, the transport layer
role is no longer an SCTP specific paremeter, but rather a generic one.
This is also the case for the OSMO_SS7_ASP_PROT_IPA, which employs TCP,
and for which we can also choose between the client and server role.
The 'sctp-role' now becomes an alias to 'transport-role', so that
we keep backwards compatibility with old config files.
Change-Id: Iab6c898181d79a5ed2bea767ee90e55bc3af16a5
Related: SYS#5424
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
This fixes bogus messages like this one:
Received MGMT_ERR 'Invalid Routing Context':
HDR=(MGMT:ERROR,V=1,LEN=268435456), PART(T=Error Code,L=4,D=00000019)
^^^^^^^^^^^^^
Change-Id: I516e486fb7b51a25e33965ed5a0f12ab4488d240
"self.assertTrue(False)" is abusing python unittests. If you want to
fail, either call the fail() method, or simply raise an exception...
Change-Id: Ib683d6e166a9fca22dd2eb26e066e47034cda750
This allows the user to administratively disconnect the current
transport connection of a given ASP.
If issued on the client side, the default layer manager will trigger
an automatic re-connect. If issued on the server side, we expect the
client will re-connect.
Change-Id: I2077121ab860fafb70951454d029c3afa9ee2818
We've always been logging received MGMT:ERR messages, but we somehow
didn't log the transmission of them. So whenever osmo-stp generates
some error to a connected peer, the peer would show it, but not osmo-stp
itself. Let's fix that.
Change-Id: I50c05409646fd47e70d904fb95bbc2fa15703b3e
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
Pau Espin
Vadim Yanitskiy
Harald Welte
Max