Fix that the test was torn down too early, before DLCX messages were
received from OsmoBSC. This caused a race condition that sometimes
failed the test with:
VirtMGW-MGCP-0(1996)@e5a096d6b4ff: Dynamic test case error: Sending data on the connection of port MGCP_CLIENT to 1999:MGCP failed. (Broken pipe)
Related: OS#5787
Fixes: 7a8594a8 ("bsc: TC_ho_in_fail_mgw_mdcx_timeout: new test")
Change-Id: If47fa3e0204ce841c79a67dd78a1c53d04e4a586
Prepare to use fail_on_dlcx in a new test case. Instead of dragging the
parameter through lots of function calls, just add it to pars.
Related: OS#5787
Change-Id: I6f0c4ce543724cc6f18bae9fc2b480f5818db8b7
osmo-hnbgw will deprecate the 'sccp cr max-payload-len' config option.
To still trigger the 130 byte limit that is now enforced in
libosmo-sigtran, enlarge the NAS PDU.
So far the limit set via VTY was 0 bytes, which will no longer happen in
osmo-hnbgw after I18dece84b33bbefce8617fbb0b2d79a7e5adb263.
Related: OS#5906 SYS#5968
Change-Id: I174b2ce06a31daa5a129c8a39099fe8962092df8
Currently an unexpected PDU will trigger a DTE (no matching alt).
Let's add an additional wildcard alt and terminate grecefully.
Change-Id: I6dbc646d5f036f454f197137373796f40c4c9e74
Related: SYS#5602, SYS#6333
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