Database preparations used to be done in PyHSS by all services if they noticed that this was needed. The time between checking and creating the tables caused a race condition where two services attempting to create tables at the same time will result at one of them failing, we have seen this in our ttcn3-hlr-test-pyhss jobs sometimes:
I have fixed this upstream by letting only the main service (pyhss_hss) prepare the database: https://github.com/nickvsnetworking/pyhss/commit/8b8a2202c345fbb7262c9d07d03003cd2fdb819f
This means that we now need to run the pyhss_hss service in the HLR tests, so pyhss_gsup doesn't fail with:
[Database] [INFO] Waiting for the main service to prepare the database ERROR: 127.0.0.1:4222 did not become available within 5s! [testenv][pyhss] pyhss_gsup: setup script failed
ggsn: TC_pdp(4)6_clients_interact: Expect UEs can interact using global IPv6 address
The link-local IPv6 address is only meant to be used privately between the UE and the GGSN, but the UEs should be in general able to reach each other using their global IPv6 address (unless some operator policy explicitly forbids it).
Since open5gs.git 6cc627c4855703a17c92352660078325c6ce63cc, open5gs-upfd supports proper routing of IPv6 packets between UEs.
osmo-ggsn apparently doesn't implement that internal routing logic yet, so these tests will start failing now, but it's actually legit to have it not passing the test anymore.
Fix unintended if condition removal in recent commit when in the -latest case. That commit expected to leave the -latest path untouched but ended up removing the line. Re-add it.
Since we recently increased a bit the timeout to assume the BSSAP_LE peer (SMLC) is implicitly up, the function f_bssap_le_wait_sccp_peer_available() may still be onging when we drop the sctp connection at the STP in the test, which will generate an explicit DUNA towards BSSAP_LE and hence fail the test because it never comes back available before it times out.
Since we don't need nor test SMLC in this test, simply disable starting the SMLC here to avoid this race condition and simplify the test.
hnbgw: Fix race conditions during PFCP Association
Since osmo-hnbgw now sends Heartbeat Requests, we need to take that into account. Furthermore, since it also now supports retriggering association when detecting peer restarted upon rx of Heartbeat Req, use that to trigger an association to clean up state and have a deterministic way to synchronize at that point regarding state.
BSSAP_LE_Emulation: Increase timeout in f_bssap_le_wait_sccp_peer_available()
It was spotted in SMLC_Tests.ttcn that the current timeout may be too short, and the test fails because ttcn3 connects to STP and receives a DUNA, and then the IUT (osmo-smlc) connects to STP around 4 seconds later, which is too late with existing timeout.
bts: as_rsl_meas_res(): tolerate low RxLev in early reports
The MS is not guaranteed to begin transmitting immediately after activation of the respective logical channel. There is typically a short interval during which the BTS receives no bursts. Consequently, the initial RSL measurement reports are expected to indicate poor RxLev/RxQual values.
We already tolerate bad RxQual values; however, sporadic failures still occur due to low RxLev in the very first report. Extend the logic in f_build_meas_res_tmpl() to tolerate low RxLev as well.
Change-Id: Ic632917d429ec597dba524bf79749944cf1fc628 Related: 8ce558dd ("bts: as_rsl_meas_res(): tolerate bad RxQual in early reports") Related: OS#6933
hnbgw: TC_rab_assign_mgcp_to: Allow hnbgw to tear down CN conn at SCCP level
Newer versions of osmo-hnbgw will be tearing down the CN conn at SCCP level by transmitting an RLSD in this scenario, instead of sending a Iu RANAP Release Request crafted by the osmo-hnbgw itself. The HNBGW is expected to forward RANAP messages between UE/HNB and CN, not to generate them.
It may happen that the target BSC is not yet connected to the MSC. In this case the MSC rejects handover with HandoverRequiredReject. Let's catch this PDU to make the verdict cleaner in such case.
msc: TC_ho_inter_bsc: wait for the target BSC to become ready
A race condition may occur between the two testcase components emulating BSCs: the source BSC initiates handover to the terget BSC before the later completes connection establishment with the MSC. In this case, the MSC fails to find the target peer and rejects our HandoverRequired with HandoverRequiredReject.
Target RAN peer from neighbor config is not connected: Cell ID CGI:023-42-5-6 resolves to target address 0.24.2 Cannot find target peer for cell ID CGI:023-42-5-6 Attempted Handover to 1 cells without success
Let's avoid this by waiting for the target BSC to become available before initiating the handover procedure. Use the COORD port ("intercom") to signal readiness of the target BSC.
