A new intermediate component DIAMETER_ConnHdlr_CT is added which extends
the required DIAMETER_ConnHdlr by the DIAMETER_Emulation, and forwards
it to the PGW_Session_CT. This way, the PGW_Session_CT, which usually
runs the test code, will have access to GTP2, Gx and Gy messages for the
session.
Initial Gy support for PGW_Tests is added in follow-up patch.
Change-Id: I28f1ac0a013e479058f28a6feff6901b33f6c247
When responding to a CBSP KILL with a CBSP KILL COMPLETE, make sure
we include the optional "Number of Broadcasts Completed List" IE
in order to inform the CBC about how many times the just-killed
message had been broadcast before it was killed.
It seems some CBCs expect this IE to be present, while 3GPP TS 48.049
lists it as optional. osmo-bsc is including this IE as of Change-Id
I47aebd613dfc6dd9261ea9019a51aff0cd6470d8
This change updates the test suite to expect this IE to be included.
Change-Id: I5b56676c93479ec7b32cff66c9738fff7d0228cf
Related: SYS#5906
The default AMR link adaptation parameters have been changed in
the recent osmo-bsc, so set the old expected default explicitly.
Change-Id: I320d91a35bc50bdfe87c0384035a10b8672ef23c
Related: osmo-bsc.git Ic5f8d55d250976d8d4c9cae2d89480fd52326717
Related: SYS#5917
I used the construct like f_rnd_octstring(f_rnd_int(100)) in a number
of places to generate random-length packets with randomized length.
The problem I didn't realize is that f_rnd_int() of course can also
return '0', which would generate zero-length packets. This may be
permitted in some protocols, but it leads to problems e.g. when trying
to send a UDP packet of zero length (which the kernel will not do).
So let's introduce
* f_rnd_int_nonzero() for returning non-zero randomized integers
* f_rnd_octstring_rnd_len() for returning a random-length random payload
octet string
* replace all f_rnd_octstring(f_rnd_int()) call sites with the new
function.
Change-Id: I818a113ff8d2a2f7cab2ec7d9c8661607c6331d6
Closes: OS#5528
Release of 256 tuns + threads takes quite a reasonable amount of time.
Let's increase the timeout since reset_all_state can take around 10
seconds sometimes.
Related: OS#5523
Change-Id: Ie01e07bd698cb5c386f757f4ec315f4892ad61cb
Deactivate as_Media() once the handover is completed, so that it does
not fail on the expected MGCP DLCX from release.
Fix fallout seen in these tests:
SCCPlite
BSC_Tests.TC_ho_into_this_bsc
BSC_Tests.TC_ho_into_this_bsc_a5_0
BSC_Tests.TC_ho_into_this_bsc_a5_1
BSC_Tests.TC_ho_into_this_bsc_a5_3
BSC_Tests.TC_ho_into_this_bsc_a5_4
BSC_Tests.TC_ho_into_this_bsc_a5_1_3_no_chosen_enc_alg
BSC_Tests.TC_ho_into_this_bsc_a5_1_3
BSC_Tests.TC_srvcc_eutran_to_geran
BSC_Tests.TC_srvcc_eutran_to_geran_a5_3
BSC_Tests.TC_srvcc_eutran_to_geran_src_sai
BSC_Tests.TC_srvcc_eutran_to_geran_forbid_fast_return
BSC_Tests.TC_ho_into_this_bsc_sccp_cr_without_bssap
All of these tests use f_ho_into_this_bsc().
(It is not clear to me why only the SCCPlite tests show the fallout, the
AoIP should be similarly affected, but isn't.)
The failures were introduced by recent merge of
I0633f60f09d58802f6be0238ef41a632d93a4327, which made as_Media()
stricter by failing on early DLCX.
Related: SYS#5916
Change-Id: Ic5650a48eb3d90f2b42f16685178c97b54473429
Since recenly, osmo-bts is using P_CON_INTERVAL=2 by default. This
means that the MS power loop gets triggered every 4th SACCH block
(1.92s), so we need more time to reach the maximim Tx power.
Change-Id: I9266f7284fcdb0afa3473f575640689e334e89a8
Related: osmo-bts.git I91c505447f68714239a4f033d4f06e91893df201
Related: OS#5517
An emergency call often comes with a Location Request. Make sure
osmo-bsc handles it well.
Related: SYS#5916
Change-Id: I95037374c45943cb14401bc48f16a39c2fcbe1f5
as_Media_mgw() is used to establish a voice stream. If a DLCX happens as
part of that, that should be flagged as a problem.
In fact the Mode Modify test with current osmo-bsc does exhibit a DLCX
right upon the Assignment Complete message, which is a bug fixed in
I5ab10ee7fd9c5d7608e8a06893881d990943feed.
This patch now correctly flags this as a failure.
In the two tests
TC_ho_in_fail_no_detect, TC_ho_in_fail_no_detect2
the expected failure causes expected DLCX, so exempt those.
Related: SYS#5916
Change-Id: I0633f60f09d58802f6be0238ef41a632d93a4327
We don't really act as rely agents in the emulation, so let's not
announce it.
Furthermore, this aids libfreediameter selecting proper routes, since it
seems to only underscore peers not matching the AppId if they are not
rely agents (see dont_send_if_no_common_app() in freeDiameter.git)
Change-Id: I0a9daf094f4c27c0b4de5581ddd56feced8e5732
ranops was not isvalue because bssap_reset_retries was not set and not
explicitly omitted either, so the ran adapter decided not to create a
ran emulation...
Change-Id: Ib2d3f1fbcfbd53af1e627bd2cf36c3153fa7d012
ranops was not isvalue because bssap_reset_retries was not set and not
explicitly omitted either, so the ran adapter decided not to create a ran
emulation...
Change-Id: Ibbef035929ec861fec1e8554460e22650b386f83
bsc-nat introduces a delay that will lead to failed tests, since the
reset attempt happens too early and times out, and the tests do not
retry.
Change-Id: I9f6db2a24e984eef31e76f9d42a80eb6a1bb6928
According to 3GPP TS 48.008, section 3.2.1.71, the LCS QoS IE shall
be present if location of the target MS is requested and is optional
otherwise. Since [1], osmo-bsc started to check presence of this IE,
so let's add it to ts_BSSMAP_Perform_Location_Request.
Taking a chance, let's also add LCS Priority IE.
Change-Id: If2bd6e636d3ee695abab9ed40417dc53ec68fd12
Related: [1] osmo-bsc.git Ifeb359b0468845da0b4fed9e2e4b79256067fa81
Related: SYS#5891
According to 3GPP TS 48.008, section 3.2.1.71, the LCS Client Type
IE shall be present if the location type indicates a request for a
location estimate and is optional otherwise. Since [1], osmo-bsc
started to check presence of this IE, so let's make sure that
it's present in ts_BSSMAP_Perform_Location_Request by default.
Change-Id: I5c8d6962e957d587dc4b65d08bf56bd4ef2f0d6e
Related: [1] osmo-bsc.git Id3262e67c3dc25cb93fbd52a40689c5529ca2d41
Related: SYS#5891
Using a guard statement makes no sense given that we match the
cellSelectionIndicatorValue conditionally within the alt branch
itself. Removing that guard statement eliminates the need to
have an additional alt branch with identical body.
Change-Id: I373376637a083637ce01f3ac59fe5fd2836ac6cd
RR Cause is a mandatory IE, so it cannot be omitted. Therefore it
makes no sense to check if istemplatekind(expect_rr_cause, "omit").
Change-Id: I564d00a4715b86d248bce449d2b9193ac5e99008
This was the case under ggsn_tests, which in turn prevents search text
tools like "ag" to find stuff in .ttcn files (because it skips code in
.gitignore).
Change-Id: Iaef3cfd5ae29db352046664ab4949b037ca80307
According to 3GPP TS 44.018, section 9.1.15, the RR Handover Command
message may optionally contain the Cipher Mode Setting IE (10.5.2.9).
Section 9.1.15.10 states that this IE may be omitted in case of the
intra-RAT GERAN-to-GERAN handover, however in case of the inter-RAT
handover (e.g. EUTRAN-to-GERAN), this IE *shall* always be included.
In f_ho_into_this_bsc(), check presence and correctness of the Cipher
Mode Setting IE. Add TC_srvcc_eutran_to_geran_a5_3, which is similar
to TC_srvcc_eutran_to_geran, but enables ciphering on the target channel.
This patch makes all SRVCC relates test cases fail, until [1] is merged.
Change-Id: Ic3dfc4e31a7ed078cdfdaced9986ee9551c5aa7c
Related: [1] osmo-bsc.git I1d270e82d0a9b12897fc94dae4e8999aa132a22f
Related: SYS#5838
The new message is to be used by Gy interface emulation, which according
to RFC4006 uses AppId 4 "Credit Control Application". The application
is apparently not 3GPP vendor specific.
Change-Id: I0e33673d65140aad34d2efcae3c7f49154ceb99f
The test case scenario can be summarized as follows:
1. Activate a logical channel for async handover.
1.a. Tune the MS side to that channel.
1.b. Make sure that no Downlink DCCH is received.
2. Send a handover Access Burst to the BTS.
2.a. Expect RR Physical Information to be received Ny1 times.
2.b. Expect no other data to be received on Downlink DCCH.
Currently the new test case fails for several reasons:
* osmo-bts-trx starts transmitting on DCCH before the handover
Access Burst is received, this is wong;
* trxcon immediately starts sending dummy frames on Uplink
DCCH, causing osmo-bts to stop sendig RR Physical Info.
Change-Id: I9469027ce88fb2750f1eceef2d8a56d4b8ee4d03
Related: SYS#5838
In TTCN-3 it's possible to call one altstep from another. This
allows us to build complex hierarchies of simple altsteps, where
one is built on top of the others. I call this altstep-oriented
programming. This change adds the following hierarchy:
* as_l1ctl_dl_msg() - triggers on receipt of a L1CTL DATA.ind
matching the given RSL chan_nr/link_id and data templates;
* as_dl_lapdm_dummy() - triggers on receipt of dummy LAPDm
func=UI frames with empty payload (repeats by default);
* as_dl_dcch_lapdm_ab() - triggers on receipt of a Downlink DCCH
containing a L2 payload that matches the given LAPDm frame;
* as_dl_dcch_pdu() - triggers on receipt of a LAPDm AB frame
with a L3 payload matching the given template.
All of these altsteps (except as_dl_lapdm_dummy()) expect an 'out'
parameter, which will hold the matched (and possibly decoded) data.
Example:
var PDU_ML3_NW_MS pdu;
alt {
[] as_dl_lapdm_dummy(); /* Ignore empty LAPDm func=UI frames */
[] as_dl_dcch_pdu(pdu, tr_CM_SERV_ACC) { setverdict(pass); }
[] as_dl_dcch_pdu(pdu, tr_CM_SERV_REJ) { setverdict(fail); }
[] as_dl_dcch_pdu(pdu, ?) { setverdict(inconc, "Unexpected PDU"); }
}
Change-Id: Ia4d502488cbb6bccc4d2656206ae6649bfa71007
Related: SYS#5838
Harald Welte
Pau Espin
Vadim Yanitskiy
Neels Hofmeyr
Eric Wild