open5gs got the Gy Thresholds fixed recently
(e078b33f0c4d6f34d8991f8ad211dd2d9ea977a0).
AS shown in 3GPP TS 29.244 C.2.1.1 diagram, in Diameter Gy the value
sets the trigger for the "remaining credit", not the "used credit".
"ThresholdPFCP = Quota - ThresholdGy"
The test needs to be adapted since it was wrong too.
Change-Id: Ia283ad4919813241e3c33465ba4be2d2e33f5e54
The StatsD init() function parameter names were misleading
(prefixed "dst_" while they are actualy "local_" ones).
As a result, the hnbgw test was passing the wrong values to it.
Change-Id: I213173c99ec314c2eebfb8836c4d3467b3a7f818
From running this test repeatedly, I noticed that osmo-msc's new patch
to avoid storing a TMSI may also trigger more evil twin situations in
the VLR as described in OS#4721.
Always run this test twice, to probe for the evil twin problem.
This test will pass from osmo-msc patch
Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd on.
Depends: osmo-msc Ifdabe0b65bffafbf7b8e5cc10e2d225d1ed1cecd
Related: SYS#6860 OS#4721
Change-Id: I5e596597add7d585efd27c850067b8d7ba34ecc0
Add test case for handling a LU by TMSI MI when 'no assign-tmsi' is
configured.
This test will pass from osmo-msc patch
I583682d1a35a70b008d7bb2d89ba7c3109a60b21 on
Depends: osmo-msc I583682d1a35a70b008d7bb2d89ba7c3109a60b21
Related: SYS#6860 OS#4721
Change-Id: If10b9987395670b084ff8ad6d1f033ff46896d75
Allow testing Location Updating by TMSI MI.
Prepares for TC_lu_tmsi_noauth_notmsi in
If10b9987395670b084ff8ad6d1f033ff46896d75
Change-Id: I31aad8eb751528f7237a892702e87ee5855cabbb
Obviously, when only a TMSI has been used, searching for an IMSI will
return no subscriber. Don't fail in that case when testing for
verify_vlr := false.
Prepares TC_lu_tmsi_noauth_notmsi in
If10b9987395670b084ff8ad6d1f033ff46896d75
Related: SYS#6860 OS#4721
Change-Id: I4d719928f04e5a47d415c38f835451b1f10c713d
When a received Paging mismatches, instead of waiting for Tguard
timeout, fail immediately. Add a local timer and wait 4.0 seconds
by default.
Change-Id: I30273e3882e348a2ded88b7b96a5ec1473a56913
Tweaked-By: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
The by_tmsi argument so far had no effect. But I actually need exactly
this in upcoming MSC_Tests.TC_lu_tmsi_noauth_notmsi(): expect a Paging
with explicitly no TMSI included.
Related: SYS#6860 OS#4721
Change-Id: I9434745b7faeb738caafed8080b9f7b1a6a8079a
The component architecture in PCU_Tests is quite complex to follow.
Update the diagram in order to make it easier for people to gasp the big
picture.
Change-Id: Ie592a9301b7a900334650741ed633cd70535a2b1
Fix access of non-present tMSI.* if tMSI == omit, allowing to match
incoming Paging with a UnitData receiver that has no TMSI.
Change-Id: I1bdf3488be0f8d4f0905665c4ba642f9468b9777
We shouldn't run all of our tests with a rather exotic release
cause value (O&M intervention) but assume a normal/orderly NAS
triggered release, unless a specific test case explicitly tests
an abnormal release cause.
Change-Id: I8ddd1dccc5637431e3a8c6e607e0e45faa82b5b5
Lots of infrastructure added to allow call establishment and hang up
between 2 users connected to Asterisk.
SIP_Tests is updated to accomodate for necessary changes in
SIP_Templates used by Asterisk_Templates.
Change-Id: Ic5827a3e94b06fbc57f6405bf0f0aa6598c5d1fe
Related: SYS#6782
open5gs-smfd is since recently acting properly and setting the proper
TEIC when sending GTPv2C messages for cases where session is not found.
Related: https://github.com/open5gs/open5gs/issues/3043
Change-Id: I2086b4576a10c7b4ba8217be6e49c8f5f389bc4b
"Dynamic test case error: Port CLIENT_PROC has more than one active
connections. Message can be sent on it only with explicit addressing.".
Change-Id: Ibf868394ce2c495a78ab943ddec278a45bf71088
This testcase is failing sporadically ever since it was introduced
back in 2019, during 36C3. The problem is that osmo-msc does not
react to the malformed MM IDENTITY RESPONSE immediately, but only
after timeout of timer X1 (5 seconds, by default); while the
testsuite expects the LU REJECT to be received within 5 seconds.
We should ideally fix osmo-msc to react immediately, but for now
let's enlarge the LU REJECT waiting timeout in the testcase.
Change-Id: I5d2b5d49df8f7ae1eb12fc137f4256fe6fab9117
Related: OS#6426, OS#4340
We didn't have any test coverage for HNBAP UE registration so far.
Let's start with two basic tests:
* normal / successful case
* abnormal case: UE Register without prior HNB Register
Change-Id: Ice2743d376ab8041646259fa25117d6fd0e8c2fd
Add initial infrastructure to run tests against an Asterisk process.
An not-yet-finished draft test doing registration is submitted to
validate communication towards Asterisk works.
The testsuite will be improved in follow-up commits, but this way other
people can already start using it and we can set up the dockerized setup
+ jenkins jobs to run it nightly.
Related: SYS#6782
Change-Id: I66f776d5df6fb5dc488d9e589b84a6b2385406e8
The existing template system in SIP_Templates made it difficult to craft
specific templates, since it was usually skipping several layers of
fields when passing parameters.
This commit reworks some of those templates, adds news templates, and
cleans formatting for others, as a preparation for further work which
will be done when adding Asterisk_Tests testsuite.
Change-Id: Ifd14213e9c2b8f5061f828a63ef47844828d94ea
osmo-mgw should not respond to unknown peers. The test expected the
wrong thing, because of an old hack for 3G voice. Fix that.
Related: OS#6424
Change-Id: Ibe2ee59d1ed2c25ffef7e8534c172ac190b4983d
This testcase is not Iu-compatible yet, but let's make life a bit
easier for those trying to make it such in the future.
Change-Id: I8185153502d31163fcb4c718690ee0f1cc912f5b
Previous commit [1] uncovers a problem in f_tc_mt_crcx_ran_reject():
this function uses as_clear_cmd_compl_disc(), which is expecting
A-interface (GERAN) specific BSSMAP Clear Command. The Iu-interface
(UTRAN) specific RANAP Iu-ReleaseCommand is not handled at all.
The testcase was passing so far due to a bug in as_optional_cc_rel(),
which would unblock the alt-statemtnt on receipt of CC RELEASE, so
that we would never respond to RANAP Iu-ReleaseCommand.
Let's derive a new altstep from f_expect_clear() and use it.
Change-Id: Idd679bbf720a56a76cf37ab414b1e6d90e53278b
Related: [1] I0143b4d33b1ebe4cce99c09018540524c4626eec
We do activate() this altstep in several testcases, so that it's
kinda "running in background". In reality, the defaults in TTCN-3
are just a syntax suggar, and the following code:
```
var default foo := activate(as_foo_bar());
alt {
[] PORT1.receive(tr_Msg1) { repeat; }
[] PORT1.receive(tr_Msg2) { setverdict(pass); }
}
PORT2.receive(tr_Msg3);
```
actually evaluates to:
```
alt {
[] PORT1.receive(tr_Msg1) { repeat; }
[] PORT1.receive(tr_Msg2) { setverdict(pass); }
[] as_foo_bar();
}
alt {
[] PORT2.receive(tr_Msg3);
[] as_foo_bar();
}
```
If as_foo_bar() contains no 'repeat' statement, then whenever it
triggers it would efficiently cancel (unblock) the current alt
statement, resulting in weird behavior due to messages not being
dequeued from ports as expected. And this is exactly what we
saw happening in OS#6414.
Change-Id: I0143b4d33b1ebe4cce99c09018540524c4626eec
Related: OS#6414
Assuming n_sd should be 3 is only valid for non-A5 testcases, in which
we are *not* doing ciphering and authentication. For the A5 testcases
(TC_ho_inter_bsc_a5_*), this assumption is incorrect and osmo-msc is
definitely not happy about that:
Duplicate DTAP: bin=0, expected n_sd == 0, got 3 (ran_msg.c:159)
Dropping duplicate message ... (msc_a.c:1363)
Why and how the A5 testcases passed so far? It was a pure luck, which
sailed away when we started executing ttcn3-msc-test with io_uring.
The A5 testcases were passing thanks to the as_optional_cc_rel() that
gets activate()d in background before calling f_call_hangup(). This
altstep does not have the 'repeat' statement, and as a side effect it
may cancel any normal alt-statements and even standalone receive()
statements.
In the successful scenario, it would cancel (unblock) the following
receive operation in f_call_hangup():
MNCC.receive(tr_MNCC_REL_ind(cpars.mncc_callref));
log("f_call_hangup 2: rx MNCC REL ind");
BSSAP.receive(tr_PDU_DTAP_MT(tr_ML3_MT_CC_REL_COMPL(cpars.transaction_id)));
// ^^^^^^^^^^ as_optional_cc_rel() triggers here and cancels this one
which is a pure luck because our CC RELEASE was sent with incorrect
sequence number and got dropped, so osmo-msc would never send us
CC RELEASE COMPLETE. It would instead send us CC RELEASE due to
expire of T306, and the as_optional_cc_rel() would kick in handling
this message and responding with CC RELEASE COMPLETE.
In the failing scenario though (when running with io_uring), that
same altstep running in backround may trigger *earlier* and unblock
another standalone receive() statement:
MNCC.receive(tr_MNCC_REL_ind(cpars.mncc_callref));
// ^^^^^^^^^ as_optional_cc_rel() triggers here and cancels this one
log("f_call_hangup 2: rx MNCC REL ind");
BSSAP.receive(tr_PDU_DTAP_MT(tr_ML3_MT_CC_REL_COMPL(cpars.transaction_id)));
so that we will be stuck waiting for CC RELEASE COMPLETE until the
Tguard expires.
This patch fixes n_sd patching, so that our CC RELEASE message is
handled properly and the call gets released as expected, without
requiring as_optional_cc_rel() to kick in. The missing 'repeat'
is to be added to as_optional_cc_rel() in a follow-up patch.
Change-Id: Iddde391eade716ca5c6c48cb631450ddb543e0d4
Related: OS#6414
During TC_addr_pool_exhaustion, if all of the pdp context activations
were unsuccessful, teic_list is an empty list. We therefore cannot
unconditionally obtain its first element.
This patch avoids the related "Index overflow in a value of type
@PreGenRecordOf.PREGEN_RECORD_OF_OCTETSTRING: The index is 0, but the
value has only 0 elements."
Related: OS#6423
Change-Id: I7c7a84ed8343fb48e841248f86d37972f4674ed0
open5gs-smfd was recently modified to send RAT-Type inside
PS-Information instead of MSCC, since having it in the former is
supported since older spec releases and having it in the later creates
problems in some real world OCS implementation like PortaOne OCS.
Related: SYS#6837
Related: open5gs.git d0b31177cca360865ebc6ab0b89eee7ee4fc8d1a,
Related: open5gs.git 3b5e851f5d1328536052031e66a7b9b03c3057f6
Change-Id: I7ce77d08847a0876291f76e901e5c89c339db27d
Prepare to run the GGSN tests in different configurations:
* v4_only: one APN with v4
* v6_only: one APN with v6
* v4v6_only: one APN with v4v6
* all: multiple APNs with all of the above
Related: OS#6096
Related: docker-playground Ia2fe0c3ed4ccf06e72fd258d085e4a79cecd5f26
Change-Id: I6d94a8b18200fbb2119406827b74b83e912e3ecc
The function was copied from MGCP_Templates.ttcn since the logic is the
same for SDP, but copied in order to avoid depending on whole MGCP file.
Since now SDP logic has been moved to its own SDP_Templates and a new
f_sdp_addr2addrtype() was added, use that one.
Change-Id: I27ce46b6d23ba0f2704dd0cee290ed519dec278e
Pau Espin
Vadim Yanitskiy
Neels Hofmeyr
Harald Welte
Oliver Smith