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
Add new environment variables WITH_MANUALS and PUBLISH to control if
the manuals should be built and uploaded. Describe all environment vars
on top of the file.
When WITH_MANUALS is set, install osmo-gsm-manuals like any other
dependency and add --enable-manuals to the configure flags (for "make"
and "make distcheck"). Add the bin subdir of the installed files to
PATH, so osmo-gsm-manuals-check-depends can be used by ./configure.
Related: OS#3385
Change-Id: I5904c86c7e38d36d23df213f5a2ae1986647a051
Set AM_DISTCHECK_CONFIGURE_FLAGS in Makefile.am instead of
DISTCHECK_CONFIGURE_FLAGS. This is the recommended way from the
automake manual, as otherwise the flag can't be changed by the user
anymore.
Related: OS#3718
Change-Id: Ib3f443e07f51df352357c5a90792bd946efcdf27
Moved to doc/manuals/, with full commit history, in preceding merge commit.
Now incorporate in the build system.
Build with:
$ autoreconf -fi
$ ./configure --enable-manuals
$ make
Shared files from osmo-gsm-manuals.git are found automatically if
- the repository is checked out in ../osmo-gsm-manuals; or
- if it osmo-gsm-manuals was installed with "make install"; or
- OSMO_GSM_MANUALS_DIR is set.
Related: OS#3385
Change-Id: Ib5a22c2ea81fdde036bf9efb47d785a830b88c93
After I66e97706de0c546db3c6ff77fb5e6ac6e32bff55 which adds the missing
sccp_vty_init(), update VTY reference with the new SCCP show / config commands.
Depends: I66e97706de0c546db3c6ff77fb5e6ac6e32bff55
Change-Id: Id941b8e31d3b4cfdb3f912beedc1e7af321a0113
This is the first update since the libosmocore changes to the 'show
online-help' generated output. Hence the produced document now benefits from
the structural improvements:
- not repeating common commands for every node;
- using section names that match the VTY prompt.
Change-Id: I98cdfcb6c1c7db49ab106e775be92e4c6adeab17
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
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