In [1] I copied the hexstring concatenation statement for the 3-digit
MNC from the original function f_enc_BcdMccMnc(), which was renamed
to f_enc_BcdMccMnc_int(). Unfortunately, this statement (originally
introduced in commit [2]) is incorrect.
In our implementation a pair of MCC and MNC is encoded as follows:
| MCC digit 1 | MCC digit 2 | octet 1
| MNC digit 3 | MCC digit 3 | octet 2
| MNC digit 1 | MNC digit 2 | octet 3
Additionally, in the case of a 2-digit MNC, the original variant
of f_enc_BcdMccMnc() (before [1]) would swap MCC and MCC in the
2nd octet, generating even more unpredictable results.
According to 3GPP TS 24.008, Figure 10.5.13, the correct coding is:
| MCC digit 2 | MCC digit 1 | octet 1
| MNC digit 3 | MCC digit 3 | octet 2
| MNC digit 2 | MNC digit 1 | octet 3
So far the only user of this API is the PCU_Tests module. Looking
at the PCAPs of testcases invoking this function, Wireshark indeed
shows weird MCC/MNC values (expected 262/42):
Routing area identification: 23-43-423-2
Mobile Country Code (MCC): Unknown (23)
Mobile Network Code (MNC): Unknown (43)
Location Area Code (LAC): 0x01a7 (423)
Routing Area Code (RAC): 0x02 (2)
Change-Id: Ifa3083fdd6307b56baa1ef3ac85a3e7a2efab728
Related: [1] 7a92d5fbc0
Fixes: [2] 0637ba0728
Add a test that uses SDP CLEARMODE towards the MGW. The SDP parameters
generated by the test look as expected when compared to RFC 4040
section 5.
Related: OS#4395
Related: https://www.rfc-editor.org/rfc/rfc4040#section-5
Change-Id: I89c5dfdcd728ab3b50e77c5062f07e1b802b1f01
The tests that test the conversion from AMR octet-aligned to AMR
bandwith-efficient use the same payload type number on both ends. This
does match the reality. Typically the BSS uses 96 as payload type
internally, while 3gpp specifies a payload type of 112 on the link
between BSS and CN. To reflect those conditions in the test as well,
lets use 96 on one RTP end and 112 on the other.
This also increses the test coverage as we now test if PT translation
and bwe/oa conversion work together.
Change-Id: Id734b6954098130bba02f8cdf1b06e0080c3e915
Related: OS#5461
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
Pau Espin
Vadim Yanitskiy
Neels Hofmeyr
Harald Welte
Oliver Smith
Philipp Maier
Daniel Willmann
Alexander Couzens