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
Various tweaks are required to allow RAN_Emulation to handle, and also
to expect, an SCCP CR that has no payload data.
Related: SYS#5968
Related: If0c5c0a76e5230bf22871f527dcb2dbdf34d7328 (osmo-hnbgw)
Change-Id: I827e081eaacfb8e76684ed1560603e6c8f896c38
ranops was not isvalue because bssap_reset_retries was not set and not
explicitly omitted either, so the ran adapter decided not to create a
ran emulation...
Change-Id: Ib2d3f1fbcfbd53af1e627bd2cf36c3153fa7d012
Neels Hofmeyr
Pau Espin
Daniel Willmann
Eric Wild