The ipv4 addr in addr->ip.v4 is already in network byte order, as it's
usual in struct in_addr (see sua_addr_parse_part()).
So the code in there was simply calling ntohl() because
msgb_t16l16vp_put_u32() is calling htonl() on the given parameter before
storing it. Let's simply use msgb_t16l16vp_put() directly and avoid a
double byte swap which only adds confusion.
Change-Id: I70a94ee1b459d56116f0c6a6c7c3b778a939b7ea
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
Until now, host list validation was only taking into account a set of
ipv4-only addresses. As a set can contain now IPv4 and Ipv6 addresses at
the same time, we need to do ANYADDAR validation against addresses of
that specific version inside the set.
Change-Id: I18f3cc59149d478259d7afc456bdc5213c1406e5
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
A message like
DLSCCP <0011> sccp_scoc.c:1653 Cannot find connection for local reference 1154
is not incredibly useful, as you don't even know what type of SCCP/SUA
message had been received.
Change-Id: I18af9d7e9ea4877b13bf98a980b0ba97c5ed6599
Our manuals explain that the cs7 config automatically adds missing parts.
However, previous code requires an ASP to exactly match the default name that
the autoconfiguration would choose -- that is unintuitive.
If a config included only an ASP, or both AS and ASP but omitting to add the
ASP to the AS, auto configuration would pick it up iff it exactly had the name
the application chose. For osmo-bsc, that was 'asp-clnt-msc-0', if 'msc 0' is
the first MSC in the config file. For osmo-msc, it is 'asp-clnt-OsmoMSC-A' or
'asp-clnt-OsmoMSC-A-Iu' and so forth, so it is not always clear which name the
user should pick to get the ASP used by auto config.
Refactor so that any ASP with a matching protocol that is not associated with
any AS yet is picked up by the auto configuration, i.e. associated with the AS
etc., regardless of the name chosen in the config file.
Related: OS#4635
Change-Id: I2954e0167729fd0b1a7d0144a5b5775fc1c44c35
In I9b3ae6dfcf6efeabb7fb6c33503d1d7924fec2fa we fixed some problems
regarding rapid open/close cycles of inbound M3UA client connections.
Unfortunately the fix now triggered another bug.
xua_srv_conn_closed_cb() is called by libosmo-netif stream code whenever
a connection (socket) is closed. As the stream_server is de-allocated
right after this call-back, the call-back must make sure to remove
any pending references to the stream_server.
Change-Id: I2464cf524f1f91bfad10ff1861a03bf1461dfed8
Related: OS#4625
This reverts commit ec20a6164b.
Reason for revert: this patch makes specific variants of 'cs7'
config fail. In short, if AS and ASP are configured and connected,
the ASP is never started. See OS#4635 for elaborate details.
Related: OS#4635
Change-Id: Id6e1fd69f312e5dc74e8718b2e2e678ad54bc16b
When a client closes and instantaneously re-opens a SCTP socket for an
M3UA connection, there is a chance that both the "shutdwon event" (old
connection socket becomes readable for sctp event) and the "init event"
(listen-fd becomes readable) happen during the same scheduler interval /
select() cycle. As there is no guaranteed order by which we call our
file descriptor callbacks, it means that we may end up processing
then new connection (accept) before we get the notification that the
old one is dead.
The fact that the fd number of the accept-fd is mostly lower than the fd
number of the individual per-client connection actually makes it likely
that the order is exactly the opposite of what would feel "logical".
As the ASP is identified by the tuple of (src-port, src-ip, dst-port, dst-ip),
both the old connection and the new connection map to the same ASP
object. So we need to handle this situation gracefully: If we get a
new connection for a tuple that we already [think we still] have one,
close the old one and use the new.
Change-Id: I9b3ae6dfcf6efeabb7fb6c33503d1d7924fec2fa
Closes: OS#4625
In osmo_sccp_simple_client_on_ss7_id(), only call osmo_ss7_asp_restart() if the
ASP was created by that function. If a previously existing ASP was re-used, do
not restart it.
Background: Recently, osmo-bsc started calling
osmo_sccp_simple_client_on_ss7_id() multiple times, once for each configured
MSC in an MSC pool. Normally, that ends up re-using the same ASP and SCCP
client, so should not change anything. Still, it turns out that the SCTP
association was re-launched for every configured MSC, which is obviously not
necessary when using the same SCCP connection and SCCP user for multiple MSCs.
That happened because osmo_sccp_simple_client_on_ss7_id() calls
osmo_ss7_asp_restart() even if a pre-existing ASP is re-used.
The rapid restarts also uncovered a problem in osmo-stp, causing it to crash --
that is a separate issue.
Independently from an osmo-stp fix, this change should in fact avoid the
osmo-stp crash and fix the sporadic massive ttcn3-bsc-test fallout we're seeing
since merging the MSC pooling feature to osmo-bsc.
Related: OS#4625
Change-Id: I62443edd681a2ec1b38f958520e907f9a7ef285e
There are some M3UA implementations out there who use a routing context
during the ASPAC procedure, but who then don't use it in subsequent DATA
transmission.
This behavior seems to be at the edge of what's possible within the
spec; if you don't configure a routing context, The RCTX IE it is not
required to be sent. And if you have multiple routing contexts/AS within
one ASP, it *must* be sent. But the situation where a routing context
has been configured (but not multiple) is not explicitly covered.
Change-Id: I59f47a999f40411aadc88b8f362d8d2b89a66332
Closes: OS#4594
Though, since in current practice, not many users exist, and all incoming
messages have a valid PC, this is unlikely to have any noticeable effect.
Change-Id: I3533a01e29b97bebe4b8f1f6965444519b3bacfe
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
To allow osmo-bsc to add more than one MSC peer on a single SCCP instance, it
must add a local SCCP user only once per SCCP instance. The first configured
MSC adds a local user, all subsequent MSC should use the same local SCCP user.
So, it is most convenient to provide a public function to return such user if
it exists.
Add as thin wrapper instead of renaming and moving the internal
sccp_user_find(): to keep the patch smaller, and to match the way
osmo_sccp_user_bind_pc() is a 1:1 wrapper for sccp_user_bind_pc().
Related: OS#3682
Change-Id: I9ecbab16b45268f626950303d6ff8296dd6acda0
sccp.c uses #ifdef OSMO_IS_LITTLE_ENDIAN, but fails to include endian.h, i.e.
it would build little endian also on big endian systems.
Found by libosmocore/contrib/struct_endianness.py.
Change-Id: I5906d94e0e0a74674c3a14cf2ec81c681e696474
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
Those values (except for XUA_T_ACK_SEC) are not used at all, and anyway
they already exist as timers in osmo_sccp_timer_defaults (sccp_scoc.c).
Change-Id: Id5902e809e02b2651e381cd58ef97b77c1143dc2
All other code paths moving to state DISCONN_PEND seem to stop them, and
anyway that state doesn't permit event SCOC_E_T_IAS_EXP:
DLSCCP DEBUG SCCP-SCOC(0){ACTIVE}: Received Event T(iar)_expired (sccp_scoc.c:346)
...
DLSCCP DEBUG SCCP-SCOC(0){ACTIVE}: state_chg to DISCONN_PEND (sccp_scoc.c:1095)
...
DLSCCP DEBUG SCCP-SCOC(0){DISCONN_PEND}: Received Event T(ias)_expired (sccp_scoc.c:339)
DLSCCP ERROR SCCP-SCOC(0){DISCONN_PEND}: Event T(ias)_expired not permitted (sccp_scoc.c:339)
Change-Id: Ieb02dedba312ab76890e943934ce6a1e2fe61f74
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).
This is basically a counterpart of much older commit
3884eb68d9, were same logic was applied to
osmo_sccp_simple_client().
Change-Id: I85d2680ac65a552d7b2824ec41cd8fc669782079
first, xua_msg is allocated internally in the function. Then depending
on msg type different functions are called. All of those functions
either return the same input xua msg pointer or NULL. If they return
NULL due to parsing failure, we need to free the internally allocated
xua pointer.
Change-Id: I4189fbd66e7e05ce466b3e716a357c56d788b64c
Detected while running a TTCN3 sending malformed SCCP message in
SCCP_Tests_RAW.ttcn:
sccp_user.c:174:12: runtime error: member access within null pointer of type 'struct xua_msg'
ASAN:DEADLYSIGNAL
=================================================================
==6==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000008 (pc 0x7f2a11f93c5c bp 0x7ffefcf05c50 sp 0x7ffefcf05c10 T0)
#0 0x7f2a11f93c5b in mtp_user_prim_cb /tmp/libosmo-sccp/src/sccp_user.c:174
#1 0x7f2a11fb48f9 in deliver_to_mtp_user /tmp/libosmo-sccp/src/osmo_ss7_hmrt.c:94
#2 0x7f2a11fb4c8a in hmdt_message_for_distribution /tmp/libosmo-sccp/src/osmo_ss7_hmrt.c:133
#3 0x7f2a11fb5c90 in m3ua_hmdc_rx_from_l2 /tmp/libosmo-sccp/src/osmo_ss7_hmrt.c:275
#4 0x7f2a11f6f5c2 in m3ua_rx_xfer /tmp/libosmo-sccp/src/m3ua.c:586
#5 0x7f2a11f70480 in m3ua_rx_msg /tmp/libosmo-sccp/src/m3ua.c:739
#6 0x7f2a11faee35 in xua_srv_conn_cb /tmp/libosmo-sccp/src/osmo_ss7.c:1623
#7 0x7f2a0f46d082 (/usr/lib/x86_64-linux-gnu/libosmonetif.so.8+0xb082)
#8 0x7f2a1186c0be (/usr/lib/x86_64-linux-gnu/libosmocore.so.12+0xc0be)
#9 0x7f2a1186c735 in osmo_select_main (/usr/lib/x86_64-linux-gnu/libosmocore.so.12+0xc735)
#10 0x557378718219 in main /tmp/libosmo-sccp/examples/sccp_demo_user.c:264
#11 0x7f2a105ad2e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#12 0x557378717059 in _start (/usr/local/bin/sccp_demo_user+0x6059)
Change-Id: Idafa8c9693d98ecd214b62155372e4db69e2a4a4
* Introduce check to make sure we don't write out of peer->host bounds.
* Clean up any/specific address checks, it should be more clear now.
Change-Id: I3ecb94267acbec6ecf2134b08110f24f131cd8cf
Server addresses (and remote added ones) were not being copied to the
ASP and hence connections were not matches against the ASP when
connecting:
osmo_ss7.c:1820 (r=127.0.0.2:2905<->l=127.0.0.1:2905): m3ua connection
without matching ASP definition and no dynamic registration enabled, terminating
Related: OS#4355
Change-Id: I77d4f4d733cb46eaaacc7dc32259c9851c79d78e
The code managing addresses is decoupled from xua_server since they will
also be used to manage addresses for ASPs.
Change-Id: I4af2a6915ac57c7baa67343bd9414c65154d67f7
It doesn't really change old behavior since it's impossible the child
function returned an error with current implementation, but let's better
return the return code in case new error paths are added.
Change-Id: I24747578b3412b385c1ea1a14922f543f9023a27
Old commit of mine successfully fixed a memory leak, but apparently
after some more investigation it seems to have introduced a double free
of xua object in other code paths.
Nowadays, it seems scrc_rx_mtp_xfer_ind_xua() is called from 3 different places:
mtp_user_prim_cb()
sua_rx_cl()
sua_rx_co()
Before present patch, first caller is not freeing the xua message and my
old commit made scrc_rx_mtp_xfer_ind_xua() free it (by passing
ownsership of the object). But the other 2 callers do free the xua
object afterwards (actually the grandparent caller sua_rx_msg() does
it), which means it would double-free the xua object.
Let's move ownership out of scrc_rx_mtp_xfer_ind_xua() and let the
caller free the xua object (only changes need on the first caller). This
way everybody is happy and we keep the free() closer to the alloc().
Change-Id: Ia550b781b97adbdc0a0ad58a1075e5467e056f1e
Related: OS#4348
Fixes: 9c3baa89fb
This reverts commit ffb248dd78.
Reason for revert: ttcn-msc-tests fail, apparently there are lots more
xua_msg_free() in scrc_rx_mtp_xfer_ind_xua() that need to be dropped
Change-Id: I008bcb6d5bad9e6347e7cd670159816f51331189
Neels Hofmeyr
Pau Espin
Neels Hofmeyr
Harald Welte
Vadim Yanitskiy