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
Call osmo_sccp_vty_init(), so far forgotten.
This adds the various 'show cs7 instance N sccp *' commands, as well as making
the SCCP timers configurable.
See Id941b8e31d3b4cfdb3f912beedc1e7af321a0113 for a diff of the VTY reference,
showing what commands are enabled by this patch.
Change-Id: I66e97706de0c546db3c6ff77fb5e6ac6e32bff55
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
Add ss7_asp_vty_test, a shim test program with the sole purpose of exposing the
cs7 VTY nodes.
Add ss7_asp_test.vty, transcript for verifying VTY nodes using above program.
Add --enable-external-tests to configure.
Run jenkins.sh with --enable-external-tests.
Change-Id: I6a28684fa24d6e7de568623444297028eba2ab8c
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
This commit re-adds ba3da6d725, plus fixes
two typos (sytemd->systemd) in that commit.
The commit is fine, we just need to add some extra configure flags in
osmo-ci.git.
Depends: https://gerrit.osmocom.org/#/c/osmo-ci/+/10857/
Change-Id: Ifc11d97c0c5fe1f7872b59147b1548b56951921b
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
The .tarball-version file should contain the *source version* uniquely
identifying the git commit, and not the Debian package name.
With https://gerrit.osmocom.org/#/c/osmo-ci/+/10343/ there is a correct
.tarball-version file in the .tar.xz of the nightly source packages.
Change-Id: I620c96eb311be6fdd4187bdcc311ea893ad93614
Related: OS#3449
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
This check is not in all our repos that use git-version-gen. Indeed it
seems to be a leftover of openbsc where I think it wanted to ensure
being called in the openbsc subfolder or something? libosmocore e.g.
doesn't have it.
In any case .git being a directory is not always true (if using git
worktree) so remove this check.
Change-Id: Ic14561f3b041bb94d1b60e477b18e37077ce4c32
Fix previous commit 4dc9088cab which
broke this by using -1 for local and 23 for remote PC, for both
server and client.
Change-Id: I7432e6fc2617e0fd77a098fcd7d14abc40db7229
Related: OS#2666
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
So far the tall_xua ctx used to allocate from in xua_msg_alloc() was never
initialized, actually hiding memory leaks from the talloc report.
Add this API to allow branching the xua_msg ctx off a sane root ctx.
Explicitly initialize tall_xua to NULL, so that, if xua_msg_ctx_init() isn't
called, tall_xua is still guaranteed to not be a random pointer.
osmo-bsc will use this function to hook the tall_xua ctx to osmo-bsc's own root
ctx.
Change-Id: I618878680a096a7f7fc2d83098590f2e4cb08870
Before this, the log looked like it parsed the same address twice with
differing results:
DLSUA DEBUG sccp2sua.c:333 Parsed Addr: RI=2,PC=1196,SSN=254
DLSUA DEBUG sccp2sua.c:333 Parsed Addr: RI=2,PC=100,SSN=254
Adding the IEI clarifies this:
DLSUA DEBUG sccp2sua.c:333 IEI 259: Parsed Addr: RI=2,PC=1196,SSN=254
DLSUA DEBUG sccp2sua.c:333 IEI 258: Parsed Addr: RI=2,PC=100,SSN=254
(I'd have liked to print the IEI name from sua_iei_names, but I frankly can't
figure out how to reach that value_string array "hidden" behind a xua_msg_class
struct, and neither can I find any other code doing so.)
Change-Id: I64adb31129684b2eb66fff581040017ce2f6d163
The new name allows for more natural naming of variables in TTCN3
code when this program is used as a TTCN3 test component.
Consider e.g. "SCCP_DEMO_USER_VTY" vs. "M3UA_EXAMPLE_VTY".
Change-Id: I92b5e16e765a1ac36371a16933389903628f8dfe
Related: OS#2666
There are plans to use the m3ua_example tool as an SCCP peer
for a TTCN3 test suite. Make it possible to pass paramters to
this tool so the user can override hard-coded default values
of IP addresses, ports, and point codes.
Change-Id: I52243ae926c76020de41c8dfc7263517c7263d7e
Applications may be interested in handling data for those SCTP PPID or
IPA StreamID which libosmo-sigtran doesn't implement
natively/internally.
Let's add osmo_ss7_register_rx_unknown_cb() using which applications
can register a call-back to implement whatever behaviour they'd want for
those PPID/StreamIDs.
Change-Id: I8616f914192000df0ec6547ff4ada80e0f9042a2
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
We don't implement routing by global title address.
When processing an SCCP message which is routed by global title,
don't recurs indefinitely until the stack is exhausted.
Instead, return an error with cause SUBSYSTEM_FAILURE, which we
also do in other routing failure cases.
Change-Id: I24621e77ffc979bc337775f9c6a4ad9a9068625a
Related: OS#2666
Makes sure that in absence of a user-specified port number,
osmo_ss7_asp_protocol_port() will return 5000 as default port number.
Change-Id: I628ee095603742a652fd971887e02cc17d1f71b8
As warned by gcc 8.1.0:
In file included from libosmo-sccp/include/osmocom/sigtran/osmo_ss7.h:7,
from libosmo-sccp/include/../src/xua_internal.h:3,
from libosmo-sccp/tests/xua/xua_test.c:21:
/include/osmocom/core/utils.h:13:34: error: division ‘sizeof (const uint8_t (*)[12] {aka const unsigned char (*)[12]}) / sizeof (const uint8_t[12] {aka const unsigned char[12]})’ does not compute the number of array elements [-Werror=sizeof-pointer-div]
#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
^
libosmo-sccp/tests/xua/xua_test.c:371:45: note: in expansion of macro ‘ARRAY_SIZE’
#define PARTARR(x, data) { .tag = x, .len = ARRAY_SIZE(data), .dat = (uint8_t *) data }
Change-Id: Iad5703d68fee26fc83958741512820d2539e604e
A primitive allocated in lm_timer_cb() with xua_xlm_prim_alloc()
was never freed. Don't forget to free the msgb in osmo_xlm_sap_down().
Found by code inspection.
Also, assert that allocation suceeded like we do elsewhere.
Change-Id: Ie667b1b8beeda2aa4520a1413f51101435215cc0
Related: OS#2449
So far, 'debian/control' didn't express the minimum version numbers
of the libosmocore + libosmo-netif build dependencies. This resulted
in build failures against older libosmocore/libosmo-netif versions,
so let's make sure the minimum veresion requirements are expressed
also in debian/control.
Change-Id: I1c874880d8b2569df7acc1af554f7a4dd30e649e
Max
Harald Welte
Pau Espin
Daniel Willmann