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
Drop a config line that should not be committed; it was added during
local testing of logging patches that are still unmerged.
Change-Id: Ie29c0e0d80c9318c104fe884868a30c17b6997bb
Set X31 to 5s as expected by the testsuite. The config files changed
here are not used by jenkins, but are used for manual testing by some
developers.
Previous patch ee4ce863 ("hnbgw: Introduce mp_hnbgw_timer_x31") already
sets the timer in one of the configs, move it to the end and add the
comment to make it consistent here and with the configs in
docker-playground.
Related: docker-playground I223d38e9ec2ca0f9f2ce2ac5311932789f328c9a
Change-Id: I1c275a1d10cfe0fe67d71e900881b0c4891af0be
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
It was recently decided it's a good practice to always specify the role
and sctp-role for all ASPs configured in the VTY, since it's an
important configuration providing feedback on the network setup
expectancies.
Change-Id: If48ca06f2cc3c0986daa5f6264d80138d468332a
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
Pau Espin
Harald Welte
Neels Hofmeyr
Oliver Smith
Philipp Maier