| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
|
Change-Id: Ibb22c1dc1ec73fc574cc3d38664874114f681c37
|
|
Related: OS#4372
Change-Id: I1dbe49a83a1bcddf074d5e638babd065834a0ebd
|
|
A recent commit (83db938859428ce3835239e2692d93c557b750e1) 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
|
|
was explicitly defined in VTY
The VTY config defaults are "role sg" and "sctp-role server".
However, if not set explicitly in VTY,
osmo_sccp_simple_client_on_ss7_id() was replacing them to "role asp" and
"sctp-role client".
This is fine if the ASP is not defined/created at the VTY (aka
dynamically created with no config), but if the ASP is defined in the
VTY it becomes really confusing, since it's picking different defaults
than the usual ones.
Hence, follow always the same VTY defaults in
osmo_sccp_simple_client_on_ss7_id().
As a result of this change:
- Programs not defining the ASP over VTY keep the same behavior (ASP is
created with role=asp and sctp-role=client)
- Programs defining ASP over VTY (eg. "asp asp-clnt-msc-0 5000 0 m3ua")
explicitly setting "role" and "sctp-role": keep the same behavior
- Programs defining ASP over VTY but not explicitly setting "role" or
"sctp-role", will get now the usual defaults instead.
So in summary, strange cases where osmo_sccp_simple_client_on_ss7_id()
is used (osmo-bsc, osmo-hnbgw, osmo-msc) and the dynamically created
ASP is created through VTY, then the config file must also explicitly
define the following lines:
role asp
sctp-role client
This patch also changes the "show running-config" VTY cmd to also always
show the configured role and sctp-role values, which are of vital
importance to understand a given setup.
Change-Id: Ie81987265118e48173211f88b27a006115dc62d4
|
|
sctp server
Right now, if a user configures an cs7 instance, as and asp (with
sctp-role server) in the VTY, then the function
osmo_sccp_simple_client_on_ss7_id() (used by osmo-bsc, osmo-msc,
osmo-hnbgw, etc.) will silently change the config to be SCTP client.
This is really confusing, since the user configured explicitly the ASP
as server but ends up running as client.
Instead, if the user explicitly configured the ASP as SCTP server,
allow it (after validating the user also properly configured a xUA
server through VTY).
Change-Id: I20de33edb8751a515d6719c49efadfc387dd85f8
|
|
Change-Id: I9a8afc07ae278100ffe34407db0e196f0c9ce8af
|
|
So far, the optional data limit can only be modified via cs7 VTY,
because struct osmo_sccp_instance is private. Provide public API to set
this limit from C.
Change-Id: If3d22a0f65a7ed0be043027652402b32c356e322
|
|
When the Optional Data surpasses 130 bytes, it is not sent as part of
SCCP CR, CC, CREF or RLSD messages, but gets sent separately in a Data
Form 1.
Make this 130 user configurable. This is specified to be 130 bytes
exactly, but to interop with non-conforming peers, make this limit
adjustable per cs7 instance, via osmo_sccp_vty_init().
Add and test new VTY config:
cs7 instance N
sccp max-optional-data (<0-999999>|standard)
Related: ITU-T Q.713 4.2 to 4.5
Related: Ia68dad973ef18513b52f5accb5264c557c7295ea osmo-ttcn3-hacks
Related: SYS#6423
Change-Id: If35697234796af8943691b2de62218e7dc93a08c
|
|
The field already exists in the struct, but it's not really used
anywhere internally yet (and was not available externally).
Let's make it available to users of the API, similar to osmo_sccp_user_{get,set}_priv().
This way apps can easily store per-sccp-instance state.
Change-Id: I5643e6b14590b1478b3c8dabc8a7a619f5505409
|
|
As a result we move from:
INSERT=O(1) SEARCH=O(n) REMOVE=O(1)
to:
INSERT=O(log(N)) SEARCH=O(log(N)) REMOVE=O(log(N))
So we get rid of O(n) complexity every time we need to find a conn
object based on conn_id. When a big number of SCCP conns is handled,
this saves a lot of CPU time every time a conn needs to be looked up,
for instance each time a message is received.
For instance, given 1500 SCCP conns, searching is ~10 steps while it
took 1500 steps beforehand.
Morever, since when creating a new conn_id the code looks if it exists
prior to it, that means in practice inserting used to took O(n), while
now it takes O(log(N)).
Change-Id: I28ac67038207e2fad89ea291629cec5b2f912461
|
|
The current implementation of osmo_sccp_simple_client forces the ASP to
run in ASP role. Even then when the user has configured it differently
via VTY. The osmo_sccp_simple_client should respect the VTY
configuration.
Change-Id: Ib57c513407747d36e503a4fb01c50c69dea0cb85
Related: SYS#5796
|
|
default hosts
Allow user apps to relay the decision of proper default local/remote
hosts values to the library. Proper configuration of these addresses can
be quite cumbersome to get correctly, or confusing at least. That's due
to the multi-homing feature of SCTP where both IPv4 and IPv6 are
involved.
We were already doing this kind of automatic setup in
osmo_ss7_vty_go_parent(), where we do validations and assign addresses
based on IPv6 availability.
On the other hand, apps using osmo_sccp_simple_client_on_ss7_id() API
usually pass "localhost" as default address. In Linux, when IPv6 is enabled
localhost is resolved as "::1", and "127.0.0.1" when IPv6 is disabled.
Let's instead allow apps to relay the setup to the lib, so same addresses
can be applied both during VTY command as well as if there was no VTY
setup at all.
Related: OS#5186
Change-Id: I82e203612571b7651d758d8148661f706a1642ba
|
|
Change-Id: I1164490c140cc5ca82e5977d24f5971ba216014b
|
|
SCMG (SCCP Management) is a special sub-system that normally resides
at SSN=1. In Osmocom we so far ignored its existence. However,
in terms of interop with other implementation, we should implement
at least some basic features.
The only procedure implemented in this initial commit is the response
to an incoming SST (Subsystem Test) message. If we don't respond to
this message, a remote SCCP entity could assume the SSN is dead on
our side, rendering communication impossible.
Change-Id: I04b162476f7652ef0540b5ea7299e9447efd1d09
|
|
Avoid magic number 0xffffffff and rather provide a mask value for all address
components.
Change-Id: I13ff0858e496c4392b8e1590d62f7eb80f191a07
|
|
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
|
|
This reverts commit ec20a6164b046f9b6190dc886c3cc8a8e1445739.
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
|
|
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
|
|
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
|
|
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
|
|
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
3884eb68d9322967340d4f04e7382b2147ec7a2e, were same logic was applied to
osmo_sccp_simple_client().
Change-Id: I85d2680ac65a552d7b2824ec41cd8fc669782079
|
|
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
|
|
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
|
|
Change-Id: I4736cb107a1987dab123744b98fb2b06a5e1167a
|
|
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: 9c3baa89fb6b3fc1ef588930f361d013f98a1e39
|
|
This reverts commit ffb248dd787eb854e049d990afc40f0e604268f2.
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
|
|
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
|
|
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
|
|
Fixes: 3884eb68d932 ("osmo_sccp_simple_client(): use sccp instance index 0 instead of 1")
Change-Id: Iaac59222df84eacf813825c2ef660281381e6b14
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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 variable as_name was freed before being passed to the
osmo_ss7_route_create() function. Free it later to avoid
a use-after-free crash with address sanitizer.
Found by running 'examples/m3ua_example aaa' with address
sanitizer enabled.
Change-Id: I9d724bc1d2aa8d6f8b6a67bdeafdb5f0f9136413
Related: OS#2666
|
|
There is a naming dilemma: though the osmo_ prefix is now reserved for
libosmocore, all surrounding API already has the osmo_ prefix.
This will be used by osmo-hnbgw's VTY 'show cnlink' command.
Change-Id: Ib7abf69cfcf4c56273223054b280458451e6c2f6
|
|
In osmo-stp, cmd "local-ip" inside node "listen m3ua 2905" was actually
not being applied, because the server was created + bound at "listen" command
time using NULL as IP, and at "local-ip" time the IP was changed but the
server was not re-bound using the new IP, so it kept listening at
0.0.0.0.
With this patch, we defer binding the socket to "local-ip" cmd time,
after the IP has been applied.
As a result, if no "local-ip" command is provided, then the bind never
happens, which means it is now mandatory that users of osmo_ss7_xua_server_create
API not using osmo_ss7_xua_server_set_local_host call new provided API
osmo_ss7_xua_server_bind. Another new API osmo_ss7_bind_all_instances is
provided to easily make sure all servers are bound after configuration
process. This is specially important for servers which doesn't contain
the "local-ip" parameter.
Users of osmo_sccp_simple_server API are not affected by this change,
and they not requrie to call any new API.
Furthermore, using osmo_ss7_xua_server_bind in VTY code ensures the xUA
server is automatically bound to the new address if the operator changes
the "local-ip" cmd at runtime.
Related: OS#2647
Change-Id: I79738963d633bec70705ff159c5b2127cd498aa2
|
|
Change-Id: I113232bbeaa7a835871df7f9b883ba573d8a2534
|
|
If the user does not create an AS, but creates an ASP with a name
that is equal to the default name, then the simple client detects
that and trys to use this ASP. However, unfortunately it then
overwrites the settings of the ASP with the default settings.
If the detected ASP is not created by the simple client, use it,
but preseve the settings of that ASP.
Change-Id: I53d73059f804c3bbea6cb43dc73ad49a753b3b15
|
|
The previous fix (I312caf9d54cedb02034e4ef88fdd2e6ad9ca1c34) caused the default
addresses to be discarded. Actually talloc_strdup() the default addresses to
use them if not NULL.
Change-Id: Ic8563ab272d5256a1b8ceefd5fee37da61e1bd26
|
|
osmo_sccp_get_ss7() has the risk of a nullpointer dereference, when
sccp is NULL.
Return NULL when the sccp instance is NULL.
Add doxygen comment
Change-Id: I84d484e4441fd37443fff8c67e17df8fb15d5b2e
|
|
It is currently impossible to find out which SCCP instance handles
a particular user.
Introduce function to lookup the SCCP instance from a given SCCP
user.
Change-Id: I9562c4f1d00e2ebb3252c5dea598b643aa393719
|
|
Some of the functons in sccp_user.c have already
doygen comments on them.
Add doxygen comments for the simple client functions as well
Change-Id: I9143bdc54d729f9f50e69fe38cd1798e065f2497
|
|
The point-code is not checked in the beginning, only the ASP
checks the point code at a very late stage and fails in case
an invalid point-code is detected.
Remove the check in the ASP creation.
Add a new check after the SS7 initalization that checks the
point-code. If none is set, the default point-code will be
used.
Change-Id: I334d90e769bd9952f67c51b12a945f22bd268fa8
|
|
When the default IP addresses (remote or local) the respective
struct value should be set to NULL.
Fix wrong ?:-notation.
Change-Id: I312caf9d54cedb02034e4ef88fdd2e6ad9ca1c34
|
|
The simple client takes certain parameters (pc, ip and port
numbers) which serve as a fallback default in case the user
did not configure any suitable parameters via the VTY.
Prefix all default variables with default_ to make the
purpose clear to the API user
Change-Id: Id9e697e8b198e4f58a79e59aaf2e649e84a3eb63
|
|
The simple client (osmo_sccp_simple_client_on_ss7_id() and
osmo_sccp_simple_client) does not create a default route if
the user has already created an AS via VTY.
Check the presence of a default route independently of the
AS. If no default route exists, create one.
Change-Id: I7516fa5509bade4ba10e9d8eaa3e46cfe3696b3a
|
