Add tests and enhance the upf test suite to be closer to real world
usage:
- properly verify the F-TEIDs chosen by osmo-upf.
- add tests with two-step session creation, i.e. with a Session
Establishment followed by Session Modification indicating the remote
F-TEID to use on the core side, as is the usual case.
- Add module parameters for network instances to use in the test;
dynamically configure osmo-upf's "netinst" config via VTY.
- pass Network Instance in Create PDR, verify that osmo-upf returns the
matching GTP IP addresses in Created PDR.
Related: SYS#6192 SYS#5599
Change-Id: I440466f1cc9689391869ac2579a4497ef6008adb
PFCP_Templates.ttcn is not the place to do the conversion between string
and OCT4.
When I wanted to use an OCT4 address in some ts_PFCP_* template, it
dawned on me that it is stupid to convert the OCT4 to a string, just so
that the ts_PFCP_* template converts it back to OCT4.
Related: SYS#6192 SYS#5599
Change-Id: Ib068831787f4256f70a2189a5f36ca1ea1f40c9e
The other use case, tunmap, needs some space next to tunend, too. tunmap
tests will be added soon.
Related: SYS#6192 SYS#5599
Change-Id: If4a4534aa237e6ff1acb6d50e3738dd4dd6e9dfa
A recent commit introduced a regression which made
TC_assignment_emerg_setup_deny_bts fail.
The problematic commit (see hash below) set "pars.ra :=
f_rnd_ra_emerg()" in the helper function, which made the BSC early
reject the CHAN RQD with ImmAssRej in the case the BTS policy forbids
emergency calls.
In that scenario, rejection can be done early because there's no need to
wait to find out which MSC it is aimed at.
This scenario, however, is already being validated by test TC_chan_rqd_emerg_deny.
The scenario TC_assignment_emerg_setup_deny_bts was testing is actually
one where CHAN RQD doesn't contain reason="emergency call", which means
BTS doesn't early reject it, but only knows about it being an emergency
call when a CC Emergency Setup is sent to it, time at which it releases
the call.
Hence, this commit sets back pars.ra = f_rnd_ra_emerg() only on the ..._deny_msc
testcase, since it's the only test really needing it.
Fixes: 14076d3b72
Related: OS#5849
Change-Id: I8d342e5938f6293ae45ee399796417651768af5d
Ramping down power if the oml link is lost was removed in osmo-bts.
Instead TC_tx_power_down_bcch checks that the rx power received is not
> 0 after dropping the oml link.
Change-Id: I463679d9678b95b7d3a5ace711c6ce17b3b24689
Depends: Ida1d7bbf094958b9142af306dbf84206729a609e (osmo-bts.git)
Related: SYS#6237
As stated in the comment near the t_def_TestHdlrPars definition,
valueof() shall not be used for getting a value of this template.
The f_gen_test_hdlr_pars() function should be used instead.
All LCLS testcases violated this, and started to fail since
recently after patch [1] has been merged:
"MSC_ConnectionHandler.ttcn:820 : Either imsi or imei must be set!"
BSC_Tests_LCLS.ttcn:743 BSC_Tests_LCLS control part
BSC_Tests_LCLS.ttcn:262 TC_lcls_gcr_only testcase
Use f_gen_test_hdlr_pars() as suggested.
Change-Id: I69ab8699b0be80b12e2df590d9170a743a00d035
Fixes: [1] b27653c6b6
OsmoBSC does some minimal parsing of l3 content to select MSC target,
match paging response to paging request, etc.
Since tests right now use potentially invalid data, osmo-bsc is not
rejecting conns providing invalid l3 content.
This commit makes sure TTCN3 tests pass valid l3 payloads to osmo-bsc,
so that they keep working once osmo-bsc starts rejecting invalid IEs it
parses.
Related: SYS#6280
Change-Id: I6e99ac39f32c9a981420b73f8d7d1568d2fa1c54
OsmoBSC does some minimal parsing of l3 content to select MSC target,
match paging response to paging request, etc.
Since tests right now use potentially invalid data, osmo-bsc is not
rejecting conns providing invalid l3 content.
This commit is another step towards passing proper l3 data to osmo-bsc
in TTCN3 tests.
Related: SYS#6280
Change-Id: I012dbdc673ff98a6647280ce3d0245abff86cfa4
Since [1] was merged, sending the L1CTL_DM_REL_REQ message alone
is not enough to be able to tune back to BCCH. We also need to
send L1CTL_RESET_REQ, so the trxcon's state is reset properly.
This patch fixes the following testcases:
* TC_sacch_chan_act_ho_async,
* TC_sacch_chan_act_ho_sync,
* TC_conn_fail_crit.
Change-Id: I07192e8a3127f8d9557a4b8aac3ca002f511a1d5
Related: [1] I5bbe6ca4cc6299f9faf343822c992a6872a45081 (osmocom-bb.git)
I am not using Debian, so I always have to edit this file in order
to be able to run the testsuites. Keep using default paths for
Debian, but allow redefining the TITAN_LIBRARY_PATH variable.
Change-Id: I3778a52697a182dbac39de6c18a053832ef78d93
Most BTS_Tests require to run fake_trx. Add a simple
run_fake_trx.sh script when running these test without
docker.
Change-Id: Ie3a68931bd52f55570409bb35962cebbfd58d168
We need to be able to send L1ctlDlMessage to the l1gprs_test [1],
a special program for testing the MS side GRR implementation.
Change-Id: I18e7585a8e93e3fafeda63b7325cfcc73e792abd
Related: [1] I36ceec4035b2ea593d47998f3f14f1415c606765
Related: OS#5500
We need to be able to send L1ctlDlMessage to the l1gprs_test [1],
a special program for testing the MS side GRR implementation.
Change-Id: Id163cb53afcbf803caf60a5b1a5768c67a9a2bf0
Related: [1] I36ceec4035b2ea593d47998f3f14f1415c606765
Related: OS#5500
On ArchLinux /bin/sh is actually a symlink to bash, so bash is running
in limited mode and emulating the Bourne Shell. The shell detection
logic added in [1] does not work correctly for me because the cmdline
would be 'sh' or '/bin/sh', not 'bash'. This is what I am getting:
\033[1;32m====== FooBar_Tests.TC_foo_bar pass ======\033[0m
Let's switch to printf, which does interpret the backslash escapes
as expected by default, regardless of the actual shell in use.
Also fix ttcn3-dumpcap-stop.sh, which was left untouched by [1].
Change-Id: Id28193a7ca00b5501a6852e5b4a5412fbaa5e063
Fixes: [1] bf45a5cff8
Revert submission 30430
Reason for revert: I did not consciously merge these, maybe some misunderstanding of Gerrit UI elements. Although it really surprises me that merging could have happened that easily without me noticing
Reverted Changes:
I85c2dc201:WIP: ns: Add test for SNS Size Num. of IP Endpoint...
I3584b7b04:WIP: ns: Add test for SNS Size NSEI IE
Ic69c461cd:WIP: ns: Add test for SNS Size Num. of NSVCs IE
Change-Id: Ifab74bd8ae568a3099637fb53f5fe407f85952b6
Revert submission 30430
Reason for revert: I did not consciously merge these, maybe some misunderstanding of Gerrit UI elements. Although it really surprises me that merging could have happened that easily without me noticing
Reverted Changes:
I85c2dc201:WIP: ns: Add test for SNS Size Num. of IP Endpoint...
I3584b7b04:WIP: ns: Add test for SNS Size NSEI IE
Ic69c461cd:WIP: ns: Add test for SNS Size Num. of NSVCs IE
Change-Id: I2b963d8d547b7c97ba8499921e42c57bab4ffaee
Revert submission 30430
Reason for revert: I did not consciously merge these, maybe some misunderstanding of Gerrit UI elements. Although it really surprises me that merging could have happened that easily without me noticing
Reverted Changes:
I85c2dc201:WIP: ns: Add test for SNS Size Num. of IP Endpoint...
I3584b7b04:WIP: ns: Add test for SNS Size NSEI IE
Ic69c461cd:WIP: ns: Add test for SNS Size Num. of NSVCs IE
Change-Id: I838b9b608a939ff909efe24ce3c1fdbfb539939d
It can happen that the RLCMAC req arrives at osmo-pcu before the
CS_PAGING we send to it over BSSGP, in which case osmo-pcu will schedule
an RLCMAC DL Dummy Block. Take into account this scenario to avoid
failing id it occurs.
Change-Id: I30da93835c7738aefcd84691d83f39759dd4b599
Since recently osmo-pcu arms the X2002 in a more fitting place (later,
when paging.cnf is received from osmo-bts over PCUIF).
Since we use same X2002 value in TTCN3 to wait for the timer to trigger,
in the past it was always fine (the X2002 at osmo-pcu always already had
triggered before the one in ttcn3 after receiving the ImmAss).
However, now the timer is roughly set at the same time in both places (ttcn3 and
osmo-pcu) and hence there may be race conditions where we request a
DL data block before the X2002 triggered at osmo-pcu, in which case we
receive a DL dummy block because the TBF is not yet in the FLOW state
Change-Id: Icc94eb0544226facddcd65be65a8a41bcfc662cc
Since recently osmo-pcu arms the X2002 in a more fitting place (later,
when paging.cnf is received from osmo-bts over PCUIF).
Since we use same X2002 value in TTCN3 to wait for the timer to trigger,
in the past it was always fine (the X2002 at osmo-pcu always already had
triggered before the one in ttcn3 after receiving the ImmAss).
However, now the timer is roughly set at the same time in both places (ttcn3 and
osmo-pcu) and hence there may be race conditions where we request a
DL data block before the X2002 triggered at osmo-pcu, in which case we
receive a DL dummy block because the TBF is not yet in the FLOW state
Change-Id: I67483bc423567d1fc98eb912ece1cf5cda746119
Since recently osmo-pcu arms the X2002 in a more fitting place (later,
when paging.cnf is received from osmo-bts over PCUIF).
Since we use same X2002 value in TTCN3 to wait for the timer to trigger,
in the past it was always fine (the X2002 at osmo-pcu always already had
triggered before the one in ttcn3 after receiving the ImmAss).
However, now the timer is roughly set at the same time in both places (ttcn3 and
osmo-pcu) and hence there may be race conditions where we request a
DL data block before the X2002 triggered at osmo-pcu, in which case we
receive a DL dummy block because the TBF is not yet in the FLOW state.
Change-Id: If7121473a3580b40d3a658dc38b9bb1421196127
So far the test asked osmo-upf to use an actual IP address and TEID, but
normally it is sent with CHOOSE = 1 so that osmo-upf picks a new local
TEID and returns it with the proper local IP address in the response.
This is making the test more realistic, and also prepares for testing
Network Instance handling, where osmo-upf will need to return the proper
IP addresses for specific Network Instance names.
Change-Id: Iaba372cbb2e0cf0c5bee80b09d346f9bcb78bfbe
The proper name is mp_verify_gtp_actions.
jenkins is not affected because it uses another .cfg from
docker-playground.git.
Change-Id: Ia13407db795021a2c3e2923c08b63ad6cdd6b0f9
`lsof` isn't available in the docker image, use /proc fs instead to get
the shell type
Related: OS#5736
Change-Id: I38e132f49b0711d611d08b61c28b3092c991a191
The old output is preserved, too, in order to ensure
compatibility with expectations regarding legacy behavior.
Related: OS#5736
Change-Id: Ia92ff32c8ce09ab7805c5509837ec88fa4b864c5
Neels Hofmeyr
Pau Espin
Daniel Willmann
Vadim Yanitskiy
Alexander Couzens