aboutsummaryrefslogtreecommitdiffstats
path: root/tests/msc_vlr/msc_vlr_test_ms_timeout.err
AgeCommit message (Collapse)AuthorFilesLines
2018-09-30GSUP client: send CN domain IE on LU requestNeels Hofmeyr1-4/+4
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 Hofmeyr1-0/+130
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-04-12msc conn ref counts: log human readable list of conn ownersNeels Hofmeyr1-22/+22
Change-Id: I2a09efafbdbdde0399238f7d79feea8612605201
2018-04-12refactor VLR FSM result handlingNeels Hofmeyr1-9/+9
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 Hofmeyr1-219/+219
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 Hofmeyr1-20/+25
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 Hofmeyr1-65/+92
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-03subscr_conn: store complete_layer3_type in conn, not FSM event argNeels Hofmeyr1-6/+4
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-03-30use osmo_init_logging2() with proper talloc ctxNeels Hofmeyr1-4/+7
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-15cosmetic: rename conn_fsm "bump" event to "release_when_unused"Neels Hofmeyr1-9/+9
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: vlr_auth: log decision to send UMTS or GSM AKA challengeNeels Hofmeyr1-3/+3
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-1/+1
Change-Id: Ib0f9f573ffac2302fbd3ee28f48ccd8fce5fe286
2018-03-02msc_vlr_tests: revert IMSI parameter and test nr outputNeels Hofmeyr1-6/+6
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
2018-02-14remove unused "authorized-regexp" VTY commandHarald Welte1-4/+4
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
2018-02-07VLR tests: always print test parametersMax1-6/+6
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
2018-01-24remove traces of bsc_subscriberHarald Welte1-4/+4
Change-Id: I8672f0a76cb47595444a7ddbc4f34fc4ddaeb375
2017-12-31VLR: log subscriber updateMax1-0/+2
* 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
2017-12-20fix: properly cancel all Paging on IMSI DetachNeels Hofmeyr1-3/+18
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
2017-12-20fix paging: add timeout to discard unsuccessful pagingNeels Hofmeyr1-0/+167
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
2017-11-27subscr_conn: introduce usage tokens for ref error trackingNeels Hofmeyr1-14/+14
When hunting a conn use count bug, it was very hard to figure out who's (not) using the conn. To ease tracking down this bug and future bugs, explicitly name what a conn is being reserved for, and track in a bit mask. Show in the DREF logs what uses and un-uses a conn. See the test expectation updates, which nicely show how that clarifies the state of the conn in the logs. On errors, log them, but don't fail hard: if one conn use/un-use fails, we don't want to crash the entire MSC before we have to. Change-Id: I259aa0eec41efebb4c8221275219433eafaa549b
2017-11-22msc_vlr_tests: set a valid lac for fake connsNeels Hofmeyr1-2/+2
Change-Id: Ie647d93a54aefad5bde8a9411d983cd60714b83d
2017-11-20vlr_subscr_conn_timeout(): don't fire events to discarded fiNeels Hofmeyr1-3/+7
Terminating one of the FSM instances may effect termination and deallocation of the others, as well as the vlr_subscr itself. So, reserve the vlr_subscr locally, and then dispatch events to exactly those FSM instances that exist. The changes in expected output in the msc_vlr_tests shows that the subscriber was deallocated from the first FSM termination, and now sticks around until we've checked both FSMs are gone. Change-Id: I56551ecc10f5295fe75944bdde4b583b1b621811
2017-11-20subscr_conn: don't close after conn timeoutNeels Hofmeyr1-4/+0
If dispatching a conn timeout, the conn fsm will already have been discarded, and we cannot fire any more events to it. The expected test output changes illustrate that we are now omitting event dispatches that happen *after* the same FSM was already deallocated. Change-Id: I25af3e5a1b04e3a5c9f41956cbcbbdd8439c6457
2017-08-29Implement AoIP, port to M3UA SIGTRAN (large addition and refactoring)Philipp Maier1-0/+6
This was originally a long series of commits converging to the final result seen in this patch. It does not make much sense to review the smaller steps' trial and error, we need to review this entire change as a whole. Implement AoIP in osmo-msc and osmo-bsc. Change over to the new libosmo-sigtran API with support for proper SCCP/M3UA/SCTP stacking, as mandated by 3GPP specifications for the IuCS and IuPS interfaces. From here on, a separate osmo-stp process is required for SCCP routing between OsmoBSC / OsmoHNBGW <-> OsmoMSC / OsmoSGSN jenkins.sh: build from libosmo-sccp and osmo-iuh master branches now for new M3UA SIGTRAN. Patch-by: pmaier, nhofmeyr, laforge Change-Id: I5ae4e05ee7c57cad341ea5e86af37c1f6b0ffa77
2017-08-2304.08: log protocol discriminators and message types by nameNeels Hofmeyr1-8/+8
On incoming 04.08 messages, we log only the protocol discriminator in decimal. Enhance: log pdisc and message type in hex, and also log the protocol and message type as human readable string. Also adjust the msc_vlr tests' log statements for wrapped rx/tx functions of dtap from/to the MS. Adjust the expected output of msc_vlr_tests. Change-Id: Ida205d217e304337d816b14fd15e2ee435e7397d Depends: libosmocore change-id I0fca8e95ed5c2148b1a7440eff3fc9c7583898df
2017-08-08Implement IuCS (large refactoring and addition)Neels Hofmeyr1-40/+44
osmo-nitb becomes osmo-msc add DIUCS debug log constant add iucs.[hc] add msc vty, remove nitb vty add libiudummy, to avoid linking Iu deps in tests Use new msc_tx_dtap() instead of gsm0808_submit_dtap() libmgcp: add mgcpgw client API bridge calls via mgcpgw Enable MSC specific CTRL commands, bsc_base_ctrl_cmds_install() still needs to be split up. Change-Id: I5b5b6a9678b458affa86800afb1ec726e66eed88
2017-08-07vlr: LU FSM: enable Retrieve_IMEISV_If_RequiredNeels Hofmeyr1-2/+2
Change-Id: I121b95ad6d5ecb7603815eece2b43008de487a8a
2017-07-23Add msc_vlr test suite for MSC+VLR end-to-end testsNeels Hofmeyr1-0/+332
Change-Id: If0e7cf20b9d1eac12126955b2f5f02bd8f1192cd