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
osmo-upf has changed the naming of GTP action kinds, need to adjust the
test here to avoid failing tests.
Related: I49ac7b1f8b5b74f586edfed1dfb29f9af55a521b (osmo-upf)
Change-Id: I6fe4a4cf02ca05b772491d11a5edbdbd7b0b429a
Since osmo-ggsn.git Ia15c1cfd201d7c43e9a1d6ceb6725ddf392d2c65 osmo-ggsn
supports configuration of X3 timer, which should be set to (T3-RESPONSE
* N3-REQUESTS) configured at the peer.
The default values are 5 and 3 respectively, hence X3 is by default
5*3=15 seconds.
Let's use that default value for now.
Once new osmo-ggsn version is released, we can speed up test duration by
decreasing the values of the module parameters introduced in this commit
and configure VTY gtp timers at osmo-ggsn accordingly.
Related: OS#5485
Change-Id: I02c0982674b43317a5fc8f341c03eeeb1efee77f
Adjust the test to also check the special case ARFCN=0, which is at the
end of each sub list.
Related: OS#5717
Related: osmo-bsc Ic5e4f0531e08685460948b102367825588d839ba
Change-Id: Ia8f94d72651061427afc9e34f678544f89d0149b
Vadim Yanitskiy
Pau Espin
Alexander Couzens
Neels Hofmeyr
Oliver Smith