Remove the paragraph about writing to the Free Software Foundation's
mailing address. The FSF has changed addresses in the past, and may do
so again. In 2021 this is not useful, let's rather have a bit less
boilerplate at the start of source files.
Change-Id: I8ab8f1e79fcc38d889cce4eac2e90cd4e5582b1b
It's better if we run ttcn3-bts-test with the default values, given
that they were significantly reduced some time ago.
Change-Id: Id97e848e5dfd0b6c504d06f62642511cfd5a0f66
Related: I7da3d0948f38e12342fb714b29f8edc5e9d0933d (osmo-bts)
Related: OS#4487
Otherwise it's impossible to run the CBSP test cases locally, because
the remote peer address in osmo-bsc gets set to '0.0.0.0', so indeed
it cannot establish connection to the server.
Change-Id: I5b1d215818255717ed955c9f1a9c45505ab11a65
Fixes: OS#5351
It's clearly stated in a comment to this function that the returned
value is 0 <= x < max, so it's always less than the maximum.
Change-Id: If127fc6a2feeddbdd3ea636b56dadf8957941758
Using the same IMSI in each test case makes it harder to correlate
subscriber connections in the SUT with particular test cases. A
good example is a problem described in OS#5337: some test cases
create dangling subscriber entries that never got released:
OsmoBSC# show subscriber all
IMSI TMSI Use
001019876543210 ffffffff 3 (3*paging-start)
001010000100001 ffffffff 1 (conn)
With this patch I am getting the following output:
OsmoBSC# show subscriber all
IMSI TMSI Use
001016017428234 ffffffff 1 (paging-start)
001014631230680 ffffffff 1 (paging-start)
001011161500382 ffffffff 1 (paging-start)
001010000100001 ffffffff 1 (conn)
so I was able to correlate the following test cases:
* (001016017428234) TC_lcs_loc_req_for_active_ms_ta_req,
* (001014631230680) TC_lcs_loc_req_for_active_ms_le_timeout2,
* (001011161500382) TC_cm_service_during_lcs_loc_req,
* (001010000100001) TC_no_msc.
Change-Id: Ie008b5566b207b13cd562c55625bad38c09b3927
Related: OS#5337
The resulting set of dependencies needed just to have one simple CellId
struct is huge. That was fine for sgsn testsuite since anyway those were
being used, but it's not acceptable for other testsuites (hnodeb) which
only really require the GTP side.
After this change, GTP_Templates only requires GSM_Types, which ends up
in a much smaller subset of dependencies being pulled in.
Change-Id: Icd8234908af445b798517fe110cd0648969179a4
Different pcus try to establish the same BVC. Ensure that all the other
BVCs still remain functional.
Change-Id: I46eb0205b4c86b5f1bdc241ef0b2e12135c028e4
This change fixes sporadic failures of TC_cm_serv_rej:
RAN Connection table not found by component TC_cm_serv_rej(2648)
BSC_Tests.ttcn:11106 BSC_Tests control part
BSC_Tests.ttcn:10550 TC_cm_serv_rej testcase
The reason is that sometimes a BSSAP/DTAP PDU (with CM Service Reject)
gets enqueued before the SUT has established an SCCP connection to the
virtual MSC. This causes a lookup error in the RAN connection table.
A simple solution would be to add a receive statement after calling
f_create_chan_and_exp(), like it's done everywhere else:
f_create_chan_and_exp();
BSSAP.receive(tr_BSSMAP_ComplL3); // <---
But a more general solution is to expect and receive this message in
f_create_chan_and_exp(), so we can reduce code duplication and make
the API more convinient. This is exactly what this change does.
Change-Id: Ic675168e29919e1234cb49440c4a630238ff5d70
Related: SYS#4878
In [1] I forgot to invert an if statement. This regression caused
most of GERAN specific test cases to fail due to "Tguard timeout".
Change-Id: I8cbaff00abfd9eb252dc3011df848e2e24fe5a1e
Fixes: [1] Ib7ebe8fd675295beb02cadebb19d8465dffeb732
Related: OS#5333
Reduce nesting and improve readability by splitting GERAN/UTRAN
specific CMC/SMC message handling into separate functions.
Change-Id: Ib7ebe8fd675295beb02cadebb19d8465dffeb732
Related: OS#5333
The idea is to generate a talloc report after execution of a test
case and store it together with PCAP files. This might be useful
for detecting memory leaks and finding the relevant test cases.
To enable this feature, make sure that osmo_interact_vty.py from
osmo-python-tests is installed (see [1]), and the following
variables are set (see [2]):
* OSMO_SUT_HOST (e.g. "127.0.0.1"), and
* OSMO_SUT_PORT (e.g. 4242).
Change-Id: I1b03b17426d8760c55976e3b78ca2f3af248c055
Depends: [1] Ida8e08e7fe4f171f934a2d4eef4568da7c398f5c
Related: [2] Icd4c2d80db934535d499598282ed9416d8088163
Related: OS#5328
Verify the BTS level assignment:attempted_speech / _sign as well as
assignment:completed_speech / _sign counters, in four selected
assignment tests (fr, hr, amr_f, amr_h).
Shows a bug where we counted a speech assignment as
assignment:completed_sign.
Related: SYS#4878
Depends: Ie9fcd1e86f27ecb2f11e2e8813faac365cb470b8 (osmo-bsc)
Change-Id: Icb1386ec2ccd70eb3c026301b9b08ad7177278f7
Test the new bsc.N.paging:expired stat in TC_paging_counter too.
Depends: osmo-bsc I9c118e7e3d61ed8c9f1951111255b196905eba4d
Related: SYS#4878
Change-Id: I8931bf1bc2f4e0d4b168168cdb83683bb350d961
Create functions to check which from Osmocom repository the SUT is
running. Put it in Misc_Helpers instead of a new library file since
Misc_Helpers is already available in many/all? tests and it fits there
too.
Depends: docker-playground Ic06532f7a67e59458652c5cf4c8f6fee8113e703
Related: OS#5327
Change-Id: Ic33d08992ea84af006d133db6aec508a7b7c7f28
T3212 is set to 60 min. by default in osmo-msc. There is no need
to set the value explicitly, so let's use the default.
Change-Id: I4a053af23ae9371c945c7634053827bb3813a67a
The BVCI that this message might contain should not be used to route it.
It referes to the BVCI that the PDUs were transferred to (BVCI (new)).
Instead broadcast to all components.
Change-Id: Ia1df35da44ef28d91501bb898e1059bf1390129b
A new Iuh CodecPort + Emulation is introduced to (de)mux RANAP and RUA
in the same SCTP socket.
The Iuh_CodecPort.ttcn file has currently a hack to be able to test
HNBAP, since titan seem to be reporting sinfo_ppid=0 when in fact it
received sinfo_ppid=20 (HNBAP).
A couple tests are added to validate HNBAP HNBRegister Request + Accept
or Reject. In current osmo-hnodeb state, both tests pass if run
separately, but fail if run sequentially since osmo-hnodeb still doesn't
re-connect properly after first test finishes and connection is dropped.
Related: SYS#5516
Change-Id: I7227917148e98a2c777f4b05d8d2eca6e9c121b7
So far all handover tests trigger handover via VTY command. This means
that any bugs introduced in measurement report handling and handover
target selection are by definition not caught.
Almost a year ago, fixing a handover oscillation bug for intra-BSC
handover introduced a segfault for inter-BSC handover targets, because
for those the target.bts is NULL. Show this bug.
Related: OS#5324 SYS#5259
Related: I5a3345ab0005a73597f5c27207480912a2f5aae6 (osmo-bsc)
Change-Id: Iba033c32015173f57dbb1c211aefab1a9094e29d
Due to the migration to a multithreading scheme the timing behavior of
the stats items has slightly changed. There is now a 1 sec update cycle
in which the stats items are regenerated. This means we have to wait 1
sec. before we can query the endpoints.used stats item.
Change-Id: I90613616f9ff85ca59464dfd45d331ed1a54d9c5
Related: OS#5316
As can be seen from ttcn3-bsc-test run #1565 on Jenkins [1], it may
happen that the VTY command requesting handover reaches the IUT earlier
than the SCCP 'SACK CC' message. In this case, the 'SUBSCR_CONN' FSM
remains in state 'WAIT_CC', so we get an error:
(bts=0,trx=0,ts=0,ss=0) (ARFCN 871) --> BTS 1 Manually triggering Handover from VTY
SUBSCR_CONN(msc0-conn204)[0x5633b2877af0]{WAIT_CC}: Received Event HANDOVER_START
SUBSCR_CONN(msc0-conn204)[0x5633b2877af0]{WAIT_CC}: Event HANDOVER_START not permitted
The easiest way to avoid this is to introduce and artificial delay
after the connection establishment and before triggering the handover.
[1] https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-bsc-test/1565/
Change-Id: I19f7ca942e22d7930a56d1a525414f137a9ef831
Make the test more stable by sleeping a bit before stopping all
components. Also reduce the f_sleep(3.0), an accidental leftover from
initial debugging.
Related: SYS#4878
Change-Id: I005af13baac4bca2a431b09b2a6bbfe7077342e0
I cannot reproduce the issue in my local system with docker, probabluy
due to different performance from jenkins builder. It triggers almost
every time in jenkins nightly TTCN3 PCU_tests though.
A similar fix was already introduced recently for TC_n3105_max_t3195
since PCU started submitting empty (idle) blocks when there's no TBF
listening on that PDCH. We need to update the test to account for that,
since our TTCN3 timers are not necessarily exactly matching the one at
the PCU side.
Change-Id: Ia5344df15c612c70a6cdd7bb6f12dc7524a23bf4
Oliver Smith
Vadim Yanitskiy
Pau Espin
Daniel Willmann
Neels Hofmeyr
Alexander Couzens
Philipp Maier