Wen there's no SMPP support compiled in, and routing was successful,
we shouldn't return an uninitialized value.
Change-Id: I4abbbb5ab336a7e8da08d682f396baec3b56fa3a
Fixes: Coverity CID#174176
osmo-mgw.git is changing the mgcp_client_vty API to use 'mgw' instead of
'mgcpgw'. Fix example configs after that patch is merged.
Depends: I1d43d42929dc9162e57640499526fb7cadbcfbe6
Change-Id: Ib4c5ec1046a3c7a916ecfb7e5aa83dfe2f5ea8bf
vty_install_default() and install_default() will soon be deprecated.
Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
Change-Id: I34708c73d8084db4e6c83a39be8fdaeaa492d743
When using ciphering, the TMSI is an important part of the ciphering. To guard
against users forgetting to set 'assign tmsi' in the config and compromising
their ciphering unknowingly, the default should be to use a TMSI.
To optimize in an unencrypted network, 'no assign tmsi' config can still switch
off TMSI use.
Change-Id: If115e95bebc314bedb50faf3993b52071fee5c1e
The name auth_tuple_max_use_count suggests that if I want to use each auth
tuple exactly once, I need to set it to 1. Curiously, so far you need to set
to intended uses - 1.
Reflect this in its name by renaming to auth_tuple_max_reuse_count.
I first considered to not rename but change the if-conditions so that == 1
means each tuple is used once, and upon struct vlr allocation, set the default
to 1. That would also logically entail that setting to 0 means to re-use
vectors infinitely often, like now a value < 0 does. That means, when
allocating a vlr struct zeroed out, we would by default have the most
dangerous/unsafe configuration. It's no problem to set a default to 1 upon
allocation, but by renaming the variable instead, we get safer alloc-zero
behavior and don't need to change any conditionals in the code (even though the
patch ends up considerably larger from all the renaming).
Change-Id: I0b036cae1536d5d6fb2304f837ed1a6c3713be55
Before this, a code change in libvlr or libmsc would not cause a rebuild of the
tests.
You'd have thought 'AM_LDADD' were the right name for the variable, but
apparently it is just 'LDADD' instead. Tested that it works as intended.
Change-Id: Icbdedc1581fa23abe9ed99cef3918592b25f30b3
I'm using the dame version as in configure.ac to avoid build failures
against older versions of certain packages, such as older libsmpp34.
Change-Id: I83c617fa4e83e2e3d2613e454f517d6031814f21
libmsc/a_iface.c and libmsc/a_iface_bssap.c still include
osmocom/sccp/sccp_types.h to get access to enums defining SCCP
cause values. Until that is resolved, we have to keep the build
dependency to libosmo-sccp-dev
Change-Id: I957dcb2bcce216d0fd81a58bfe869aca0e4624a8
Related: OS#2601
See osmo-ci change I2409b2928b4d7ebbd6c005097d4ad7337307dd93 for rationale.
Depends: I2409b2928b4d7ebbd6c005097d4ad7337307dd93
Change-Id: I6ae80147b2624079b5c364dbce08194215cc4e95
[ Alexander Couzens ]
* debian/rules: show testsuite.log when tests are failing
[ Neels Hofmeyr ]
* build: check for -lgsm
* am: msc_vlr_tests: use AM_LDFLAGS instead of COMMON vars
* jenkins: fix build: osmo-mgw from master, not pre_release
* jenkins: drop unused build matrix vars, always --enable-smpp
* configure.ac: fix to "AC_INIT[osmo-msc]"
* rewrite README
* rename openbsc.pc to osmo-msc.pc
* debian: fix web and VCS links, tweak osmo-msc.install
* drop files unrelated to osmo-msc
* rename include/openbsc to include/osmocom/msc
* doc/examples: add detailed cs7 config examples
* use separated libosmo-mgcp-client, apply rename to mgcp_client_*
* ctrl: subscriber-list-active: list only attached subscribers
* debian: fix dependency to mgcp library
* main: remove cmdline args no longer available for osmo-msc
* vty: fix: missing default cmds at hlr node
* ctrl: remove unimplemented cmds subscriber-{modify,delete}
* fix build: remove obsolete header legacy_mgcp/mgcp.h
* fix debian: fix erratic doc/examples install path
* fix memory leak: vlr: vlr_gsupc_read_cb() must msgb_free()
* fix vty tests: long timeout due to unreachable STP address
* cosmetic: vlr: declare a struct in .h; drop unused header
* add ';' after OSMO_ASSERT()
[ Philipp Maier ]
* a_iface: fix memory leaks
* a_iface: fix typo
[ Max ]
* Remove rest_octets.h
* Remove SI-related code
* Remove BTS-specific attributes
* Remove unused osmo_bsc_rf.h header
* Remove pkg-config file
[ Harald Welte ]
* Update .gitignore for post-nitb-split
* remove further files and autotest/autoconf bits irrelevant to osmo-msc
* Rename osmo_fsm to avoid illegal space in name + more meaningful name
* Debian: remove obsolete Dependencies
* configure.ac: Depend on latest tagged/released libosmo-* versions
* Debian: Build with enabled SMPP support
* osmo-msc: Don't link against libasn1c
* Debian: Include systemd.service in package
* Debian: include all (not just one) example config files
Change-Id: Ic24d937658e5b467c6643ae3cd54e5b6d9db3175
osmo-msc doesn't use any API/symbols of libasn1c directlry. Rather,
we use libosmo-ranap which in turn uses libasn1c. Let the linker
work out that dependency.
This fixes the following dpkg-shlibdeps warning:
Change-Id: I2f840884d8f1cc542de1e26acd3d4215bd2fd899
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/osmo-msc/usr/bin/osmo-msc was not linked against libasn1c.so.0 (it uses none of the library's symbols)
This is the safe choice, as in absence of automatic testing we don't
know if we actually still build against the [sometimes] ancient
dependencies. Would be great to automatize this, but until we have that,
better be safe.
Change-Id: Idf5cad1dc17a5136d00c970c326cdf3b7ee18e3c
A FSM doesn't need "FSM" in its name, as it is obvious that it is a
FSM. Also, having two that are called RESET is confusing, so let's
try to come up with better names.
Also, after Change-Id I9ef59432f43a3cdb94e4cbb0c44ac3f9b2aac0f2 in
libosmocore, we now enforce that no FSM identifiers contain spaces
or other illegal characters.
Closes: OS#2593
Change-Id: I858a81b8a4e01b2e802e3159f2835e5ca515953d
Currently, OSMO_ASSERT() is defined such that it ends in a semicolon, hence an
added ';' is redundant. However, the usual way this kind of macro should be
defined is
#define OSMO_ASSERT(x) do { ... } while(0)
so that the compiler requires a trailing semicolon.
To prepare for such a change possibly coming up in libosmocore, add ';' to all
OSMO_ASSERT() users.
Change-Id: Ic79c8b8f98a7f3bef761751d55a7e6125cf2c46d
In vlr_core.h, "pre-declare" a struct used in function declaration.
In vlr_lu_fsm.c, gsup.h is not used, drop the #include.
Change-Id: I61d793c3001abbe6d381be1ae0bb350b07403e88
The doc/examples/osmo-msc SCCP config examples with 10.23.42.1 as asp ip-remote
cause >5 minutes timeout for each VTY config test being run before the VTY
becomes available. This hugely elongates the config tests, we didn't spot it
before because it does succeed after that timeout. Rather use link-local
addresses in order to immediately note the lack of connection and carry on with
the VTY config tests.
Related: OS#2333
Change-Id: I5ea4ef8a7e181bd3a38edf9c3b5d098f6ba65ee5
Add required msgb_free() to vlr_gsupc_read_cb().
Adjust msc_vlr_tests.c gsup_rx() to *not* free the msgb again after
vlr_gsupc_read_cb() did.
Related: OS#2476
Change-Id: I347c53f57a7fa79921aed3f6e42599841acf27c0
Since Ifb8f3fc2b399662a9dbba174e942352a1a21df3f libosmo-mgcp-client has its own
definitions in mgcp_common.h, which conflict with legacy_mgcp/mgcp.h. This
cross-inclusion to support libosmo-mgcp-client is no longer necessary.
In the future, including libosmo-mgcp-client together with libosmo-mgcp will be
made possible, but not with libosmo-legacy-mgcp (because we don't care enough).
That is why including libosmo-legacy-mgcp headers would cause build failure.
Depends: Ifb8f3fc2b399662a9dbba174e942352a1a21df3f
Change-Id: I8e3359bedf973077c0a038aa04f5371a00c48fa0
The MSC should not fiddle with low-level SI details like rest octets
anyway. Unfortunately simply removing the header is impossible as it
causes massive fallout due to missing includes. Fixed it as well.
The only other parameter which required removal is cell_ro_sel_par which
is not referenced anywhere in the code anyway.
Change-Id: Ibff77330de056fad4288cd4c48d016aad8105354
osmo-mgw has split the MGCP client to a separate library in
change-id I8e0b2d2a399b77086a36606f5e427271c6242df1
or commit 97df691307e48c39170ac39b2394a7095d7f0ee5.
Change-Id: I9c56c218fce2264fe0acae62caed4d9ff4bfb54c
I would have liked to add a regression test to verify this, but currently there
is no easy way to run CTRL tests and at the same time have access to the
osmo-msc in a way that simulates an attached subscriber.
Related: OS#2285
Change-Id: I003542b208ecf3713e9e67712d84ccb4c61af14e
After osmo-mgw changes I8e0b2d2a399b77086a36606f5e427271c6242df1 and
I99f7faab637cfcc22ece64a1dbcbe590f2042187, apply linking of new
libosmo-mgcp-client and renames to drop the "gw" from mgcp_client_*.
Also rename the gsm_network.mgcpgw to mgw, to indicate that the MGCP client is
used to contact the MGW (Media Gateway).
Depends: I8e0b2d2a399b77086a36606f5e427271c6242df1 (osmo-mgw)
I99f7faab637cfcc22ece64a1dbcbe590f2042187 (osmo-mgw)
Change-Id: I093ad02ca0e532f659447c785e09678b3e6f220d