These tests are expected to fail since open5gs has no specific logic for emergency services in open5gs-amfd, and announces no Emergency Support in Registration Accept.
TC_uemux_e_rab_release_ind never actually tests the release indication because release_ind is false instead of true. The test body becomes identical to TC_uemux_e_rab_setup - no release indication is ever sent.
Change-Id: Ieed5d8a2bf4f696efc1071569090facc7b731f96 Fixes: cdc149a6 ("s1gw: add UEMux TCs for E-RAB SETUP and RELEASE")
s1gw: fix TC_e_rab_setup_failure: expect a specific S1AP PDU
setup_rsp is carefully constructed, but is not actually used. The f_ConnHdlr_rx_s1ap_from_enb() call falls through to the ? default, so the test accepts any S1AP PDU and never validates that the S1GW actually populated the failed-items list correctly.
s1gw: f_ConnHdlr_conn_track_disable(): set conn_track := null
After deactivate, conn_track still holds the now-dead reference. A second call (which can happen if any test explicitly calls this before f_ConnHdlr_s1ap_disconnect()) will attempt to deactivate an already-inactive default, which is a TTCN-3 runtime error.
On timeout pdu was never assigned (it's an out parameter), so TITAN logs <unbound>. The useful diagnostic is the expected template, not the received value.
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.
