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.
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.
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.
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.
