Fix that 6 tests started failing on ttcn3-hnbgw-test-latest with e.g.:
Timeout waiting for metrics
HNBGW_Tests.ttcn:2885 HNBGW_Tests control part
HNBGW_Tests.ttcn:1536 TC_rab_assign_fail testcase
Fixes: 904b5f1a ("hnbgw: Implement validation of [some] counters")
Change-Id: I0cd47728308757fe6eaaaed1581fbbec03a09cf7
The StatsD init() function parameter names were misleading
(prefixed "dst_" while they are actualy "local_" ones).
As a result, the hnbgw test was passing the wrong values to it.
Change-Id: I213173c99ec314c2eebfb8836c4d3467b3a7f818
We shouldn't run all of our tests with a rather exotic release
cause value (O&M intervention) but assume a normal/orderly NAS
triggered release, unless a specific test case explicitly tests
an abnormal release cause.
Change-Id: I8ddd1dccc5637431e3a8c6e607e0e45faa82b5b5
We didn't have any test coverage for HNBAP UE registration so far.
Let's start with two basic tests:
* normal / successful case
* abnormal case: UE Register without prior HNB Register
Change-Id: Ice2743d376ab8041646259fa25117d6fd0e8c2fd
This will allow emulating an MGW deciding to change its local IuUP IP
address due to received remote address in MGCP MDCX, and announce the
changed address back in MGCP MDCX. A test validating this scenario
against osmo-hnbgw will be added in a follow-up patch.
Related: SYS#6657
Change-Id: Ia724e0363a8bab56f5d31e7f7f7a127af584f935
The default value of the timer changed recently, and made some tests
which were using some timer hardcoded values fail.
Add this configurable option to adapt the test behavior to the
osmo-hnbgw configuration. This way we can also set it to lower values in
order to avoid waiting too much time.
Change-Id: I176ef96e193f2ca39077bcee3a2187768ddb45ce
Give some more wait time for RANAP RESET after f_cn_nr_init().
Intended to fix sporadic failures of HNBGW_Tests...
- TC_rab_assign_mgcp_to
- TC_ranap_cs_mo_disconnect
Change-Id: Ia5144dbbc5168b3707e714e12b805f5d640fa774
docker-playground.git needs a config file change to be committed at the
same time as this patch, see 'Related'.
Depends: osmo-ttcn3-hacks I94aa0b2adfc48b98cb4b1efe595c2432fc603d6c
Change-Id: I027a059faed3f140f8801f84338956cd004043b5
Most tests need to run f_start_hnbs() directly after f_init(), so make
that the default behavior.
The three tests that don't want f_start_hnbs() to run now pass a new
arg, f_init(start_hnb := false).
Change-Id: I2b29ce66aee0b2d57fa26e6110f06292c481ab6b
This allows selectively disabling ASN.1 memory checks, which still fail
in current osmo-hnbgw-latest.
Change-Id: I5c18cf2d6797bcf0bef13d71ab0b69f1403b474f
This allowed me to find massive memory leaks in osmo-hnbgw: at the end
of each test, run f_shutdown_helper(), and in it query 'show talloc' for
an empty asn1_context.
Hence verify that all the scenarios run in these ttcn3 tests have no
asn1 de/encoding memory leaks.
Change-Id: I2948ee6f167369a2252f85b493e9653b93c7e4e9
To get 001-01, we need to encode the placeholder 0xf nibble.
Since recently, osmo-hnbgw cares about the PLMN in messages, in specific
cases: in upcoming CN pool tests, the PLMN is part of the algorithm that
picks the CN link. So let's encode 001-01 correctly.
Change-Id: I5299c521479dc25ea0f82d7d294d53942960d2cf
This RANAP RESET code...
a) is not used:
osmo-hnbgw has only recently started sending RANAP UnitData by its own initiative.
Until very recently, osmo-hnbgw has only responded to receiving a RESET, with an ACK.
It has never sent a RESET message to the peer, here titan.
b) makes no sense implementation wise:
RANAP RESET handling is actually implemented in RAN_EMulation.ttcnpp.
c) makes no sense protocol wise:
The UnitDataCallback happens when osmo-hnbgw sends a RANAP UnitData to
titan: if at all, the only logical response would be a RESET ACK
message, not a RESET message.
Change-Id: Ie7b9022e991b63b945c7ec6e5c9f7c4eb5da4d7e
When we respond to the MGCP requests from OsmoHNBGW, we use codec name
"FOO" and payload type 23 in the SDP part of the response. This is
obviously an invalid codec and osmo-mgcp-client will not tolerate this
anymore. Let's use a more realistic payload type and codec name, like
112 and "VND.3GPP.IUFP"
Change-Id: Ib53ff7a878087b497e6ff27f786c9ab1297f3d5f
We have sporadic test failure, because the test starts to send RUA
messages before the CN link was able to perform a RANAP RESET + ACK
procedure.
Since recently, osmo-hnbgw is stricter on RANAP RESET: it will only
start passing RUA connections to the CN when the CN link has seen a
RANAP RESET ACK (from either side). So now, when the test is too quick,
its first RUA message is dropped on the floor, and the test fails, since
the RANAP never turns up on SCCP.
This is a quick hack, better would be to wait for some signal from the
RAN_Emulation when we are ready.
This jenkins trace shows that the RUA InitialUE happens about 200 ms
before RESET ACK is complete:
Time Protocol Info
04:02:17.088852 RANAP Reset
04:02:17.105820 RANAP Reset
04:02:17.899887 RANAP (RUA) InitialUE-Message (DTAP) (Unknown)
04:02:17.905122 RANAP Reset
04:02:17.906043 RANAP SACK (Ack=2, Arwnd=106496) ResetAcknowledge
04:02:17.906056 RANAP SACK (Ack=5, Arwnd=106436) ResetAcknowledge
04:02:18.081522 RANAP Reset ResetAcknowledge
04:02:18.082829 RANAP SACK (Ack=4, Arwnd=106496) ResetAcknowledge
https://jenkins.osmocom.org/jenkins/job/ttcn3-hnbgw-test/512/artifact/logs/hnbgw-tester/HNBGW_Tests.TC_rab_assign_mgcp_to.pcap.gz
Change-Id: Icbe7220112fbfe4ff5a5e1b9b65eeec428e51530
I hope that this helps with sporadic test failures because of RANAP
RESET happening during test shutdown.
Change-Id: Ie2088bc8786742a1dffb0132f4b162fb2649fb9b
Since I introduced stricter timeouts on PFCP messages in
hnbgw: add f_pfcp_expect()
commit 6bbfe057af
Change-Id I2117475b695d486b1204d61e5bb21120a6187354
the HNBGW tests with PFCP support fail often:
The Assoc Setup resending timeout (X26) is configured to 5 seconds, and
the timeout to wait for this is also 5 seconds. Every once in a while
they happen to miss, causing a test failure.
Increase the initial Assoc Setup Req timeout to 15 seconds to avoid
sporadic failures.
Change-Id: I4b9af224e2346a4735f3d4e01b234acf56c5f3ff
End the guessing when seeing "timeout of T_guard": set a precise failure
verdict when an expected RANAP/SCCP ("BSSAP") message did not arrive as
expected.
Change-Id: I51c60ed8fcef83c98e6c62c9f62a8c3c665de860
End the guessing when seeing "timeout of T_guard": set a precise failure
verdict when an expected PFCP message did not arrive as expected.
Change-Id: I2117475b695d486b1204d61e5bb21120a6187354
End the guessing when seeing "timeout of T_guard": set a precise failure
verdict when an expected RUA message did not arrive as expected.
Change-Id: I29e6b7659ba53efee9f676197b502f79780ead7e
Increase timeout for expecting an SCCP RLSD from osmo-hnbgw.
Affects tests
HNBGW_Tests.TC_ranap_cs_mo_disconnect
HNBGW_Tests.TC_ranap_ps_mo_disconnect
Rationale:
For the case
RUA --id-Disconnect--> HNBGW ----release-SCCP---- CN
the tests expect behavior not exactly specified.
3GPP TS 48.006 9.2 Connection release:
The MSC sends a SCCP released message. This message shall not contain
any user data field.
So what we should expect is this:
HNBGW MSC
RUA --id-Disconnect-------> | ---Data-Form-1(!)---> | Iu-ReleaseComplete
| <--Released---------- | (no data)
Instead, we expect the HNBGW to immediately send a RLSD to the MSC:
HNBGW MSC
RUA --id-Disconnect-------> | ---Released---------> | Iu-ReleaseComplete
osmo-hnbgw is being fixed in that respect: it will soon give time for
the CN to send an SCCP RLSD, and only if that times out will osmo-hnbgw
send an SCCP RLSD to the CN.
So HNBGW_Tests.ttcn should still ensure that osmo-hnbgw will eventually
send an SCCP RLSD if the CN fails to do so, but it should allow more
time to accomodate the release timeout.
Related: osmo-hnbgw I6ff7e36532ff57c6f2d3e7e419dd22ef27dafd19
Related: SYS#6297
Change-Id: Ibf6eaeb1b82d43e4f208f64a71f2f6e889883a11
osmo-hnbgw will deprecate the 'sccp cr max-payload-len' config option.
To still trigger the 130 byte limit that is now enforced in
libosmo-sigtran, enlarge the NAS PDU.
So far the limit set via VTY was 0 bytes, which will no longer happen in
osmo-hnbgw after I18dece84b33bbefce8617fbb0b2d79a7e5adb263.
Related: OS#5906 SYS#5968
Change-Id: I174b2ce06a31daa5a129c8a39099fe8962092df8
PFCP_Templates.ttcn is not the place to do the conversion between string
and OCT4.
When I wanted to use an OCT4 address in some ts_PFCP_* template, it
dawned on me that it is stupid to convert the OCT4 to a string, just so
that the ts_PFCP_* template converts it back to OCT4.
Related: SYS#6192 SYS#5599
Change-Id: Ib068831787f4256f70a2189a5f36ca1ea1f40c9e
Oliver Smith
Pau Espin
Harald Welte
Neels Hofmeyr
Philipp Maier