aboutsummaryrefslogtreecommitdiffstats
path: root/src/libvlr/vlr_auth_fsm.c
AgeCommit message (Collapse)AuthorFilesLines
2024-03-01libvlr: fix auth_fsm_term(): use proper value-string for causeVadim Yanitskiy1-1/+1
Change-Id: Ia0868dce2da5cb78c30cf518870c3d91144499b9
2024-03-01libvlr: fix wrong cause value passed to auth_fsm_term()Vadim Yanitskiy1-1/+2
This was found thanks to clang (-Wenum-conversion): warning: implicit conversion from enumeration type 'enum gsm48_gmm_cause' to different enumeration type 'enum gsm48_reject_value' [-Wenum-conversion] Change-Id: I0b820bb2a8e561682a8158fc51bd9565f5912d56
2024-03-01libvlr: auth_fsm_wait_ai(): cosmetic: drop redundant breakVadim Yanitskiy1-1/+0
Change-Id: Iaa2962bfe67902f6b4aa944b73fa97db46bc9c54
2022-10-27vlr_auth_fsm: add result no_auth_info_eventNeels Hofmeyr1-25/+49
Add third outcome of auth_fsm: the no_auth_info_event, which should be dispatched when auth failed because the HLR has no auth info for this subscriber, i.e. not because an actual auth challenge failed. No functional change: Handling no_auth_info_event separately follows in another patch (to allow fallback to no-auth). Feed the same _E_AUTH_FAILURE as no_auth_info_event to still behave unchanged. Related: OS#4830 Change-Id: I5103b1f2727f1729a5517ae359df813d50436ed3
2022-10-27vlr: auth_fsm: clarify success/failure resultNeels Hofmeyr1-8/+20
Explicitly send distinct parent events on auth success and failure. So far determining success depended only on the data pointer passed on with the event. Distinct events clarify the logging and the FSM code. This prepares for a third FSM outcome to be added in a subsequent patch, to separately signal when the HLR has no auth data. No functional change. Related: OS#4830 Change-Id: I02776dfe6785983f2ebe398f57867f5ceb288ba0
2021-08-24vlr_auth_fsm.c: Simplify function auth_fsm_wait_ai_resyncPau Espin Pedrol1-7/+3
Change-Id: I2070002dea18b728deef5547b4deb6166cfcab6a
2020-01-27vlr: remove unused parameter 'log_level' of auth_fsm_start()Vadim Yanitskiy1-1/+0
We unconditionally use logging level of the parent FSM anyway. All callers of auth_fsm_start() always pass fi->log_level. Change-Id: If2fdf2564eb56d3d94ec3800bdcb0aabcad4e48d
2019-11-19Fix some typosMartin Hauke1-1/+1
Fix typos and common misspellings in code comments and log messages. Change-Id: Ie66b89065f2100c1d2125ce5a6c9b1d58df7c8ad
2019-10-17vlr_auth_fsm: on SAI use the GSUP provided GMM cause codeAlexander Couzens1-7/+8
The HLR might respond with a specific GMM cause code. E.g. roaming not allowed which needs to be passed down the layers. Change-Id: I9af515dc52834b7c57c42fc3a76ee2c682734e2a
2019-03-19libvlr: Allow 2G auth tuples to be re-used without going through AUTHSylvain Munaut1-0/+15
If the key_seq we get in the first messages matches the last_tuple, then both we and the MS already know the key to use and we don't need the AUTH REQUEST/RESPONSE cycle. Security wise ... not so good, and so IMHO the 'auth required' option in the MSC should always be set. But this allows to turn on ciphering on a channel without doing any MM transaction, and so the MS doesn't turn on the T3240 timer which allows to have a ciphered silent-call channel that won't timeout. Change-Id: Ief840a2ae7a0ffd2bf0bf726f209a79e3f787646 Signed-off-by: Sylvain Munaut <tnt@246tNt.com>
2019-01-04vlr: auth_fsm: make sure vsub->auth_fsm = NULL when it terminatesNeels Hofmeyr1-3/+7
Probably fixes this segfault: at ../../../../src/osmo-msc/src/libvlr/vlr_lu_fsm.c:957 file=file@entry=0x5611d8f10c28 "../../../../src/osmo-msc/src/libvlr/vlr_lu_fsm.c", line=line@entry=1467) at ../../../src/libosmocore/src/fsm.c:580 parent_event_failure=parent_event_failure@entry=6, parent_event_data=parent_event_data@entry=0x0, vlr=0x5611d98862b0, msc_conn_ref=msc_conn_ref@entry=0x5611d9aa8150, type=VLR_LU_TYPE_REGULAR, tmsi=4294967295, imsi=0x7ffd756c1cf0 "262423403004874", old_lai=0x7ffd756c1ce0, new_lai=0x7ffd756c1ce8, authentication_required=true, ciphering_required=true, is_r99=false, is_utran=false, assign_tmsi=true) at ../../../../src/osmo-msc/src/libvlr/vlr_lu_fsm.c:1467 at ../../../../src/osmo-msc/src/libmsc/gsm_04_08.c:443 The segfault is indirectly caused by 1fbf45c291f7e1f09ef2e862abfeca6a23efdc03, 'enrich context for vlr_subscr_name and ran_conn fi name', which sets auth_fsm context, on a non-NULL auth_fsm that has been deallocated. Change-Id: I3c528eed295be2ee673ea295804372f388a0dccd
2018-11-30move gsm_auth_tuple to vlr.h as vlr_auth_tupleNeels Hofmeyr1-9/+9
Along goes GSM_KEYSEQ_INVAL as VLR_*. It's where it logically belongs, and is almost the only reason why vlr.h includes gsm_data.h. The remaining reason, GSM_EXTENSION_LENGTH, will be moved by upcoming patch. Change-Id: I122feae7ee3cbc59e941daef35a954bce29fec76
2018-04-12refactor VLR FSM result handlingNeels Hofmeyr1-26/+24
Instead of keeping separate enums for FSM results and translating between those and the actual 04.08 reject causes that will ultimately reach the MS, just pass enum gsm48_reject_value cause codes around everywhere. Collapse some VLR *_timeout() and *_cancel() api to just *_cancel() with a gsm48 cause arg. (Hopefully) improve a few reject causes, but otherwise just aim for more transparent decisions on which cause value is used, for future fixes of returned causes. Depends: I6661f139e68a498fb1bef10c266c2f064b72774a (libosmocore) Change-Id: I27bf8d68737ff1f8dc6d11fb1eac3d391aab0cb1
2018-03-15cosmetic: vlr_auth: log decision to send UMTS or GSM AKA challengeNeels Hofmeyr1-6/+7
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
2018-03-10cosmetic: vlr_auth_fsm: log RAN and size along with SRES/RESNeels Hofmeyr1-2/+4
Change-Id: Ib0f9f573ffac2302fbd3ee28f48ccd8fce5fe286
2018-03-10cosmetic: vlr_auth_fsm: clarify decision on UMTS AKA or GSM AKANeels Hofmeyr1-19/+42
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
2018-02-08GSUP: check osmo_gsup_encode() resultMax1-4/+9
Check and handle gracefully any error which might appear in osmo_gsup_encode() - mark corresponding functions with warn_unused_result attribute to make sure this failure is always checked against. Change-Id: I4551212011fb0bd898c020a183756ed7a9afb9e5 Related: OS#2864
2017-12-18cosmetic prep: publish vlr_use_umts_aka() decisionNeels Hofmeyr1-11/+1
During Set Ciphering Mode on GERAN, it is required to know whether UMTS AKA is used to decide which Kc to pick. Change static function is_umts_auth() into public vlr_use_umts_aka(), so future patches can re-use it. Prepares: If04e405426c55a81341747a9b450a69188525d5c Change-Id: I85d784c62ecbabdb6186a3dae4dcd554e7921041
2017-11-12vlr: auth_fsm_start: check return value of fsm allocNeels Hofmeyr1-1/+4
Fixes: coverity CID#178663 Change-Id: I7d1c15b546377b1afa38f7f40c5421b743e21605
2017-10-31cosmetic: vlr: rename auth_tuple_max_use_count to _reuse_Neels Hofmeyr1-16/+16
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
2017-09-06rename include/openbsc to include/osmocom/mscNeels Hofmeyr1-2/+2
Change-Id: I1f96a1285bbd1b4607614856bca935d5c26e2da9
2017-07-21Add libvlr implementationHarald Welte1-0/+605
Original libvlr code is by Harald Welte <laforge@gnumonks.org>, polished and tweaked by Neels Hofmeyr <nhofmeyr@sysmocom.de>. This is a long series of trial-and-error development collapsed in one patch. This may be split in smaller commits if reviewers prefer that. If we can keep it as one, we have saved ourselves the additional separation work. Related: OS#1592 Change-Id: Ie303c98f8c18e40c87c1b68474b35de332033622
generated by cgit v1.2.3 (git 2.25.1) at 2024-04-16 14:33:14 +0000