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
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
Do not interpret the SRES/RES length returned in the auth response as the R99
capability bit, instead determine it from the actual Classmark information
associated with the conn.
This fixes the is_r99 flag passed in to vlr_subscr_rx_auth_resp(), which ends
up in the struct vlr_auth_resp_par dispatched to the auth_fi and influences the
authentication acceptance.
Though the effect of a wrongly-set-to-false R99 flag is not harmful in this
code path, let's not get this confused.
Change-Id: Ib7f7d89a8b9455d2c022d53d74328fa7488577f4
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
In gsm_silent_call_{start,stop}(), return meaningful error codes and interpret
them on the VTY to clearly indicate the result.
Change-Id: Id5abb8f2ba901689e03040af8e51483b6c618e7f
Rationale: in the HLR, it is called 'msisdn' after the database column, so a
user going back and forth between osmo-hlr and osmo-msc would appreciate being
able to type 'msisdn' in the MSC's vty as well.
Change-Id: I7b46f9736421e8edd8a95ae89e025ebe486fde4c
Before this, it was for example possible to crash the MSC by the vty 'show
subscriber' command, which would dereference a potentially stale
vsub->msc_conn_ref pointer.
Related: OS#3050
Change-Id: Ia4105d9f135ba3216ad3c86157be7658b1d568fb
When osmo-msc restarts it looses all information about the BSC. The
BSC will not be aware of the reboot and on the next communication
attemt it will notice that something is wrong and start the reset
procedure on his side. osmo-msc will receive the reset messages
and send a reset.
The reset is received. Osmo-msc detects that no context information
is created yet. The context is created. Then it is checked if the
UNITTDATA message that came in is a reset. If it is one. Nothing
happens. The UNITTDATA is passed on and triggers the RESET-ACK
some layers above. Unfortunately by the current code this also
means that no reset FSM is created and therefore a_reset_conn_ready()
can never be true. Which means it will also drop any legitimate
reset from the BSC in the future.
- Ensure that the reset FSM is always created when a new BSC
context is created
- Make sure that reset related traffic always passes so that
the higher layers can handle the procedure properly
Change-Id: I3fdcec5dbeaa0e21fd6a92568a623faa368239be
The vlr_subscr_get() can return NULL if its argument is NULL
(which isn't checked for) so before dereferencing it's result
we should check for it.
Change-Id: I13632908d0b67323202effa9dd6f29732a12cc91
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
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
Various functions in vlr_lu_fsm.c belong to one of the four FSMs defined in
that file. After the recent error was uncovered where the lu_fsm called
lu_compl_fsm()'s termination function, I want to make sure it's correct.
Introduce distinct inline functions to dereference the respective fi->priv
pointers, each asserting that the fi indeed belongs to the proper FSM. Use
those *everywhere* to dereference fi->priv.
From this patch on, we are sure beyond doubt that we are not inadvertently
passing an fi pointer to the wrong FSM's handling functions, though we will
only catch this at runtime -- but then will immediately know the reason.
vlr_lu_fsm.c is the only file defining more than one FSM, so the other FSM
definitions are already reasonably safe.
Change-Id: I7419a780ff2d8b02efc4195bb1702818e4df181c
From the vlr_loc_update() FSM, don't call the vlr_lu_compl_fsm_failure()
function. These are two distinct FSMs with distinct priv pointers, but they are
defined in the same .c file.
In vlr_loc_upd_post_auth(), change two erratic calls of
vlr_lu_compl_fsm_failure() to lu_fsm_failure(), so that the proper fi and priv
struct are used.
Fixes: OS#2947
Change-Id: I7fd2c6fa23254fffd0d526e53541f4068153929f
Add 3-digit flags and use the new RAI and LAI API from libosmocore throughout
the code base to be able to handle an MNC < 100 that has three digits (leading
zeros).
Depends: Id2240f7f518494c9df6c8bda52c0d5092f90f221 (libosmocore),
Ib7176b1d65a03b76f41f94bc9d3293a8a07d24c6 (libosmocore)
Change-Id: I82f0016d9512ee8722a3489a3cb4b6c704a271fc
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
The FSM (fsm_msc_mgcp) lacks a proper definition of the FSM event
names. This causes problems when inspecting the FSM using the VTY.
- Add proper FSM Event names
Closes: OS#2924
Change-Id: I6823756a63b08a71e5518130e49751aa073dbcd2
The FSM lacks a proper definition of the FSM event names. This causes
problems when inspecting the FSM using the VTY.
- Add proper FSM Event names
Change-Id: I76d7d9e0accffd433a3f3b5e5f8ab17ecd4a348c
Related: OS#2924
Call osmo_fsm_vty_add_cmds() to make osmo_fsm VTY commands available
in osmo-msc's VTY interface.
Change-Id: Iaf970f6039c3f668f275dd8c21fb9071774a5d9e
Related: OS#2967
Change I0d57ac214e574e267fa9752daf76566197b9aa64 forgot to remove this
file along with meas_feed.c.
Note also the weirdness: that patch removes the proper
include/osmocom/msc/meas_feed.h, but there's also this other one.
This libmsc/meas_feed.h always existed from the start as an unused
orphan, see:
https://git.osmocom.org/osmo-bsc/diff/openbsc/src/libmsc/Makefile.am?id=b4771a6871efb3cf12b371aedc575912984ca528
No need to drop from Makefile.am, since it is already gone from there.
(meas_feed from the old osmo-nitb (openbsc.git) has / should have moved to
osmo-bsc. There are no measurement reports in the MSC. Refer to osmo-bsc.git
instead from now on.)
Change-Id: Ib2566013dd30b21ce2774cd4cc7dcba2408f938f
The ID will include the type of connection (GERAN_A, UTRAN_IU) followed
by the SCCP conn_id.
This can be used for the fsm instance ID before we know the IMSI.
Change-Id: I4b875772e3994ad3458ee60dbf880604486d9afd
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
OsmoMSC is using whatever reject cause is apropriate in the given
situation. This user-configurable reject cause only had relevance
in OsmoNITB, and hence it is an unused parameter that can be removed
in OsmoMSC.
Related: OS#2528
Change-Id: Ie1f39e706477aaf42051877b52d4b3ae1c5f138e
This belongs into the BSC and has no relevance in the MSC, as the MSC
has no clue about dynamic timeslots.
Related: OS#2528
Change-Id: Iaa41d22db81120572d4cd2c0c4c75d258947a42f
The mncc_rtp_create_pending and mncc_rtp_connect_pending members
were unused, let's remove them.
Related: OS#2528
Change-Id: I417e23ec53323ddd8e1e5d18952566fe8fd6ac24
When we receive bearer capabilities from MNCC and encode thme into
a CC message, we have to also update our "cache" inside 'struct
gsm_trans'. Only that way, the BSSMAP ASSIGNMENT code is aware of
the actual current/present bearer capabilities such as permitted speech
codecs.
This will in practise only work if the related CC/MNCC message with
berer_cap IE will happen before the MSC performs the BSSMAP ASSIGNMENT
procedure. Our logic still needs to change in a way that the CC/MNCC
code in gsm_04_08.c detects if trans->bearer_cap != new bearer_cap, and
in that case triggers a new follow-up BSSMAP ASSIGNMENT.
Change-Id: I6838dc0c8c4c2c6bba385da548c92f3fc91060c1
Closes: OS#2854
When we receive a MNCC_SETUP_REQ primitive from the external MNCC
handler, we must not only encode it into the TS 04.08 CC SETUP, but
also keep it around in the "trans" structure representing this voice
call, as it is needed e.g. at BSSMAP ASSIGNMENT time.
Change-Id: Ib6919d148ff6687112e8166dbde947be19e70a76
Related: OS#2322
Closes: OS#2929