The TC_nacc_outbound_pkt_cell_chg_notif_dup is currently failing
because in [1] we changed the default hard-coded MCC/MNC values in
ts_BssgpCellIdDstAddr_default, however these it's still using
hardcoded MCC=023/MNC=43. I overlooked this in [2].
Let's split up the f_handle_nacc_rac_ci_query() into four functions:
* f_ctrl_rx_nacc_rac_ci_req() / f_ctrl_tx_nacc_rac_ci_rsp(),
* f_pcuif_rx_nacc_rac_ci_req() / f_pcuif_tx_nacc_rac_ci_rsp(),
and use them in TC_nacc_outbound_pkt_cell_chg_notif_dup. Also
employ them in TC_nacc_outbound_pkt_cell_chg_notif_twice.
Change-Id: I3e84f55eedd278fb239600d6a0465bd34fd8cd0b
Related: [1] 03f74d4132
Fixes: [2] 7295661af5
Related: OS#5901
This patch fixes TC_nacc_outbound_si_resolve_timeout, which is still
using old hard-coded MCC/MNC values. The altstep does the same, but
relies on the updated values from ts_BssgpCellIdDstAddr_default.
Change-Id: I9f6dbe97e9a494a4e8fdb441a70999d3040f6cfd
Related: OS#5901
When setting up an RTP flow the fmtp string is checked using isvalue(),
however this does not guard against empty fmtp strings. Rejecting empty
strings is especially useful in situations where the caller wants to
signal using "" that no fmtp string is present.
Change-Id: I2641a52a3b271681f4f2e424c34be12e125092d6
Related: OS#5688
There is no such country/operator with MCC=023/MNC=43. Wireshark
complains about that when looking at the BSSGP messahes:
Mobile Country Code (MCC): Unknown (23)
Mobile Network Code (MNC): Unknown (43)
This may look confusing, let's better use some real country/operator:
Mobile Country Code (MCC): Central African Rep. (623)
Mobile Network Code (MNC): Celca (Socatel) (03)
Change-Id: Idc22128657d10893aa5c6d8ec80538a764de5c42
Related: OS#5901
The enc_* functions usually return an octetstring. However, both
f_enc_BcdMccMnc[_int]() return a sub-type of hexstring (BcdMccMnc),
so let's rename them to avoid confusion.
A follow-up patch adds the actual encoding function for BcdMccMnc.
Change-Id: I0332fe7396310da49910e89571f7181fb1604182
This is a partial revert of e9858efb90.
I was confused by weird MCC/MNC values in the Destination RAI generated
by the NACC testcases from the PCU_Tests.ttcn. As I figured out, these
values are not from the INFO.ind, but some hard-coded literals:
* SRC RAI: MCC=262/MNC=42/LAC=13135/RAC=0 (from ts_PCUIF_INFO_default);
* DST RAI: MCC=023/MNC=43/LAC=00423/RAC=2 (resolved by test itself);
so actually they're not incorrect: they're sent by the testsuite itself
in response to the Neighbor Address Resolution Request, and then
expected to be received in the Destination RAI from the PCU.
Another important point is that TITAN produces different results when:
a) converting BcdMccMnc to bytes using the hex2oct() function,
b) converting BcdMccMnc to bytes using the RAW encoder.
The key difference is that TITAN does swap nibbles in each byte when
using the RAW encoder, but does not when using the hex2oct() function.
Use the proper hexorder (low-to-high) in f_enc_BcdMccMnc().
Add a selftest to make sure we're encoding the input properly.
This change makes the NACC testcases pass again.
Change-Id: I6f497b97c4f1e270803e01530be8355beea740bb
Related: SYS#5602
Fixes: OS#5901
This config is out of sync with the one in docker-playground.git.
The 'neighbor resolution' param makes osmo-pcu use the CTRL interface.
Change-Id: I8d59096644afd5a5278bc7bb1335670edad72576
Related: OS#5901
The current BSC_Tests are using osmo-bts-omldummy to keep OML out of the test context.
Add a new test file and component for OML tests.
Change-Id: I0934ea26db359b0a6649c613f01de134a3a372ee
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
Vadim Yanitskiy
Philipp Maier
Alexander Couzens
Pau Espin
Neels Hofmeyr
Harald Welte
Oliver Smith
Daniel Willmann