The naming of "bump" was short and made sense to me at the time of writing, but
it is keeping pretty much everyone else at a distance, no-one intuitively gets
what it is supposed to mean.
Clarify by renaming to "release_when_unused".
Adjust test expectations.
Change-Id: I4dcc55f536f63b13a3da29fff1df5fe16751f83a
There are a number of bad failures in CC teardown handling we're solving. It
helps to see CC logging in the msc_vlr_tests.
Change-Id: I56ac269d46b48b6b85efad81c4d2343bfc41ea90
Also indicate in msc_vlr_test_gsm_authen.c that we're indeed sending no
capability to do R99 in the Classmark 1 during LU request.
Change-Id: Id79a77ca1f218d55dad21d9dd3de92445fb5d6bf
Clearly distinguish between Ciphering Mode Command on GERAN and Security Mode
Control on UTRAN.
Cosmetic: explicitly verify the key strings in the testing code (not only in
the expected output).
Change-Id: Ica93ed06c4c63dc6768736d25231de8068001114
Actually call msc_vlr_set_ciph_mode() and wrap away a_iface_tx_cipher_mode()
and ranap_iu_tx_sec_mode_cmd(). Hence we'll see decisions and errors in
msc_vlr_set_ciph_mode() as well.
Change-Id: Id23bc245d4b5707edcd27c44db272fbb211bf9bd
Three recently merged commits take the msc_vlr_tests in a wrong direction.
The IMSI is usually encoded in the hex streams. The rationale behind hex
streams is that it is a) easily copied from a wireshark trace and b) exactly
the bytes as sent by an actual phone. It is hard to parameterize the IMSI
because we would have to employ our encoding functions, which I intentionally
want to keep out of the loop here.
The test number should not appear in the normal test output, so that adding a
test or changing their order does not affect expected output for following
tests. The nr is simply for manual invocation, only seen when invoked with -v.
Revert
- "VLR tests: always print test parameters"
b0a4314911.
- "Expand VLR tests"
d5feadeee8.
- "Move IMSI into test parameters"
093300d141.
Change-Id: Ie1b49237746751021da88f6f07bbb9f780d077c9
This is another left-over VTY command from the OsmoNITB days.
If such functionality is desired, it must be implemented in OsmoHLR,
but not here.
Related: OS#2528
Change-Id: Icf0897c47388e49ba7886b55acc728a6f7d213fe
For each test print:
* the test number
* IMSI
Unfortunately tests are organized in such a way that we don't know the
number of particular test in advance. Nevertheless, it make sense to
always print it regardless of -v option presense.
Related: OS#2864
Change-Id: I2e1d7701f5322d2311f32b796148a8b414f53b8e
The VLR code seems to have the assumption that there is one particular
algorithm to be used, as opposed to one of a set of algorithms.
What's missing is basically to decide when/where to pick the best
algorithm within the capabilities of the phone (classmark) and the
network configuration (net->a5_encryption_mask). So far, libvlr has no
notion of classmark. Rather, libmsc has.
Why does the VLR care about the particular algorithm at all? The VLR
should probably simply decide if it should use encryption or not, and if
so, the MSC will figure which algorithm to use.
Change-Id: I5ed80ca2086560a5975a758ec568a034a9a8ab89
In I8de7c01f9ea1d66c384e57449c4140186f5ce6c5, libosmocore introduced
shorter names in gsm48_pdisc_names, which has implications on the
expected test output
Change-Id: I4421872a0d609dd50a6b911b928aa5e111d1ad24
* move log helpers to generic header
* log subscriber update
It's handy for troubleshooting issues with subscriber update via GSUP
from HLR.
Change-Id: I1958aeeb3ea99831c7e2c5ee9a6b59834baf4520
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
On MT call, there is a bug in CC conn use which leads to an early free and
use-after-free.
Add msc_vlr_test_call to show both MO and MT call legs separately and reproduce
the failure. It is visible in a sanitizer build (on debian 9).
A subsequent patch will fix the bug: If0659a878deb383ed0300217e2c41c8c79b2b6a5
Related: OS#2672
Change-Id: I6c3ca0c660388b1e2c82df17ec540c846201b0c7
Neels Hofmeyr
Harald Welte