Age | Commit message (Collapse) | Author | Files | Lines |
|
These tests helped to debug issue OS#2779. Now that they're here we might as
well keep them.
The test test_call_mo_to_unknown shows that an MS answering to the Release
Request works as it should: the conn is torn down.
The test test_call_mo_to_unknown_timeout currently expects the error: the conn
remains active if the CC Release times out. This bug and the test expectations
will be fixed in I46ff2e9b09b67e4e0d79cccf8c04936f17281fcb.
Change-Id: Ic3c84520bff8c3fc82512d03ff6ab97d21b8fb7a
|
|
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
|
|
See also change-id I72a1dbb30e0a39dbf4b81c7e378d5607b62e10d3 in
osmo-ttcn3-hacks.git, which adds a similar test to the MSC_Tests.ttcn suite.
Writing this test helped me fix the issue faster, why not keep it now that it's
there.
Related: OS#2947
Change-Id: Iba56556207cf6e79e6531b0e7dd3eaec28fb5eaa
|
|
Change-Id: Ib0f9f573ffac2302fbd3ee28f48ccd8fce5fe286
|
|
The code deciding on whether UMTS AKA is used was cascaded and convoluted. By
flattening the decisions, they become easier to read and possibly catch more
weird corner cases / log information more clearly.
- First decide what AKA the RES length reflects.
- Then decide whether all prerequisites for UMTS AKA are satisfied.
- Finally, on UTRAN, turn down the auth if we don't have UMTS AKA, and neatly
log all of the potential causes.
One corner case that should never occur is that the UMTS AKA RES length is
actually the same length as the GSM AKA SRES. If this nevertheless occurs, log
this as an error, though not turning down authentication because of it. (The
effect is that we would favor UMTS AKA when it has a res_len == sizeof(sres)
and would not succeed to GSM AKA. At least the log will tell us why, now.)
Adjust an expected test output, trivial logging difference.
Change-Id: I43f7f301ea85e518bac91f707391a53182e54fab
|
|
Change-Id: I0e9099625bd9d3de3db5ee29fbf81b2d8a30071d
|
|
Change-Id: Ie5473f06fc2d04c6a9f343da5764ec95b292a5f9
|
|
Change-Id: Ia1bc57b3dc1f3c3c654ba2d907b16ba925cd03e8
|
|
Change-Id: Iba43c685cbe238d96175267e9cc954b2f2f3e7fc
|
|
Instead of just closing down the conn hard, actually feed invalid auth response
data to vlr_subscr_rc_auth_resp() in order to trigger all the actions we want
to see with a failed authentication:
- a GSUP signal that the auth failed,
- a LU reject.
Verify this in new test_wrong_sres_length() in msc_vlr_test_gsm_authen.c.
Note that in gsm48_rx_mm_auth_resp(), the is_r99 flag is falsely derived from
the RES length, which upcoming commit Ib7f7d89a8b9455d2c022d53d74328fa7488577f4
will fix.
Change-Id: I4179a290069ac61d0662de4ec7ca3edb76988899
|
|
Switch by vsub->sec_ctx to use the proper Kc for ciphering.
Even on an R99 capable MS with a UMTS AKA capable USIM, the MS may still choose
to only perform GSM AKA, as long as the bearer is GERAN. The VLR already stores
whether the MS replied with a GSM AKA SRES or a UMTS AKA RES in vsub->sec_ctx.
So far, though, we were always using the UMTS AKA Kc just because the USIM and
core net are capable of it, ignoring the choice the MS might have made in the
Authentication Response.
In msc_vlr_test_gsm_ciph, fix the test expectations to the correct GSM AKA Kc
keys, showing that all of LU, CM Service Request and Paging Response now
support MS choosing GSM AKA in a UMTS capable environment.
Related: OS#2793
Change-Id: I42ce51ae979f42d173a45ae69273071c426bf97c
|
|
Even on an R99 capable MS with a UMTS AKA capable USIM, the MS may still choose
to only perform GSM AKA, as long as the bearer is GERAN. In that case, we must
make sure to send the GSM AKA Kc for ciphering.
Add test_gsm_ciph_in_umts_env() to msc_vlr_test_gsm_ciph.c to answer an Auth
Request with a GSM AKA response (see the log stating "AUTH established GSM
security context" after we sent a UMTS AKA challenge).
In the test, show that we currently send the *wrong* Kc, i.e. the UMTS AKA
derived Kc for GERAN, instead of the correct Kc for GSM AKA (which was received
from the HLR in the auth tuples).
Subsequent patch I42ce51ae979f42d173a45ae69273071c426bf97c will fix this and
correct the test expectations.
Related: OS#2793
Change-Id: I85f12a20dcd701e671188e56811ec7b58d84da82
|
|
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
|
|
All functions in the individual msc_vlr_test_*.c files should be static; hence
we would be warned if one of them were unused (forgotten to add to the tests
array).
Change-Id: Ia169c6a1443a48879ab4777e09c2040c48810bf6
|
|
This test is actually in msc_vlr_test_rest.c, shouldn't be copied here, and was
anyway unused.
Change-Id: I9bba10a05d43f7f94aa2cd6dcb63dd8f2f644d35
|
|
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"
b0a4314911140b1599cccfc8171fcdab4cd9bfab.
- "Expand VLR tests"
d5feadeee8dd24f991df2892d6bcf0be8b0cf707.
- "Move IMSI into test parameters"
093300d141c300651954473d73138b72de04d931.
Change-Id: Ie1b49237746751021da88f6f07bbb9f780d077c9
|
|
All callers pass mcc=1, mnc=1, so just have it as default.
(Prepare for net->country_code etc to be replaced by net->plmn)
Change-Id: Ibcd1cc38f170895305ae176a5574384c74a33939
|
|
This is yet another unsused bit from the OsmoNITB legacy.
Related: OS#2528
Change-Id: I825e659da529257e5edec94d9d59f0e10c1b4c63
|
|
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
|
|
Related: OS#2528
Change-Id: I332aa8697c98a0d7b3db65f98711275da3d381d7
|
|
That's a preparation step for properly splitting main function of
different tests in follow-up function.
Change-Id: I68a2e94cf79fcb83286eef981a8d88bdbe10ef69
Related: OS#2864
|
|
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
|
|
Having while(0) as a body for for() cycle generate too much WTF while
looking at the code while not serving any obvious purpose. Let's just
drop it to avoid confusing developers.
Change-Id: I1f571ec319ff3231fd9acd4066e470476c3b1f78
Related: OS#2864
|
|
Don't fail tests using thwart_rx_non_initial_requests() via
OSMO_ASSERT. Instead log extended error which will fail the test
eventually but allows to gather additional info helpful for debugging.
Change-Id: I2607cb1ac60941dbc22fca532ed2b3738bfbcc63
Related: OS#2864
|
|
Print the IMSI used for each test. This enables expansion to tests with
several IMSIs in follow-up patches.
Change-Id: I7958608e5136351f7b7c0c57fe79791d989ce9c3
Related: OS#2864
|
|
Related: OS#2864
Change-Id: I5eac4c24257fd38068ba629d3c21848181703220
|
|
This makes test routines more flexible and allows to easier re-use them
for tests with different IMSIs.
Change-Id: I74d46fdb7e87dc04c6b82a0b6f3ce6bef60bde58
Related: OS#2864
|
|
We don't usually put space before in-place increment or decrement. Let's
make code look similar to other Osmocom projects.
Change-Id: I5962431ad16c97e412939dc1b8949f6361a5c26e
|
|
in the current implementation we still use osmo-bsc_mgcp, which
has many problems and is also obsoleted by osmo-mgw.
integrate osmo-mgw and re-implement the current switching using
an osmo fsm.
Depends: osmo-mgw Iab6a6038e7610c62f34e642cd49c93d11151252c
Depends: osmo-iuh I3c1a0455c5f25cae41ee19229d6daf299e023062
Closes: OS#2605
Change-Id: Ieea9630358b3963261fa1993cf1f3b563ff23538
|
|
According to TS 24.007 Section 11.2.3.2.3, it is possible that uplink L3
messages are duplicated in some scenarios, particularly during
assignment/handover procedure.
To avoid L3 entities from seeing duplicated messages, there's a modulo-2
or modulo-4 message sequence counter, based on which the MSC can detect
and suppress such duplicate messages.
It appears that even our unit tests were wrong in that regard so far.
Rather than manually adjusting each and every message, let's make sure
that the sequence number generation always increments as expected, and
that during matching of incoming messages, sequence numbers are masked
out.
Note: the tests will only pass from libosmocore Change-Id
Iec875a77f5458322dfbef174f5abfc0e8c09d464 onwards, due to
gsm48_hdr_msg_type() being broken in earlier versions.
Change-Id: Id15e399ab7e1b05dcd426b292886fa19d36082b1
Closes: #2908
|
|
So far, the administrator had to pick one particular cipher which
would then be used throughout all subscribers/phones. This is a bit
impractical, as e.g. not all phones support A5/3. Extend the VTY
command syntax in a backwards-compatible way to permit for multiple
ciphers.
NOTE: Like the previous code, OsmoMSC does *not yet check* whether
the configured cipher is compatible with the MS capabilities as
reported in CLASSMARK! The network hence might choose an algorithm
not supported by the phone. Fixing this is subject to another patch.
Closes: OS#2460
Change-Id: I79a4e2892eb5fbecc3d84e11dceffb7149db264b
|
|
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
|
|
osmo-msc still had large amounts of dead code that came along from
openbsc.git. This commit removes a lot of it, mostly stuff relevant
only to the BSC side of things (or even GPRS).
Change-Id: I247def85da2dc3ec461389fb74414a0d964e7e3c
Related: OS#2528
|
|
Change-Id: I8672f0a76cb47595444a7ddbc4f34fc4ddaeb375
|
|
In I8de7c01f9ea1d66c384e57449c4140186f5ce6c5, libosmocore introduced
shorter names in gsm48_pdisc_names, which has implications on the
expected test output
Change-Id: I4421872a0d609dd50a6b911b928aa5e111d1ad24
|
|
Measurement reporting (and the relate feed) are functions of the BSC,
not the MSC. This code should never have been inherited from OsmoNITB
to OsmoMSC in the first place, let's remove it.
Change-Id: I0d57ac214e574e267fa9752daf76566197b9aa64
|
|
* 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
|
|
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
|
|
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
|
|
Change-Id: Ib19dfd7255bda01ebace62386df4ec89697d9d14
|
|
DLSMS logs SMS pointers, so is not suitable for logging them always. Allow
logging for manual invocation, though.
Change-Id: I1b7d2fd3fb38bf50eeabd6f7ef736d70a17de7a6
|
|
The ipa.py has been moved to osmo-python-tests as osmo_ipa - use it for
vty and ctrl tests instead of local copy. The soap.py and twisted_ipa.py
are not MSC-specific: leftovers from repository split which are now
available in osmo-python-tests as well.
Change-Id: Ia3ab77846c9beae7eca32a81079a4a9bfa4dcc75
|
|
All the CTRL tests were skipped automatically because they were
inherited from before repo split time. This means that MSC CTRL
interface was not tested at all. Add trivial test which uses generic
rate counter introspection so we at least check that MSC's CTRL
interface is not completely broken.
Change-Id: I784feece666b00752a81f2c126e6f255505445be
|
|
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
|