Skip to content
Unstable

#2977 (Dec 20, 2025, 10:32:00 AM)

Started 1 mo 29 days ago
Took 37 min on build5-deb12build-ansible
Build Artifacts

Started by timer

This run spent:

  • 1 ms waiting;
  • 37 min build duration;
  • 37 min total from scheduled to completion.
Revision: fc22df8f4e54ed26a7b9878f032eb47830e2e3d4
Repository: https://gerrit.osmocom.org/osmo-ttcn3-hacks
  • origin/master
Tests (7 failures / +2)Show all failed tests >>>
RAN_Emulation: Support Tx RESET retries in RANAP

As already done in BSSAP in the same module.

Change-Id: I84553ae7aee19efa007bae060d7f7ca218a5f306
Pau Espin Pedrol at
BSSAP_LE_Emulation: Support Tx RESET retries

Have same code as we use in RAN_Emulation.ttcnpp.

Change-Id: I475f93ff0b8cbfa5aa4900d02ddcb2e97fa5ca6a
Pau Espin Pedrol at
BSSAP(_LE)/RANAP: Proper counting of RESET retries

N retries means N+1 attempts.

Since M3UA_Emulation (in deps/, not in library) doesn't support pushing
DUNA/DAVA as primitive up the stack, we cannot implement the related
SCCP primitives which should end up sending in turn other primitives to
our BSSAP(_LE)/RANAP emulations.
This means we currently have no way  to figure out the status of the
underlying SCCP/MTP link, and our only way is implement a poor man's
solution: retransmit RESET until we get an answer.

Since before bssap_reset_retries was set to 1 everywhere and we were
only attempting once, it could happen that the other end (the IUT) was
not yet connected to the STP when we send the RESET, and hence it is
discarded the STP. In that scenario, we'd time out and fail the test.
Instead, now that we do N+1 attempts, we retry after 5 seconds, which
should be enough time for the peer to reconnect to the STP.

Change-Id: If02e424672ff6270aed323c3bb236e822d8a39a4
Pau Espin Pedrol at
bts: properly set BTS_Tests.mp_trx_pars for hopping cfg

The pchan assignment is *different* for the hopping and non-hopping
configurations, so let's override it in the BTS_Tests_FH.cfg.

Change-Id: Ib8861c3eee5157436fb213da212f22477639883f
Vadim Yanitskiy at