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
After dispatching to scrc_rx_mtp_xfer_ind_xua(), free the xua_msg.
Do not free the xua_msg in any of the code paths triggered within
scrc_rx_mtp_xfer_ind_xua(), i.e. remove xua_msg_free() from:
sccp_scoc_rx_from_scrc()
+->sccp_scoc_rx_unass_local_ref()
+->tx_coerr_from_xua()
+->tx_relco_from_xua()
Before this, some code paths would free the xua_msg, while most code paths
would not, causing mem leaks.
Change-Id: I72b3c6a6f57ba32d9ba191af33b4b236492174e0
let's avoid messages like
DLSS7 <000c> xua_asp_fsm.c:600 XUA_ASP(asp-client0){ASP_DOWN}: transition to state ASP_DOWN not permitted!
Change-Id: Iabbcf92e3022a4c3f165ce19be929915f92b455c
If we are running in ASP (client) role, and we are about to transmit an
ASPAC or ASPIA to the SG, we must make sure to include any applicable
routing contexts.
Change-Id: Iee4f0d553d6845a9ae08cb5e4f57fdec443e4ef9
Related: OS#4285
When a client (ASP) sends an ASPAC to the server (SG), it should include
the traffic-mode configured for it's ASs, if any.
Change-Id: Ia850df22df529dab74959e8666f85976002c482c
Related: OS#4285
we handle this correctly in not writing the actual "asp" configuration,
but we have a bug when writing the list of asps within one "as". Let's
make sure to skip the dynamically-created ASPs there, too.
Change-Id: I1a184f3ddec2e91ced8c95ada224da8b490407a8
Closes: OS#4284
The ASP role must be saved in lowercas as the parser during config file
reading only understands it in lowercase.
Change-Id: I38b8e4d73121f8bf001037fdd2dd164113544d94
Closes: OS#4270
The code to set the default role (SG) and default SCTP role (server)
must only be executed when the ASP node is first created. Subsequent
times entering the pre-existing ASP node should not overwrite
those role settings [or any other configuration for that matter]
Change-Id: I068996a5e0d870043b652fb69a3c300adc6fda7c
Closes: OS#4271
This is like osmo_ss7_asp_find_and_create(), i.e. it's doing a full
match for an ASP within the specified SS7 instance, of the specified
port numbers. It just doesn't create it if it is missing.
Change-Id: I1ed3cf2b69ee622d6f9d8b50487f392fe913ae90
Related: OS#4271
In general we want to avoid multiline log messages since they make
parsing more difficult. Also output in VTY over telnet looks strange
(indentation incremented at each new line).
Change-Id: Id9084d0e0f976bb374186db93d6ff8062b99e238
Since it may act sometimes as a server and sometimes as a client, let's
better use one more neutral (2-side arrow) connector, and mark which
address is the local and which is the remote. We already use same
formatting in other osmocom code.
Change-Id: I42feaa16790f02b98bcda65281de8cd9295ddcb6
Since there's no official spec for IPA and some
implementations seem to like sending the IPA ID ACK before
the IPA ID RESP, let's catch it and feed it after we receive
the IPA ID RESP and we are in correct state. Otherwise the connection
would deadlock during the initial handshake.
That's the case with our TTCN3 IPA implementation running STP_Tests
suite.
Change-Id: I99f5346a3854ca07979020245897334197f3cd3b
If AS is configured with Traffic Mode Override, then if a new ASP
becomes active, all previous ASPs are considered to be inactive and new
data is sent to the newly activated ASP.
Remark: It's still unclear which methodology/implementation will follow
when the last activated ASP becomes inactive/shutdown. Then probably
another one should be activated at that time, but that logic is not
there implemented as far as I know.
Change-Id: I4ff246b2f899aaa3cf63bbdb3f3d317dc89b3d15
Similar to what we do with local address. Should fix creating the stream
when no remote address is provided on an ASP configured through VTY.
Related: OS#4260
Change-Id: I33672e76a51a5d5a483906749d30e4c4e08b66ce
RFC4666 sec 4.3.4.3. ASP Active Procedures:
"""
In the case of an Override mode AS, receipt of an ASP Active message
at an SGP causes the (re)direction of all traffic for the AS to the
ASP that sent the ASP Active message. Any previously active ASP in
the AS is now considered to be in the state ASP-INACTIVE and SHOULD
no longer receive traffic from the SGP within the AS. The SGP or
IPSP then MUST send a Notify message ("Alternate ASP_Active") to the
previously active ASP in the AS and SHOULD stop traffic to/from that
ASP. The ASP receiving this Notify MUST consider itself now in the
ASP-INACTIVE state, if it is not already aware of this via inter-ASP
communication with the Overriding ASP.
"""
Change-Id: I474f5cc1f6cbab72d010d1f8ac7ed2285e4c1c45
Most likely, we want all dynamically allocated ASPs to play the SG
role by default. Otherwise when using the following configuration:
cs7 instance 0
xua rkm routing-key-allocation dynamic-permitted
listen m3ua 2905
accept-asp-connections dynamic-permitted
both OsmoMSC and OsmoBSC fail to establish connections.
Change-Id: Ib904ecf0e5d192a1024863f6f0fdf79301055655
Fixes: I2df9cd9747ad5c9a05d567d9a71bab6184c53674
Related: OS#4247
This way the AS can be configured to use different traffic modes over
time as long as they don't overlap in time. That is in this case where
no specific traffic mode is specified in AS local configuration (VTY).
Some RFC4666 state similar behvor of deleting data set by ASPs during AS
shutdown. For instance:
"""
Other ASPs may continue to be associated with the Application Server,
in which case the Routing Key data SHOULD NOT be deleted. If a
Deregistration results in no more ASPs in an Application Server, an
SG MAY delete the Routing Key data.
"""
This allows for tests to easily re-use same AS to test different traffic
modes as long as they wait for the recovery timeout (2 secs by default,
configurable via VTY).
Related: OS#4220
Change-Id: I370aa3b5ddfc456c1be5b2585f2f470d5aa8d289
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
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
Use the new offset based parsing to extract GT and data from the
UDTS/XUDTS message as well. Test vectors are missing right now.
Change-Id: Id0a3a291d8bad3f8c9621e6c97d4ea0b8bbe6035
The cellmgr-ng unfortunately looks at the data being sent and can't
handle the presence of XUDT at all. Add the structure definition
and refactor extraction code to work on offsets. Add a unit test.
Change-Id: I45a7447cc1be432fff34849e0e35abc0410cf153
osmo-msc identifies its BSC and RNC peers by SCCP address, and compares those
by memcmp(), which is not really accurate. Rather provide a meaningful
osmo_sccp_addr_cmp() API to determine whether SCCP addresses are identical.
Go for a full cmp that would also allow sorting.
Change-Id: Ie9e2add7bbfae651c04e230d62e37cebeb91b0f5
Add osmo_sccp_user_sap_down_nofree(), which is identical to
osmo_sccp_user_sap_down(), but doesn't imply a msgb_free().
To implement that, sccp_sclc_user_sap_down_nofree() with the same msgb
semantics is required.
Rationale:
Avoiding msgb leaks is easiest if the caller retains ownership of the msgb.
Take this hypothetical chain where leaks are obviously avoided:
void send()
{
msg = msgb_alloc();
dispatch(msg);
msgb_free(msg);
}
void dispatch(msg)
{
osmo_fsm_inst_dispatch(fi, msg);
}
void fi_on_event(fi, data)
{
if (socket_is_ok)
socket_write((struct msgb*)data);
}
void socket_write(msgb)
{
if (!ok1)
return;
if (ok2) {
if (!ok3)
return;
write(sock, msg->data);
}
}
However, if the caller passes ownership down to the msgb consumer, things
become nightmarishly complex:
void send()
{
msg = msgb_alloc();
rc = dispatch(msg);
/* dispatching event failed? */
if (rc)
msgb_free(msg);
}
int dispatch(msg)
{
if (osmo_fsm_inst_dispatch(fi, msg))
return -1;
if (something_else())
return -1; // <-- double free!
}
void fi_on_event(fi, data)
{
if (socket_is_ok) {
socket_write((struct msgb*)data);
else
/* socket didn't consume? */
msgb_free(data);
}
int socket_write(msgb)
{
if (!ok1)
return -1; // <-- leak!
if (ok2) {
if (!ok3)
goto out;
write(sock, msg->data);
}
out:
msgb_free(msg);
return -2;
}
If any link in this call chain fails to be aware of the importance to return a
failed RC or to free a msgb if the chain is broken, or to not return a failed
RC if the msgb is consumed, we have a hidden msgb leak or double free.
This is the case with osmo_sccp_user_sap_down(). In new osmo-msc, passing data
through various FSM instances, there is high potential for leak/double-free
bugs. A very large brain is required to track down every msgb path.
osmo_sccp_user_sap_down_nofree() makes this problem trivial to solve even for
humans.
Change-Id: Ic818efa78b90f727e1a94c18b60d9a306644f340
Accept the osmo_sccp_user instead of calling conn_create() and setting
conn->user afterwards. Prepare for generating a local_ref inside
conn_create_id() in the future.
Related: OS#3871
Change-Id: I2fb47c8ba6c0ce7cd92c9ac31f15c67eb67fb66e
Move it before sccp_scoc_rx_scrc_rout_fail(), so it can be used in
the latter function to figure out the local_ref from the user (follow
up commit).
Related: OS#3871
Change-Id: Ieabeda3126dcc0349a06c0fc7c9e468b900d7855
Remove all comments, that claim conn_id is the local reference. This
is only a hack, and should not be something to rely on. A properly
separated local reference will be introduced shortly.
Related: OS#3871
Change-Id: I900124037da76caaaf5ecee323eb82e1c6d2e368
We were printing the mask of the route, but not the point code itself.
Best would probably be to print both?
Closes: OS#3835
Change-Id: Ifa4fdbad953d40f222beb470a082eed8c20991ef
"show cs7 instance 0 asp" before this patch would not display the
remote IP/port information about dynamically-added ASPs but instead:
Effect Primary
ASP Name AS Name State Type Rmt Port Remote IP Addr SCTP
------------ ------------ ------------- ---- -------- --------------- ----------
asp-dyn-0 ? ASP_ACTIVE m3ua 0 (null)
With this patch it is now correctly displayed:
Effect Primary
ASP Name AS Name State Type Rmt Port Remote IP Addr SCTP
------------ ------------ ------------- ---- -------- --------------- ----------
asp-dyn-0 ? ASP_ACTIVE m3ua 24905 127.0.0.1
Change-Id: I39a1c57bc72e8aff607f3a551811a2f6372adab4
Closes: OS#3836
Change a loglevel from NOTICE to ERROR, for when a routing key gets
re-purposed.
Add another error log for insufficient resources case.
Change-Id: Id22e3c6bab5f7b597df3514eedb162277ce0ef7d
As osmo_ss7_route_print() returns a static buffer, we cannot use it
twice within a single log/print statement. Rather, we must use
osmo_ss7_route_print2() for the second call, as it uses a separate
static buffer.
Change-Id: Ica32e83cbe8af2317cb07f8d8422a399fa537012
Using osmo_stream_cli_open() with explicit timeout set via
osmo_stream_cli_set_reconnect_timeout() will have the same
effect. Update comment explaining this as well as the code.
Change-Id: Iffe6ea48a170880faef071c7c4a1bc0605aa9855
This fixes the following compiler warning when using -Werror on gcc-8.2:
sccp.c: In function ‘sccp_system_incoming_ctx’:
sccp.c:1039:10: error: ‘result.destination_local_reference’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
&& memcmp(&conn->source_local_reference,
result.destination_local_reference,
sizeof(conn->source_local_reference)) == 0
sccp.c:1030:27: note: ‘result.destination_local_reference’ was declared here
struct sccp_parse_result result;
^~~~~~
Change-Id: Ied41f7c8ddaa5f616dd6556079a54d8d70274490
Properly transition into IPA_ASP_S_DOWN from IPA_ASP_S_ACTIVE
and fix the mask of legal out states from IPA_ASP_S_ACTIVE.
BSC-sccplite tests are still passing with this change.
Change-Id: Idb8e7bd1c74a4b47080fe32ebe0161c503ead571
Related: OS#3111
Previously internal function get_pc_comp_shift() returned negative error
code when called with wrong component number despite unsigned return
value which wasn't checked for error anyway.
Fix this by using explicit assert in the error path. This should not
affect external users because this function always called with constant
component argument.
Change-Id: Ib24cdbcf614bad68f3cfa9776a451c5c1e45ae6e
That's useful for external programs veryfying pointcode validity. For
example if used as part of BSS-related identity in GCR construction by
LCLS code we should be able to double.check that no significant bits off
pointcode are lost/ignored.
Change-Id: I5a9981dd2c1d78966c61a3f6b50c7c0d9b542caf
Allow callers of xua_srv_conn_cb() to tell whether conn
was freed by returning error code EBADF, which is also
used elsewhere in osmocom programs for this purpose.
This is necessary because xua_srv_conn_cb() might be running
inside of a loop which checks for read and then write events
on the connection. If the connection is freed by xua_srv_conn_cb()
as part of processing a read event, callers should avoid further
processing of events. But if we don't return an error we are leaving
callers none the wiser and with a dangling conn pointer.
Change-Id: I7359667b2f25d6c45acc70049b2a4ee2f376a1df
Related: OS#3685
When saving the current VTY config to a configuration file,
do not write out AS/ASP configuration items which are generated
as a fallback by osmo_sccp_simple_client_on_ss7_id().
Since the user did not explicitly configure these configuration
items they should not be saved to the user's configuration file.
Change-Id: Id8a3afc6dee29ae1ee9c862cbe404a61fe979dba
Related: OS#3616
Anywhere else in the Osmocom code base, we arrange headers in
include/osmocom/foo/ and pass -I ${root_srcdir}/include/.
This way including an osmocom header always has the format
#include <osmocom/foo/bar.h>
whether we are including from the local source tree or from $prefix.
For some reason not clear to me, the mtp and sccp folders, even though they are
being installed to $prefix/include/osmocom/, were kept *next* to the osmocom/
dir, instead of inside it. Fix that weird situation.
The motivation is that I wanted to use a definition from sccp_types.h in a
public-API header. That is impossible if it requires
#include <sccp/sccp_types.h>
in a local build, but
#include <osmocom/sccp/sccp_types.h>
for any other source tree using libosmo-sccp. After this patch, both are
identical and including works without quirks. (The other patch that needed this
has changed in the meantime on and no longer needs this, but this still makes
sense for future hacking.)
The installed result does not change, since both mtp/*.h and sccp/*.h have
always been installed to $prefix/include/osmocom/{mtp,sccp}/. This merely
changes their position in the source tree.
The most curious situation before this is that any patch #including
<osmocom/sccp/sccp_types.h> might not get a notice that the header didn't
exist, but might instead include an older system-installed file.
Change-Id: I1209a4ecf9f692a8030b5c93cd281fc9dd58d105
The previous hardcoded SCCP timers may cause SCCP connection releases, if the
peer is configured with far lower timers than libosmo-sccp. Testing with a
specific SCCPlite MSC, I experienced an iar of just over three minutes, meaning
that calls would be cut off by the MSC, since the osmo-bsc failed to send an
Inactivity Timer message until seven minutes have passed.
With this patch, SCCP timers are configurable by the user.
Define constant global default timers, and variable user-configurable timers
with each osmo_sccp_instance.
Add VTY UI to configure the timers. Users must call osmo_sccp_vty_init() to get
the sccp-timer config nodes under the 'cs7' node. Show the new UI in
ss7_asp_test.vty.
Note that even though this function is not new at all, until recently, all of
our SCCP users (osmo-bsc, osmo-msc, osmo-sgsn, osmo-hnbgw) failed to call
osmo_sccp_vty_init(), and thus also missed out on the various 'show' commands
defined in sccp_vty.c. In other words, to benefit from the timer
configurability, the patches to call osmo_sccp_vty_init() must first be merged
to the corresponding master branches.
If a 'sccp-timer' config command occurs, the cs7 instance must allocate an SCCP
instance in order to store the timer config. Do that by calling the recently
added osmo_ss7_ensure_sccp() function.
Hence remove the limitation that the SCCP instance must not be populated from
the "simple" setup function. If we want to configure SCCP timers beforehand,
there must be an SCCP instance for that, and there is no hard reason to require
a NULL SCCP instance, besides the desire to prevent this function from being
invoked twice.
Change-Id: I28a7362aa838e648ecc9b26ee53dbcade81a9d65
For 'show cs7 instance 0 ssn', fix doc string for 'ssn', and add missing one
for the SSN arg. This fixes depending builds that see VTY test failures due to
the missing doc string.
For 'show cs7 instance 0 connectsion', fix doc string for 'connections'.
Change-Id: I214ea51fc6bfa2a9a4dd7c34b43add0c77ffe22e
Instead of allocating ss7->sccp in various places, unify that in one common
function. We shouldn't spread the decision what to pass as priv pointer around
everywhere. There is no functional difference.
This is preparation for a patch where the sccp_instance gets allocated from the
telnet VTY: I would prefer to hide all allocation details from that code; which
also makes sense for the other callers of osmo_sccp_instance_create().
Change-Id: Ie912898c66d31ce4ac8eeeea5a6ddc3f821c06f7
The 'show cs7 instance 0 sccp-addressbook' command should not be inside the
'cs7' node. That defies the point of naming the instance again, and it falls
out of place of all the other 'show cs7' commands on the VIEW and ENABLE nodes.
Drop the old command within the 'cs7' node without substitution or deprecation.
At the same time, drop dash from 'show cs7 i 0 sccp-addressbook'
There are various other show cs7 commands already defined in sccp_vty.c, which
have 'sccp' as a separate string. Conform to that.
Change-Id: I80e0bc0a91bcd3fb75372045db34592d2d663d41
Fix typo "to long".
Say 'cs7 instance' instead of 'ss7 instance': we are interacting with a user on
the telnet VTY, and that user is configuring a 'cs7 instance'. Especially a
lowercase 'ss7' is potentially confusing ("is there an 'ss7' node?").
Changes show in ss7_asp_test.vty.
Change-Id: Iebb976531576268d58338895a4baadbca6137b80
Define SCCP_STR in sccp_internal.h, because I know that I want to also use it
in osmo_ss7_vty.c.
Fix "Signaling" to "Signalling" upon copying the old string.
Change-Id: Ic93e4771147070a9222c73f80b5f7c29ae7eec35
Allowing a whole line of characters as address book name would be a lot,
allowing 512 characters is completely ridiculous. That's more than this entire
commit log message! 32 is plenty.
All linking programs should automatically get the limitation in their VTY
parsing without any changes.
Configs with sccp-addr names > 31 chars will no longer work after this.
Change-Id: I3ecf83d620e46f7bf9857fc60a93d4e240ee3b8a
When entering an 'cs7' / 'asp' node, and invoking 'do show cs7 i 0 asp', the
ASP's FSM instance is not yet allocated. Hence attempting to print its status
will result in a segfault.
Spotted this while writing VTY tests that will follow shortly in another patch
(I6a28684fa24d6e7de568623444297028eba2ab8c).
Change-Id: I3ebf498492c6ba69a5dd1c9f36acdabfd6fbdfe1
The SCCP timer units are not what the comments say:
Milliseconds are 1000 * seconds, not 100.
Also, microseconds are 1000000 * seconds.
Interestingly enough, MSEC_TO_US() tried to fix the wrong hundredth-seconds to
microseconds by multiplying by 10, however, it should end up at a factor of a
million, not a thousand, hence would result in wrong sub-second fractions.
But, since none of the current timers use sub-second fractions, none of the
timers are actually affected in practice. Hence this patch is merely cosmetic.
Since all use of the timer constants is wrapped in MSEC_TO_US(), we can
transparently fix all those values and their use:
- define the constants in milliseconds (replace "100" with "1000").
- in MSEC_TO_US(), divide-and-mod by 1000.
- in MSEC_TO_US(), actually calculate microseconds.
BTW, I am about to make the timers VTY configurable, but before I get confused,
I'd rather fix these units first.
Change-Id: Ia6c893f734fbdc88873c4ef80f6cacf01ee7763a
Testing with an actual SCCPlite MSC, I see the IPA connection starting out by
the MSC sending an IPA ID ACK. Make the ipa_asp_fsm match that.
Change-Id: Icffda98579e676ab6ca63c9c22cf5d151c4fe95f
From LeakSanitizer report:
Indirect leak of 384 byte(s) in 3 object(s) allocated from:
#0 0x7f986da27d99 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:86
#1 0x7f9868d0cb61 in _talloc_zero (/usr/lib/libtalloc.so.2+0x5b61)
#2 0x7f986ad33766 in xua_msg_add_data /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_msg.c:73
#3 0x7f986ad343c3 in xua_from_msg_common /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_msg.c:143
#4 0x7f986ad347d2 in xua_from_nested /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_msg.c:201
#5 0x7f986ad65563 in m3ua_rx_rkm_reg_rsp /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_rkm.c:431
#6 0x7f986ad65f96 in m3ua_rx_rkm /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_rkm.c:510
#7 0x7f986ad31ef7 in m3ua_rx_msg /home/pespin/dev/sysmocom/git/libosmo-sccp/src/m3ua.c:749
#8 0x7f986ad7c1e8 in xua_cli_read_cb /home/pespin/dev/sysmocom/git/libosmo-sccp/src/osmo_ss7.c:1590
#9 0x7f986a66cdb4 in osmo_stream_cli_read /home/pespin/dev/sysmocom/git/libosmo-netif/src/stream.c:192
#10 0x7f986a66e091 in osmo_stream_cli_fd_cb /home/pespin/dev/sysmocom/git/libosmo-netif/src/stream.c:276
#11 0x7f986994e795 in osmo_fd_disp_fds /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:217
#12 0x7f986994eabb in osmo_select_main /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:257
#13 0x5630cb294bd3 in main /home/pespin/dev/sysmocom/git/osmo-msc/src/osmo-msc/msc_main.c:697
#14 0x7f98678b806a in __libc_start_main (/usr/lib/libc.so.6+0x2306a)
#15 0x5630cb292649 in _start (/home/pespin/dev/sysmocom/build/new/out/bin/osmo-msc+0x185649)
Following code paths:
m3ua_rx_rkm_reg_rsp
xua_from_nested
xua_from_msg_common
xua_msg_add_data
talloc_zero (part)
handle_rkey_reg_resp
Take the chance to fix the same issue in m3ua_rx_rkm_dereg_rsp.
Change-Id: I0b15d81099a9f8274b7e39962caa339da644e0dc
Fixes following error provided by LeakSanitizer:
Indirect leak of 1496 byte(s) in 11 object(s) allocated from:
#0 0x7f1eb3332d99 in __interceptor_malloc /build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:86
#1 0x7f1eae617b61 in _talloc_zero (/usr/lib/libtalloc.so.2+0x5b61)
#2 0x7f1eb063e365 in xua_msg_alloc /home/pespin/dev/sysmocom/git/libosmo-sccp/src/xua_msg.c:49
#3 0x7f1eb0650ee3 in osmo_sccp_to_xua /home/pespin/dev/sysmocom/git/libosmo-sccp/src/sccp2sua.c:1298
#4 0x7f1eb0668d6a in mtp_user_prim_cb /home/pespin/dev/sysmocom/git/libosmo-sccp/src/sccp_user.c:173
#5 0x7f1eb068ba86 in deliver_to_mtp_user /home/pespin/dev/sysmocom/git/libosmo-sccp/src/osmo_ss7_hmrt.c:94
#6 0x7f1eb068bf00 in hmdt_message_for_distribution /home/pespin/dev/sysmocom/git/libosmo-sccp/src/osmo_ss7_hmrt.c:133
#7 0x7f1eb068d345 in m3ua_hmdc_rx_from_l2 /home/pespin/dev/sysmocom/git/libosmo-sccp/src/osmo_ss7_hmrt.c:275
#8 0x7f1eb063c08f in m3ua_rx_xfer /home/pespin/dev/sysmocom/git/libosmo-sccp/src/m3ua.c:586
#9 0x7f1eb063cea6 in m3ua_rx_msg /home/pespin/dev/sysmocom/git/libosmo-sccp/src/m3ua.c:739
#10 0x7f1eb0687188 in xua_cli_read_cb /home/pespin/dev/sysmocom/git/libosmo-sccp/src/osmo_ss7.c:1590
#11 0x7f1eaff77db4 in osmo_stream_cli_read /home/pespin/dev/sysmocom/git/libosmo-netif/src/stream.c:192
#12 0x7f1eaff79091 in osmo_stream_cli_fd_cb /home/pespin/dev/sysmocom/git/libosmo-netif/src/stream.c:276
#13 0x7f1eaf259795 in osmo_fd_disp_fds /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:217
#14 0x7f1eaf259abb in osmo_select_main /home/pespin/dev/sysmocom/git/libosmocore/src/select.c:257
#15 0x55666c1bebd3 in main /home/pespin/dev/sysmocom/git/osmo-msc/src/osmo-msc/msc_main.c:697
#16 0x7f1ead1c306a in __libc_start_main (/usr/lib/libc.so.6+0x2306a)
#17 0x55666c1bc649 in _start (/home/pespin/dev/sysmocom/build/new/out/bin/osmo-msc+0x185649)
The code path is the following, starting from mpt_user_prim_cb:
mtp_user_prim_cb
osmo_sccp_to_xua
xua_msg_alloc
scrc_rx_mtp_xfer_ind_xua
sccp_scoc_rx_from_scrc
scrc_node_6
scrc_node_4
scrc_translate_node_9
So the xua_msg is created in mtp_user_prim_cb through osmo_sccp_to_xua
and then handed over to scrc_rx_mtp_xfer_ind_xua which transfers the
xua_msg and thus should take ownserhip of it, and consecuently freeing
it once it's done using it.
Change-Id: I43e159c82b64bd85b185f77ee19b6455a96e082f
In libosmocore Change-ID I1834d90fbcdbfcb05f5b8cfe39bfe9543737ef8f
we have introduced ipa_ccm_id_resp_parse() as a bugfixed replacement
of ipa_ccm_idtag_parse().
The main difference is that the returned "value" parts now have
a correct reported "length", whereas before this commit they all
reported a one-byte too-long "length" for each IE.
Change-Id: I3c79d3bb56cc1370b9922e64d13d2d5508fd8039
1: Do not call xua_msg_alloc() which is later bluntly overwritten by
m3ua_xfer_from_data().
2: After dispatching to m3ua_hmdc_rx_from_l2(), call xua_msg_free().
Related: OS#3393
Change-Id: I0918f9bbc15b036619f1c25a133b69819b2a30fa
Pau Espin
Neels Hofmeyr
Harald Welte
Neels Hofmeyr
Vadim Yanitskiy
Oliver Smith