Keep the default of using a random payload length, but also allow picking one
specifically. TC_cbsp_write_bss() will use this in a subsequent patch.
Change-Id: I259da42cbcbfdfe930aabb45c9de8a2b67c69629
Fix the length calculation to provide a range of [1..82].
f_rnd_int() generates [0..max[ (i.e., < max), so f_gen_page() so far has a
payload len range of [0..81]. We want no zero payload, and we want a maximum of
82 bytes (page max of 88 minus 6 header bytes).
Change-Id: Id521b6038a23dc8e71ea25475bcdef7bc8917531
When dividing the payload by 22, the initial 6 header octets must also be taken
into account.
And, the last_block value indicates 4 as 0, which is not encoded correctly
before this patch. Add a separate f_cbsp_block_count_enc() to fix the
calculation.
Change-Id: I06cc144bd92e94d461dac3f56a738da8e055b73a
Expecting a CBSP RESTART when connecting as CBSP client does not work, osmo-bsc
doesn't send any. Let's ignore this to get the CBSP tests running at all first.
We should clarify expected behavior and apply that, later (OS#4702).
Related: OS#4702
Change-Id: Ib93530691344c6dc4c0a8318bee2edf87e309a42
The bsc/BSC_Tests_CBSP.ttcn rely on a configuration where the first three BTS
carry out SMSCB messaging, and the fourth BTS does not. That requires a CBCH
channel config on bts 0, 1, 2.
Side effects:
- adjust the number of available SDCCH (for TC_chan_exhaustion).
- there now is a CBCH channel description in SI4, add this to
SystemInformationConfig_default.
Related: Idbcc703ace7012fb395f0eef3e445df28b368d74 (docker-playground)
Change-Id: Iac46ee2cc5bc0978d5f5baa550baf493a7c56b1b
In the ttcn3-bsc-latest tests, there are no 'msc 1' and 'msc 2' configured, so
stepping into 'msc 1' and '2' creates two new, empty MSC configurations.
osmo-bsc latest actually still tries to use them and fails 2/3 Compl L3.
So do not step into 'msc' config scopes if no such MSC is mentioned in the
running config yet.
This should finally fix the bsc latest tests after I broke them in
I02ad58ed7d0d0aac61e393b415e09c6c5c8a70ca and
Ibd5adb359b3fb302e2c70700d911878aef605ff3 and
I75295d638072df9f5213a7e74e4a960c009c2865.
Yes, I know :/
Change-Id: Ibfeeea98c2a962dec58ad03beb35bb7f83cad228
osmo-mgw recently added support for E1 trunks via libosmoabis. While the
actual E1 plane may be difficult to test, there is some functionality
that can already be tested without having E1 support in TTCN3.
Lets add three testcases:
- TC_e1_crcx_and_dlcx_ep:
Does a CRCX to an E1 endpoint followed by a DLCX
- TC_e1_crcx_with_overlap:
Not all E1 endpoint combinations are possible at the same time. This
test verifies that invalid endpoint combinations are prevented.
- TC_e1_crcx_loopback:
Opes an E1 endpoint and tests if RTP loopback works (NO E1 traffic
involved)
Change-Id: I673eeffcb3012b42f039789960c54d99282e1aad
Related: OS#2659
Invoke Clear Command with various Cause codes and verify that the RR Channel
Release reflects them.
Depends: I734cc55c501d61bbdadee81a223b26f9df57f959 (osmo-bsc)
Change-Id: Ie6c99f28b610a67f2d59ec00b3541940e882251b
Add a DCHAN and release to recently added SI2quater tests (because these tests
already configure various amounts of EARFCNs in osmo-bsc).
Verify that the RR Channel Release for CSFB contains all configured EARFCNs.
In GSM_RR_Types.ttcn, add coding for "Cell selection indicator after release of
all TCH and SDCCH IE".
In f_expect_chan_rel(), add optional arg csfb_expect_cells, and, if present,
decode the RR Channel Release message's L3 part, and in turn the Cell Selection
Indicator Value contained. Match against csfb_expect_cells.
In f_tc_si2quater_n_earfcns(), also compose a list of EARFCNs as found in the
RR Channel Release, and pass to f_expect_chan_rel().
Depends: I59e427e4ebb1c6af99b27a15c40fed82457ac8ab (osmo-bsc)
Change-Id: I882c5e1f70bcc4833fc837a95c900ce291919cc5
Test that a CHAN RQD that indicates an emergency call is rejected if
emergency calls are disabled.
Change-Id: I9084df86e8f808e3c1d948ab88e07e7458761a71
Related: OS#4548
The testcase TC_chan_act_ack_noest_emerg tests if an emergency causes a
channel assignment. This can only work if emergency calls are allowed,
but the testcase does not make sure that this actually is the case.
Related: OS#4548
Change-Id: I0ddac0ba8ed4afe993d566dcbea87cdc62ed9fe4
During patch grooming of the previous fixup, one patch line went missing, which
breaks the ttcn3-bsc-test-latest completely. Add that change now.
Change-Id: I75295d638072df9f5213a7e74e4a960c009c2865
The EMERGENCY SETUP is an L3 message that normally gets passed through
transparently to the A interface. Nomrally the BSC will not look into L3
messages. However if EMERGENCY CALLS are allowed on a BTS or not is set
in the system information. Also osmo-bsc has the option to deny
EMERGENCY CALLS globally for all BTSs.
Since EMERGENCY CALLS are a crucial application, the BSC should not only
send the appropiate sysinfo messages that forbid emergency calling. It
should also make sure that any attempt to make an emergency call is
rejected early if emergency calls are denied.
Lets add some checks to verify that the allow/deny mechanisms for
EMERGENCY CALLS are working as expected.
Depends: osmo-bsc Ia6eb38370ce4165d221d2ffbe1cd105c0628313c
Change-Id: I486d99953529a1ce9f0a3950c9a97900922eee92
Related: OS#4548
The function f_establish_fully may be called with template ass_tpl set
to "omit". In this case we must make sure that we do not pass ass_tpl on
to isvalue().
Change-Id: Ie094e5b56a851351671327b475d5e597a5a94bf6
In f_vty_wait_for_prompt(), this:
testcase.stop(fail, "VTY: Unknown Command")
outputs:
failVTY: Unknown Command
The first stop() argument 'fail' is not actually a test verdict, but gets
rolled into a log output string, becoming "failVTY".
Fix that by simply using the normal pattern of setverdict() followed by
mtc.stop().
Change-Id: Id09986444de02c10b4fba582d454d54568b6e8a2
For the VTY "Unknown Command" code path, we must actually call 'repeat', to
avoid racey VTY behavior from cruft stuck in the VTY pipe.
The missing 'repeat' caused massive random fallout in the 'latest' builds,
which often hits the 'Unknown Command' code path; fixed by this patch.
Change-Id: Ibd5adb359b3fb302e2c70700d911878aef605ff3
TC_chan_act_ack_noest requests a channel and then releases it again.
However, this does not test yet what happens if the requestor (BTS) uses
a request reference that indicates an emergancy call. Depending on the
configuration the BSC should reject or allow the channel to be
established.
Change-Id: If828c0f5786d89efa7608f38d648e2a2b8f6f675
Related: OS#4549
osmo-bsc takes a while to notice that a connected MSC is no longer connected.
Once the mscpool tests have run, the additional msc 1 and msc 2 still linger
around even though the BSSMAP link is no longer served by the bsc-tester.
The easiest way to ensure that only expected MSCs are contacted is to set
'no allow-attach' for each MSC that should not be in use.
So, the default setup is 'allow-attach' on msc 0, and 'no allow-attach' on mscs
1 and 2. In f_init(), allow attach on those MSCs indicated by the nr_msc
amount. The entire vty transaction to configure attach/no attach for all three
MSCs takes about 4 micro seconds in my test setup, so it is fine to do this
during f_init() for each BSC test.
After this, tests running after the MSC pooling tests (the LCLS tests) no
longer round-robin their subscribers across disconnected MSCs.
NOTE: it would be good to somehow detect more reliably in osmo-bsc that an MSC
is gone and not use it anymore. That is however not so trivial. To get the LCLS
tests back online, this is a workaround to avoid that complexity for now.
Change-Id: I02ad58ed7d0d0aac61e393b415e09c6c5c8a70ca
When a new test uses a VTY configuration that may not yet be available in the
'latest' build, it can be useful to ignore the "Unknown VTY Command" error.
To be used by f_init() for multiple MSCs, setting a default 'allow-attach' flag
per MSC implicitly -- such vty config is not yet supported in the latest build.
Change-Id: I284c42e10c0cb282c8410db87959b471867edef6
This change introduces new version 10 specific extensions, in
particular: the frequency hopping parameters of each timeslot.
These parameters are used to compose Channel Description IE
in the packet resource assignment messages.
In order to maintain backwards compatibility with version 9 of
the PCUIF, and thus to still be able to run test cases against
the latest release of osmo-pcu, I kept the old parts of the
INFO.ind and gruoped them together with the new records
into union 'PCUIF_InfoTrxs'.
During decoding, the content of this union is resolved by the
TITAN's RAW codec itself, depending on value of the 'version'
field. During the encoding, it's the responsibility of the
API user to set a proper field of the union. I implemented
both f_PCUIF_ver_INFO_{Trxs,PDCHMask} helpers for that.
Version 9 is kept as default, so this change can be merged
independently of the actual implementation. We can bump
it and remove the compatibility glue once the new versions
of both osmo-bts and osmo-pcu are released.
Change-Id: Idf11bc4ba3ff0b00b32f2beab8fd020c67119d05
Related: SYS#4868, OS#4547
An upcoming patch adds a test series (of various payload lengths) to
TC_cbsp_write_bss(), which then needs a bit longer than 30 seconds to run
through those. That test will pass a longer guard_timeout.
Change-Id: I54e1b3994074f4d0caf5b201588fce0ec41dda89
we used to accept arbitrary length responses, which made us fail to
catch the bug described in OS#4684
Change-Id: I35721ce55b58a2f70ea30a0d1bd16d2ac58dfcab
Related: OS#4684
Immediate Assignment is sent on AGCH/PCH, while on PACCH we have
Packet Uplink/Downlink Assignment instead (see 11.2.29, 11.2.7).
Change-Id: I56473ae5dfa565d2c9d26984b14685a4163bf69a
The following bitstring in TITAN:
0 N // N = NF - 1
-------------------->
0001 1011 1110 0100 // '0001101111100100'B
needs to be be encoded as follows 'on the wire':
N 0 // N = NF - 1
<--------------------
0010 0111 1101 1000 // '0010011111011000'B
so it basically gets inversed => we need to use BYTEORDER(first).
Change-Id: Iea2e3a9a7a0557d1ab5d935877d2161ee0988077
Fixes: I70b1baf01859d0cf3b8cec1aed04d73fc097a9b1
Related: SYS#4868, OS#4547
- Length of field 'MA_BITMAP' is specified in bits, not bytes;
- The value range of field MA_LENGTH is 0..63, therefore:
- value 0 means that field 'MA_BITMAP' is 1 bit long,
- value 1 means that field 'MA_BITMAP' is 2 bits long,
- value 63 means that field 'MA_BITMAP' is 64 bits long.
Change-Id: Iec19da18637febfa15bc09175bc51504c721c42f
Related: SYS#4868, OS#4547
According to 3GPP TS 44.060, table 12.10a.2, given that the number
of bit positions in MA_BITMAP equals NF, the first bit position
in MA_BITMAP corresponds to ARFCN_INDEX = NF-1, the last position
corresponds to ARFCN_INDEX = 0.
To put differently, the following bitstring in TITAN:
0 N // N = NF - 1
-------------------->
0001 1011 1110 0100 // '0001101111100100'B
needs to be be encoded as follows 'on the wire':
N 0 // N = NF - 1
<--------------------
0010 0111 1101 1000 // '0010011111011000'B
so it basically gets inversed. Let's add both BYTEORDER and
BITORDER attributes to achieve that.
Change-Id: I8f2c8c7b234605523a4fd518210b45ea3c088ff6
Related: SYS#4868, OS#4547
The testcase TC_crcx_wildcarded_exhaust assumes a wrong number of
endpoints. Since osmo-mgw has a wrongly solved off-by-one in its
endpoint allocation it allocates the wrong number of endpoints. This
is now fixed, lets now also fix the test expection.
(The failure of TC_crcx_wildcarded_exhaust also causes
TC_crcx_dlcx_30ep to fail.)
Depends: Change id I73b31e3c236a61ea0a6f76ef5ff98ce589f52c77
Change-Id: I73344ef8793cc81df0a1815bb8d890e7849cdd20
Related: OS#2659
Neels Hofmeyr
Philipp Maier
Vadim Yanitskiy
Harald Welte
Pau Espin