aboutsummaryrefslogtreecommitdiffstats
path: root/tests
AgeCommit message (Collapse)AuthorFilesLines
2018-11-09funeels/cc_timeoutNeels Hofmeyr3-8/+246
Change-Id: Idc4204fc5f9c7a051a6043fece76f5a99ab91327
2018-11-09add msc_vlr_test_call: test_call_mo_setup_timeoutNeels Hofmeyr1-0/+79
Change-Id: I1e5f2967b0458271c64e5bfc55e9ae67c72044d4
2018-10-24gsm_04_08_cc: Add global guard timer for MNCCPhilipp Maier1-0/+28
The external MNCC handler may hang indefinitely in cases where the remote end of the MNCC ceases to work properly. Add a global guard timer to make sure the call reaches ACTIVE state. Change-Id: I7375d1e17cd746aac4eadfe1e587e82cf1630d3d Related: OS#3599
2018-09-30GSUP client: send CN domain IE on LU requestNeels Hofmeyr24-175/+175
Give the HLR a chance to send us updated subscriber data by indicating the CN domain to be Circuit Switched, only during a LU Request GSUP message. Adjust msc_vlr_tests to expect the added GSUP CN domain IE to indicate CS, i.e. append '280102'. Related: OS#3601 Change-Id: I0c2d33fbfdb4728e480679120d06b7f3a2ccfd76
2018-09-17A5/n Ciph: request Classmark Update if missingNeels Hofmeyr7-26/+1565
When the VLR requests a Ciphering Mode with vlr_ops.set_ciph_mode(), and if we need a ciph algo flag from a Classmark information that is not yet known (usually CM 2 during LU), send a BSSMAP Classmark Request to get it. To manage the intermission of the Classmark Request, add - msc_classmark_request_then_cipher_mode_cmd(), - state SUBSCR_CONN_S_WAIT_CLASSMARK_UPDATE, - event SUBSCR_CONN_E_CLASSMARK_UPDATE. From state AUTH_CIPH, switch to state WAIT_CLASSMARK_UPDATE. Once the BSSMAP Classmark Response, is received, switch back to SUBSCR_CONN_S_AUTH_CIPH and re-initiate Ciphering Mode. To be able to re-enter the Ciphering Mode algo decision, factor it out into msc_geran_set_cipher_mode(). Rationale: In the following commit, essentially we stopped supporting A5/3 ciphering: commit 71330720b6efdda2fcfd3e9c0cb45f89e32e5670 "MSC: Intersect configured A5 algorithms with MS-supported ones" Change-Id: Id124923ee52a357cb7d3e04d33f585214774f3a3 A5/3 was no longer supported because from that commit on, we strictly checked the MS-supported ciphers, but we did not have Classmark 2 available during Location Updating. This patch changes that: when Classmark 2 is missing, actively request it by a BSSMAP Classmark Request; continue Ciphering only after the Response. Always request missing Classmark, even if a lesser cipher were configured available. If the Classmark Update response fails to come in, cause an attach failure. Instead, we could attempt to use a lesser cipher that is also enabled. That is left as a future feature, should that become relevant. I think it's unlikely. Technically, we could now end up requesting a Classmark Updating both during LU (vlr_lu_fsm) and CM Service/Paging Response (proc_arq_fsm), but in practice the only time we lack a Classmark is: during Location Updating with A5/3 enabled. A5/1 support is indicated in CM1 which is always available, and A5/3 support is indicated in CM2, which is always available during CM Service Request as well as Paging Response. So this patch has practical relevance only for Location Updating. For networks that permit only A5/3, this patch fixes Location Updating. For networks that support A5/3 and A5/1, so far we always used A5/1 during LU, and after this patch we request CM2 and likely use A5/3 instead. In msc_vlr_test_gsm_ciph, verify that requesting Classmark 2 for A5/3 works during LU. Also verify that the lack of a Classmark Response results in attach failure. In msc_vlr_test_gsm_ciph, a hacky unit test fakes a situation where a CM2 is missing during proc_arq_fsm and proves that that code path works, even though the practical relevance is currently zero. It would only become interesting if ciphering algorithms A5/4 and higher became relevant, because support of those would be indicated in Classmark 3, which would always require a Classmark Request. Related: OS#3043 Depends: I4a2e1d3923e33912579c4180aa1ff8e8f5abb7e7 (libosmocore) Change-Id: I73c7cb6a86624695bd9c0f59abb72e2fdc655131
2018-09-17msc_vlr_tests: cosmetically tweak perm algo printingNeels Hofmeyr2-13/+13
In the msc_vlr_tests, instead of printing the algo IDs, rather print the corresponding A5/n name, for clarity. Change-Id: Ic00f1e54490650bcb40170647b8ffd52ede23fd3
2018-09-17store classmark in vlr_subscr, not connNeels Hofmeyr2-8/+1
Store all Classmark information in the VLR. So, we now always know the Classmark 1 (mandatory IE for LU). This is visible in the msc_vlr_tests -- they no longer indicate "assuming A5/1 is supported" because classmark 1 is missing, because we now know the Classmark 1. Rationale: During Location Updating, we receive Classmark 1; during CM Service Request and Paging Response, we receive Classmark 2. So far we stored these only for the duration of the conn, so as soon as a LU is complete, we would forget CM1. In other words, for anything else than a LU Request, we had no Classmark 1 available at all. During Ciphering Mode Command, we rely on Classmark 1 to determine whether A5/1 is supported. That is moot if we don't even have a Classmark 1 for any CM Service Request or Paging Response initiated connections. The only reason that A5/1 worked is that we assume A5/1 to work if Classmark 1 is missing. To add to the confusion, if a phone indicated that it did *not* support A5/1 in the Classmark 1, according to spec we're supposed to not service it at all. A code comment however says that we instead want to heed the flag -- which so far was only present in a Location Updating initiated connection. Now we can make this decision without assuming things. This got my attention while hacking on sending a BSSMAP Classmark Request from the MSC if it finds missing Classmark information, and was surprised to see it it lacking CM1 to decide about A5/1. Change-Id: I27081bf6e9e017923b2d02607f7ea06beddad82a
2018-08-23cosmetic: mute "COMPLETE_LAYER_3 not permitted"Neels Hofmeyr3-12/+0
For networks without Authentication, the conn is already accepted when SUBSCR_CONN_E_COMPLETE_LAYER_3 is emitted. Mute that misleading error message. All is actually fine. Adjust expected test logs. Change-Id: I2d19d0a7cf3226ee1456f75a68e007ba98232402
2018-08-05Remove local libgsupclient; Use libosmo-gsup-client from osmo-hlrHarald Welte3-17/+19
osmo-hlr has recently (as of Change-Id Iad227bb477d64da30dd6bfbbe1bd0c0a55be9474) a working shared library implementation of libosmo-gsup-client. We can remove the local implementation in osmo-msc and use the system-installed shared library instead. Change-Id: I6f542945403cf2e3ddac419186b09ec0e2d43b69
2018-07-31migrate to oap_client in libosmogsmHarald Welte1-2/+2
libosmogsm in libosmocore.git from Change-Id Ie36729996abd30b84d1c30a09f62ebc6a9794950 onwards contains oap_client.c, so we don't need our local copy here in this repo anymore. Change-Id: Ib6496c35d0ce6eb531e97129dc45a9f68e503b34 Requires: libosmocore.git Change-Id Ie36729996abd30b84d1c30a09f62ebc6a9794950
2018-07-30libmsc/gsm_09_11.c: implement network-initiated sessionsVadim Yanitskiy2-6/+323
This change introduces a possibility to establish network-initiated SS/USSD transactions with a subscriber in either IDLE, or DEDICATED state. In the first case, a new transaction is established using Paging procedure. If a subscriber already has an active connection, a separate new transaction is established. TTCN-3 test case: I073893c6e11be27e9e36f98f11c1491d0c173985 Change-Id: Ief14f8914ef013bd6efd7be842f81fbf053f02e2
2018-07-30libmsc/gsm_09_11.c: forward SS/USSD messages to HLR over GSUPVadim Yanitskiy2-7/+22
In order to be able to support external SS/USSD gateway, we should not terminate the GSM 04.80 messages at OsmoMSC. Instead, we need to follow the GSM TS 09.11 specification, and forward all messages unhandled by OsmoMSC to OsmoHLR over GSUP protocol. This change implements forwarding of MO SS/USSD messages. The forwarding assumes transcoding between GSM 04.80 messages and GSUP messages. The payload of Facility IE is carried 'as is'. As a side-effect, this will disable the osmo-msc internal handler implementing the "*#100#" for obtaining the subscribers own phone number. In order to re-gain this functionality, you will need a modern osmo-hlr (Change-Id I1d09fab810a6bb9ab02904de72dbc9e8a414f9f9) and the following line in your osmo-hlr.cfg: hlr ussd route prefix *#100# internal own-msisdn TTCN-3 test case: I01de73aced6057328a121577a5a83bc2615fb2d4 Change-Id: Ide5f7e350b537db80cd8326fc59c8bf2e01cb68c
2018-07-29msc_vlr_tests: don't abuse USSD-request to conclude connectionsVadim Yanitskiy19-659/+488
Previously the '*#100#' USSD-request was abused in order to conclude the current subscriber connection. This makes the unit tests depend on each other, for example, if one break something in the GSM 09.11 implementation, a half of tests would fail. Moreover, the further changes in the GSM 09.11 implementation will make the results less predictable (i.e. session ID, etc.). So let's introduce a separate unit test with simple request- response logic, while more complex tests will be in TTCN. Change-Id: I40b4caac3113263f5a06c861dff5e10d43c319b5
2018-06-10libmsc/ussd.c: use connection ref-counting and transactionsVadim Yanitskiy6-23/+184
A subscriber may have a few active transactions at the same time. For example, one can receive SMS messages during a call, or during an active SS/USSD session. We already have connection ref-counting and transactions for CC and SMS, so let's also use both for SS/USSD. Change-Id: I21c6777cb88f1f4f80f75dcd39734e952bd4e8b0
2018-05-23implement periodic Location Update expiry in the VLRStefan Sperling4-0/+193
Remove subscribers which fail to send periodic Location Updates from the list of subscribers known to the VLR. This complements the IMSI detach procedure: periodic LU expiry triggers an implicit IMSI detach. Expired subscribers are purged from a periodic timer which iterates over all subscribers once per minute. Subscribers with an active connection do not expire. This is controlled by the subscriber conn FSM which sets a subscriber's the LU expiry timeout value to GSM_SUBSCRIBER_NO_EXPIRATION while a connection is active. Add support for fake time with osmo_clock_gettime() to msc_vlr tests. This functionality existed in OpenBSC but was lost during the nitb split. This code took some inspiration from the OpenBSC implementation. Related: OS#1976 Change-Id: Iebdee8b12d22acfcfb265ee41e71cfc8d9eb3ba9
2018-05-16vlr_access_req_fsm: use correct cause codesPhilipp Maier1-3/+3
The FSM that controls the VLR ACCESS uses cause code 9 (GSM48_REJECT_MS_IDENTITY_NOT_DERVIVABLE) to signal that the identity of the MS is currently not known in VLR (MSC-Reboot) However, this cause code is from the GMM domain and is interpreted as GSM48_REJECT_SRV_OPT_TMP_OUT_OF_ORDER by the MS, which cauese the MS not to make a new LOCATION UPDATE on CM SERVICE REQUEST - use GSM48_REJECT_IMSI_UNKNOWN_IN_VLR and GSM48_REJECT_IMSI_UNKNOWN_IN_VLR instead of GSM48_REJECT_IMSI_UNKNOWN_IN_VLR Change-Id: Ic058c93387f9be9af4940f8961839c02b93ee370 Closes: OS#3266
2018-04-17tests/msc_vlr: fix expected SS message namesVadim Yanitskiy6-92/+92
Since the I697639d8469e5dda617b27995c4a92e1f0c0bead, call independent SS messages are also supported by gsm48_pdisc_msgtype_name(). So, instead of 'NCSS:0x3b' it will return 'GSM0480_MTYPE_REGISTER'. Let's correct the expected message names. Change-Id: If9e854ee84882d104cf2ffaceb3862fda6862f19
2018-04-12msc conn ref counts: log human readable list of conn ownersNeels Hofmeyr11-1072/+1072
Change-Id: I2a09efafbdbdde0399238f7d79feea8612605201
2018-04-12refactor VLR FSM result handlingNeels Hofmeyr13-277/+270
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-04-11cosmetic: embed compl_l3_type in FSM idNeels Hofmeyr11-7130/+7130
In the subscr_conn_fsm instance's ID, include the Complete Layer 3 type, so that we can see on the first glance whether a state transition belongs to MO or MT. The huge patch is due to the cosmetic change affecting nearly every single log line in the msc_vlr_tests, by nature of changing the FSM's ID. Related: OS#3122 Change-Id: I2a7e27e0f16df1872dcda64cb928c3b8528ea3f7
2018-04-11properly receive BSSMAP Clear Complete and Iu Release CompleteNeels Hofmeyr24-556/+839
When sending a BSSMAP Clear or Iu Release, do not immediately discard the conn, but wait until a BSSMAP Clear Complete / Iu Release Complete has been received. Hence we will no longer show in the log that an incoming Release/Clear Complete belongs to an unknown subscriber, but will still be around to properly log the release. Related: OS#3122 Change-Id: Ie4c6aaba3866d6e5b98004e8870a215e8cf8ffc1
2018-04-11refactor subscr_conn and subscr_conn_fsm de-/allocNeels Hofmeyr13-2582/+3181
Refactor: 1. Glue the gsm_subscriber_connection alloc to the subscr_conn_fsm. 2. Add separate AUTH_CIPH state to the FSM. 3. Use conn->use_count to trigger conn release. 4. Add separate RELEASING state to the FSM. 5. Add rate counters for each of the three Complete Layer 3 types. Details: 1. Glue the gsm_subscriber_connection alloc to the subscr_conn_fsm. Historically, a gsm_subscriber_connection was allocated in libbsc land, and only upon Complete Layer 3 did libmsc add the fsm instance. After splitting openbsc.git into a separate osmo-msc, this is no longer necessary, hence: Closely tie gsm_subscriber_connection allocation to the subscr_conn_fsm instance: talloc the conn as a child of the FSM instance, and discard the conn as soon as the FSM terminates. 2. Add separate AUTH_CIPH state to the FSM. Decoding the Complete Layer 3 message is distinctly separate from waiting for the VLR FSMs to conclude. Use the NEW state as "we don't know if this is a valid message yet", and the AUTH_CIPH state as "evaluating, don't release". A profound effect of this: should we for any odd reason fail to leave the FSM's NEW state, the conn will be released right at the end of msc_compl_l3(), without needing to trigger release in each code path. 3. Use conn->use_count to trigger conn release. Before, the FSM itself would hold a use count on the conn, and hence we would need to ask it whether it is ready to release the conn yet by dispatching events, to achieve a use_count decrement. Instead, unite the FSM instance and conn, and do not hold a use count by the FSM. Hence, trigger an FSM "UNUSED" event only when the use_count reaches zero. As long as use counts are done correctly, the FSM will terminate correctly. These exceptions: - The new AUTH_CIPH state explicitly ignores UNUSED events, since we expect the use count to reach zero while evaluating Authentication and Ciphering. (I experimented with holding a use count by AUTH_CIPH onenter() and releasing by onleave(), but the use count and thus the conn are released before the next state can initiate transactions that would increment the use count again. Same thing for the VLR FSMs holding a use count, they should be done before we advance to the next state. The easiest is to simply expect zero use count during the AUTH_CIPH state.) - A CM Service Request means that even though the MSC would be through with all it wants to do, we shall still wait for a request to follow from the MS. Hence the FSM holds a use count on itself while a CM Service is pending. - While waiting for a Release/Clear Complete, the FSM holds a use count on itself. 4. Add separate RELEASING state to the FSM. If we decide to release for other reasons than a use count reaching zero, we still need to be able to wait for the msc_dtap() use count on the conn to release. (An upcoming patch will further use the RELEASING state to properly wait for Clear Complete / Release Complete messages.) 5. Add rate counters for each of the three Complete Layer 3 types. Besides LU, also count CM Service Request and Paging Response acceptance/rejections. Without these counters, only very few of the auth+ciph outcomes actually show in the counters. Related: OS#3122 Change-Id: I55feb379e176a96a831e105b86202b17a0ffe889
2018-04-11CC: intentionally release T308 on BSSMAP Clear Request from BSCNeels Hofmeyr1-1/+1
So far we hit a running T308 during CC release when caused by a BSSMAP Clear Request, and we loudly log that as error. However, now I understand that T308 is a direct cause of the dispatch of a REL IND towards MNCC, which is used to indicate teardown to MNCC. So during _gsm48_cc_trans_free(), we first clear all timers, then invoke mncc_release_ind() which starts another timer (useful for graceful CC Release, but in this code path the intention is immediate release). Simply immediately cancel the timer again and release the conn. A separate question is whether a BSSMAP Clear Request should be less aggressive in releasing the connections; i.e. instead of calling trans_free() all around, to rather ask each transaction to "please stop soon", somehow. Related: OS#3062 Change-Id: I231fdb574a086a206321148474cbdc7ca9cf39f0
2018-04-10msc_vlr_test_call: reproduce OS#3062Neels Hofmeyr4-0/+436
A related ttcn3 test is added in Ic80646e1fba37bb6163ca3a7eead7980b4ad7a51 Related: OS#3062 Change-Id: Ice7197b48d4e163a3c4d97b559fdcd7e88c4107e
2018-04-09Permit any Sender MSISDN when sending SMS from VTYHarald Welte1-1/+1
In the old days, OsmoNITB couldn't process any SMS that wasn't between two subscribers on the same NITB. We've long re-worked the internals in order to process SMS with arbitrary sender MSISDN (e.g. from SMPP). However, the VTY command "subscriber ... sms" was never updated, it seems. Change-Id: I62b17e0a67989484415f0df2c8cb4ff1f94dbf2b Closes: OS#3151
2018-04-05unify allocation of gsm_subscriber_connectionNeels Hofmeyr2-4/+2
The current msc_subscr_con_allocate() was in fact only used by msc_vlr_tests, while both a_iface_bssap.c and iucs.c did their own duplicate code of allocating the gsm_subscriber_connection struct. Unify. Drop the old msc_subscr_con_allocate(), instead add msc_subscr_conn_alloc(). The new function also takes via_ran and lac arguments directly. The conn allocation will soon be closely tied to the subscr_conn_fsm instance allocation, so place the new function definition alongside the other subscr_conn_fsm API, and match its naming ("conn"). Related: OS#3122 Change-Id: Ia57b42a149a43f9c370b1310e2e1f512183993ea
2018-04-03subscr_conn: store complete_layer3_type in conn, not FSM event argNeels Hofmeyr11-138/+120
Instead of jumping through hoops to pass the Complete Layer 3 operation that created this conn via FSM event dispatch parameters, put it right in the gsm_subscriber_connection struct, where it always belonged. Move definition of the enum complete_layer3_type to gsm_data.h, where gsm_subscriber_connection is defined. Introduce msc_subscr_conn_update_id() to set the complete_layer3_type of the conn as soon as a Complete Layer 3 message is received. In msc_subscr_conn_update_id(), already include an mi_string argument to prepare for an upcoming patch where the FSM will be allocated much earlier when the Mobile Identity is not known yet, and we'll also update the fi->id here. The odd logging change in the msc_vlr_tests output uncovers a wrong use of the osmo_fsm_inst_dispatch() data argument for SUBSCR_CONN_E_CN_CLOSE events: if a child FSM signals unsuccessful result, instead of the failure cause, it passed the complete_layer3_type, as requested upon FSM allocation, which was then misinterpreted as a failure cause. Now a child FSM failure will pass NULL instead, while other SUBSCR_CONN_E_CN_CLOSE events may still pass a valid cause value. Related: OS#3122 Change-Id: Iae30dd57a8861c4eaaf56999f872d4e635ba97fb
2018-04-03cosmetic: rename gsm_subscriber_connection->conn_fsm to ->fiNeels Hofmeyr9-20/+20
Match osmo-bsc's naming of the subscriber connection's FSM instance; 'conn->fi' makes more sense anyway than 'conn->conn_fsm'. BTW, an upcoming commit will do away with the legacy from libbsc/libmsc duality and firmly glue the conn allocation to the fi. Related: OS#3122 Change-Id: If442f2ba78d9722b1065ec30c9a13f372b6a8caa
2018-04-03test_reject_concurrency: missing assertNeels Hofmeyr2-0/+2
I broke this test during dev and saw the failure being noticed only in the next test when DTAP is expected again. Verify success right there, instead. Change-Id: Ifdde3a6fa5835203c34c40db77761f2e90c0d5ff
2018-03-30use osmo_init_logging2() with proper talloc ctxNeels Hofmeyr14-97/+143
Since the logging allocations now also show up in the root context report, some tests need adjusted talloc checks. In msc_vlr_tests, also output the number of talloc blocks before tests are started to show that the number didn't change after the tests. Change-Id: Iae07ae60230c7bab28e52b5df97fa3844778158e
2018-03-22remove empty libcommon-csNeels Hofmeyr3-3/+0
Change-Id: If6afda250986b12781ae579323985615621ed75c
2018-03-22rename libcommon to libgsupclientNeels Hofmeyr4-4/+2
All that is left in libcommon now are the GSUP and OAP client implementations. These are duplicated in osmo-sgsn.git and make sense to remain somewhat separate from libmsc. So now they get their own little lib. Change-Id: Ic71aa119c233b6a0ae169a5b2a53819903d2be82
2018-03-22dissolve libcommon: move talloc ctx into msc_main.c, drop talloc_ctx.cNeels Hofmeyr1-14/+14
Drop tall_bsc_ctx; in mncc_sock_init(), talloc the mncc_sock_state from gsm_network. In tests or utils, move from using an extern tall_bsc_ctx to a local root context pointer. Change-Id: I92c252be1d1e7634f1653de47d37c99d77d9501c
2018-03-22dissolve libcommon: drop debug.cNeels Hofmeyr1-0/+13
Apply more concise logging categories in each main scope. The bulk goes to msc_main.c, obviously, while tests and utils get a slimmed down bunch of logging categories. Change-Id: I969a0662ba273f3721b6820d02151b7a5b8014b8
2018-03-22trans_free: tear down conn when last transaction is doneNeels Hofmeyr3-17/+7
In trans_free(), call subscr_conn_release_when_unused(), so that we are sure to clean up after the last transaction is done. This fixes an error where a conn lingered after a CC failure, because that code path forgot to trigger cleanup. Rationale: so far we were triggering the release check after each DTAP dispatch (compl_l3 and "normal" DTAP), which is sufficient for properly closed transactions. We also need a check for when a timeout clears an erratic trans. Adjust test expectation of test_call_mo_to_unknown_timeout to show that the error is now fixed. msc_vlr_test_reject_concurrency now sees an additional release checking event when the SMS transaction is done, which is expected and does not affect the test otherwise. Related: OS#2779 Change-Id: I46ff2e9b09b67e4e0d79cccf8c04936f17281fcb
2018-03-15msc_vlr_tests: add CC Release test and test to catch OS#2779Neels Hofmeyr2-0/+842
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
2018-03-15cosmetic: rename conn_fsm "bump" event to "release_when_unused"Neels Hofmeyr11-526/+526
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
2018-03-15cosmetic: msc_vlr_tests: enable CC logging in debugNeels Hofmeyr7-1/+61
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
2018-03-15cosmetic: vlr_auth: log decision to send UMTS or GSM AKA challengeNeels Hofmeyr8-77/+89
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-10msc_vlr_tests: add test_a5_3_not_supportedNeels Hofmeyr2-0/+152
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
2018-03-10cosmetic: vlr_auth_fsm: log RAN and size along with SRES/RESNeels Hofmeyr7-66/+66
Change-Id: Ib0f9f573ffac2302fbd3ee28f48ccd8fce5fe286
2018-03-10cosmetic: vlr_auth_fsm: clarify decision on UMTS AKA or GSM AKANeels Hofmeyr2-6/+6
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-03-10msc_vlr_test_umts_authen: test response with only SRES half of RESNeels Hofmeyr2-0/+294
Change-Id: I0e9099625bd9d3de3db5ee29fbf81b2d8a30071d
2018-03-10msc_vlr_test_umts_authen: test response with too long RESNeels Hofmeyr2-0/+289
Change-Id: Ie5473f06fc2d04c6a9f343da5764ec95b292a5f9
2018-03-10msc_vlr_test_umts_authen: test response with too short RESNeels Hofmeyr2-0/+290
Change-Id: Ia1bc57b3dc1f3c3c654ba2d907b16ba925cd03e8
2018-03-10cosmetic: gsm48_rx_mm_auth_resp(): log 'UMTS AUTH', not 'R99 AUTH'Neels Hofmeyr3-30/+30
Change-Id: Iba43c685cbe238d96175267e9cc954b2f2f3e7fc
2018-03-10vlr auth: gracefully reject malformed auth responseNeels Hofmeyr2-0/+173
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
2018-03-10vlr: fix GSM AKA in a UMTS AKA capable environmentNeels Hofmeyr2-12/+3
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
2018-03-10msc_vlr_test_gsm_ciph: add test for GSM AKA in UMTS environmentNeels Hofmeyr2-0/+725
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
2018-03-10msc_vlr_tests: clearly separate Ciph Mode from Security Mode checkingNeels Hofmeyr9-48/+98
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