This avoids potential licensing incompatibility and makes integration of
Debian packaging patches easier.
Related: OS#1694
Change-Id: I71cd631704a4dc155c6c752fee2a42cd6e2fa336
It's not clear cut which code is responsible for canceling pending requests,
since the requests list is kept in vlr_subscr, but sending out Paging does
certainly not belong in the VLR. Place the requests cleanup in gsm_04_08.c.
Add to test_ms_timeout_paging() in msc_vlr_test_ms_timeout.c to verify that a
pending paging is canceled on IMSI Detach.
Change-Id: Ib8874a9d92f02b0826525b55518332f6899688fd
Currently, if there is no reply from the BSS / RNC, a subscriber will remain as
"already paged" forever, and is never going to be paged again. Even on IMSI
Detach, the pending request will keep a ref count on the vlr_subscr.
Add a paging timeout, as gsm_network->paging_timeout and in the VTY on the
'msc' node as 'paging timeout (default|<1-65535>'. (There is a 'network' /
'T3113' in OsmoBSC, but to not confuse the two, give this a different name.)
Add test_ms_timeout_paging() test to verify the timeout works.
I hit this while testing Paging across multiple hNodeB, when a UE lost
connection to the hNodeB. I noticed that no matter how long I wait, no Paging
is sent out anymore, and found this embarrassing issue. Good grief...
The choice of 10 seconds is taken from https://osmocom.org/issues/2756
Change-Id: I2db6f1e2ad341cf9c2cc7a21ec2fca0bae5b2db5
These rx functions are only used for the A interface, hence the names should
not suggest general SCCP rx (which Iu also has).
Change-Id: I6815c3d4dea4c2abfdff1cf0239ada6a9254f351
Add LOGPBSCCONN for struct bsc_conn.
Use LOGPCONN or LOGPBSCCONN whereever possible.
Tweak a few log messages and remove one redundant log.
Change-Id: If9cb0e7a5cef2ec37a1a7c548aecf11a11c22eec
The target buffer in libsmpp is 16 bytes long, and snprintf() may omit the
terminating zero. There seems to be no handling for unterminated strings, so
osmo_strlcpy() is the safer (and presumably more optimal) choice.
Change-Id: I5845666201f945ea9f83da62f2dd4bec52eb74cf
In case of UMTS AKA, the Kc for ciphering must be derived from the 3G auth
tokens. tuple->vec.kc was calculated from the GSM algorithm and is not
necessarily a match for the UMTS AKA tokens.
So far we were always sending the Kc retrieved from osmo-hlr. If the 2G auth
algo is set to milenage, the 2G Kc coincides with the one derived from 3G
tokens, but if 2G is set to a different algorithm, the Kc received from the
osmo-hlr is not usable for ciphering when UMTS AKA was used for authentication
(on R99 capable GERAN and MS).
Implementation: To decide whether to use UMTS AKA derived Kc or the Kc from the
auth vector, use the umts_aka flag added to set_ciph_mode() in a previous
patch. Use osmo_auth_c3() to derive the GSM AKA Kc from the UMTS AKA CK and KI.
Related: OS#2745
Requires: I85a1d6ae95ad9e5ce9524ef7fc06414848afc2aa (libosmocore)
Change-Id: If04e405426c55a81341747a9b450a69188525d5c
In case of UMTS AKA, the Kc for ciphering must be derived from the 3G auth
tokens. tuple->vec.kc was calculated from the GSM algorithm and is not
necessarily a match for the UMTS AKA tokens.
To decide (in an upcoming patch) whether to use UMTS AKA derived Kc or the Kc
from the auth vector, the set_ciph_mode() from vlr_ops needs to know whether
UMTS AKA is being used. This could possibly derived from the msc_conn_ref, but
all flags are already available in the vlr_lu_fsm and vlr_access_req_fsm. Hence
add a umts_aka flag to the set_ciph_mode() callback invocation. The VLR FSMs
thus decide whether UMTS AKA or GSM AKA is to be used during Ciphering Mode
Command, which makes more sense than re-implementing the same decision process
in the MSC.
I considered placing the Kc derivation in vlr_set_ciph_mode() and only tell the
MSC's set_ciph_mode() implementation the precise keys it should use, but the
RAN particulars, and whether a Kc is used at all, rather belong with the MSC.
Related: OS#2745
Prepares: If04e405426c55a81341747a9b450a69188525d5c
Change-Id: I983c48347faf4ee1b405d8174b4e006c904157cf
a_iface_tx_cipher_mode() is a bit too far away from the VLR to be handling its
ciphering enums. Instead, construct the gsm0808_encrypt_info in the
msc_vlr_set_ciph_mode() callback.
Greatly simplify the sanity checking code: a_iface_tx_cipher_mode() no longer
needs to re-verify the presence of the gsm0808_encrypt_info contents.
Change-Id: Id46f9a513b555d0a481f7124c9984c2b5b196b3e
The bit shifting is performed in gsm0808_enc_encrypt_info(), and must not be
done when populating the gsm0808_encrypt_info struct.
Provide vlr_ciph_to_gsm0808_alg_id() to translate the enum vlr_ciph to the
GSM0808_* constants we need to put in the gsm0808_encrypt_info struct instead.
Related: OS#2745
Change-Id: If75f95e8a5cc8b9979610ce6d746c1f0073ee39a
When the subscriber has no MSISDN, we might construct an invalid SQL statement
such as
... AND dest_addr= AND ...
Instead, don't even query for empty MSISDNs.
Related: OS#2706
Change-Id: I7d6169d774b2da04b3051957e364fe620feed51e
Adjust test expectations accordingly.
The error was:
==16084==ERROR: AddressSanitizer: heap-use-after-free on address 0x61500000f5f4 at pc 0x561be639ac2b bp 0x7ffc0aabbe40 sp 0x7ffc0aabbe38
READ of size 4 at 0x61500000f5f4 thread T0
#0 0x561be639ac2a in _msc_subscr_conn_put ../../../../src/osmo-msc/src/libmsc/osmo_msc.c:384
#1 0x561be636070b in rx_from_ms ../../../../src/osmo-msc/tests/msc_vlr/msc_vlr_tests.c:204
#2 0x561be6360b21 in ms_sends_msg ../../../../src/osmo-msc/tests/msc_vlr/msc_vlr_tests.c:217
#3 0x561be635b40a in test_call_mt ../../../../src/osmo-msc/tests/msc_vlr/msc_vlr_test_call.c:328
#4 0x561be6363bb7 in run_tests ../../../../src/osmo-msc/tests/msc_vlr/msc_vlr_tests.c:802
#5 0x561be63524ea in main ../../../../src/osmo-msc/tests/msc_vlr/msc_vlr_tests.c:849
#6 0x7f6eebb3e2b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#7 0x561be6352fb9 in _start (/n/s/osmo/make-3G/osmo-msc/tests/msc_vlr/msc_vlr_test_call+0xdafb9)
Related: OS#2672
Change-Id: If0659a878deb383ed0300217e2c41c8c79b2b6a5
If a conn is attempted to be used when in release, log an error, but don't skip
tracking.
No current code path apparently hits this, according to msc_vlr_tests. Just
making sure that we will prominently see such errors when we introduce any.
Change-Id: I8dd20ee56ce5ad7a90fcd03a06604c383e5eed54
When hunting a conn use count bug, it was very hard to figure out who's (not)
using the conn. To ease tracking down this bug and future bugs, explicitly name
what a conn is being reserved for, and track in a bit mask.
Show in the DREF logs what uses and un-uses a conn. See the test expectation
updates, which nicely show how that clarifies the state of the conn in the
logs.
On errors, log them, but don't fail hard: if one conn use/un-use fails, we
don't want to crash the entire MSC before we have to.
Change-Id: I259aa0eec41efebb4c8221275219433eafaa549b
The BSC rate counters are a leftover from the nitb split.
Accessing them would result into a null-pointer exception,
because the struct isn't initialized.
Change-Id: I8c72ab8bf781d3f9a436eb1a27ac4d13df5e656b
If dispatching a conn timeout, the conn fsm will already have been discarded,
and we cannot fire any more events to it.
The expected test output changes illustrate that we are now omitting event
dispatches that happen *after* the same FSM was already deallocated.
Change-Id: I25af3e5a1b04e3a5c9f41956cbcbbdd8439c6457
The log message after the nullpointer check for conn tricks Coverity
Scan into detecting a nullpointer deref.
Include the log message into else branch to state the program flow
more clearly
Fixes: Coverity CID#178656
Change-Id: If6e962f4033c955ecd3539a719031a83c9b6205a
The reset context contains a string buffer to allow for setting
a human readable name, that is then displayed in the logs. Since
OSMO-FSMs already have such a feature there is no need for an
extra name variable.
Use LOGPFSML and the name parameter of osmo_fsm_inst_alloc()
to display the name of the FSM
Fixes: Coverity CID#178664
Change-Id: I5b051606791c5e085ca6bb1be20592127d48ceb5
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
vty_install_default() and install_default() will soon be deprecated.
Depends: I5021c64a787b63314e0f2f1cba0b8fc7bff4f09b
Change-Id: I34708c73d8084db4e6c83a39be8fdaeaa492d743
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
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
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
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
The function gsm0408_dispatch() accepts a message buffer pointer
and accesses the l3h pointer. Even in a properly allocated
message buffer, this may lead into a segfault if the user forgets
to set the l3h pointer. This commit adds assertions to popup a
more expressive error message.
Change-Id: I43bd9bd1c170559aaa8dacaef25dba090744bcd5
Max
Pau Espin
Alexander Huemer
Philipp Maier
Harald Welte
Neels Hofmeyr