I forgot to update this function in [1]. Let's make it consistent with
the f_TC_speech_rtp(). More details can be found in the linked patch.
Change-Id: I8c2f8bb4cc4b44378af5536893bc73fde368b3fe
Related: [1] Ifb69669b75df5b390d7056cefaf0ef1df69d9bd4
Without this change I cannot run BTS_Tests manually anymore:
Local verdict of MTC: fail reason:
"BTS_Tests.ttcn:480 : Invalid PCU Version/BTS Number received"
Change-Id: If0046b44adb93fba7dced1ce06d5ddb9d7c75269
Fixes: 3b4abb86 "BTS_Tests: Add support for PCUIF protocol version 11"
The S1_SETUP_REQUEST may have an optional IE eNB_Name in between Global
eNB ID and Supported TAs
Related: OS#5760
Change-Id: Id4b52921053884e79349301598b75c264b7f058c
This testcase has been fixed in [1] and is currently passing.
Change-Id: I9bc81629a9baaf922a87ac95c8f69af343aacdf1
Related: [1] I2c328219b1a37d0f4623c5728143cd91976000a0
Related: OS#5972
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
At the moment we do not have a default implementation for the create_cb.
The create_cb is called to resolve the vc_conn to which a subscriber
communication belongs in case it is not found in the S1apAssociationTable,
then it is resolved from an S1apExpectTable instead.
The current implementation uses the IMSI as key to resolve the vc_conn
from the S1apExpectTable, this might not work since in S1AP the UE
context is identfied by an MME_UE_S1AP_ID / ENB_UE_S1AP_ID pair.
Related: OS#5760
Change-Id: I758e7c8d8cc445cf18acdd7a25dcde8846fd84e5
When a S1AP_UeContextReleaseCmd is received, the UE association should
be deleted.
Related: OS#5760
Change-Id: I8c6f7a780945ce34dabdc794aabab5d16a3a73aa
When we search for the entry that we want to delete, we use the
ENB_UE_S1AP_ID as a search key, but we compare it against
mme_ue_s1ap_id. This is not correct, it should be compared against
enb_ue_s1ap_id
Change-Id: I8528af4e3fda0bc97f8b14785097434a6163bcc4
Related: OS#5760
The INITIAL CONTEXT SETUP RESPONSE message may have optional elements at
the end.
Related: OS#5760
Change-Id: Ic28c94093e55db0dc1fa18d36e22d328788cb3fc
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
I want to use it in a new function f_verify_talloc_bytes() added to
Osmocom_VTY_Functions.ttcn in I2948ee6f167369a2252f85b493e9653b93c7e4e9.
Change-Id: I9ddd9977734efd7599481261f04df82620845cef
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
If the talloc count matching failed, immediately stop the failed test.
It is currently used by BSC_Tests.ttcn, and will soon also be used by
HNBGW_Tests.ttcn. These tests were used to uncover memory leaks, and
can now remain to guard against new leaks being introduced.
Change-Id: Id2b29beecf1c0652fb8d75e031e5c0dc9aa27975
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
Fix the missing call to f_ran_unregister_imsi when running f_mt_call.
This is in preparation for calling f_mt_call multiple times during one
test, to test various CSD bearer services. Without this patch, it will
result in a "No space left in ImsiTable" error.
I've also considered adding it to f_call_hangup instead, but this gets
called by f_mo_call (mo instead of mt) as well, which does not run
f_ran_register_imsi.
Related: OS#4394
Change-Id: Ie9b180b95348d7e84650c14a331c5091a1e67d1f
The PCUIF protocol version 11 uses a more distinct (direct TLLI) way
to signal PAGING COMMAND and IMMEDIATE ASSIGNMENT messages towards the PCU.
Since OsmoBTS will soon fully support v.11 of the PCUIF protocol we need
to add compatibility in the OsmoBTS TTCN3 testsuite early. We also have
to stay compatible with older versions of OsmoBTS. The BTS_Tests.default
config still sets up mp_pcuif_version to version 10, so this will be the
default until we have full version 11 support in current master and
latest.
Related: OS#5927
Change-Id: I08de02e951e10bc8b4381cc2ad32e63f2747e3c4
When the PacketCellChangeNotification proposes an UTRAN or E-UTRAN cell,
then the PCU will not provide system information. Instead it will directly
conclude the NACC procedure with a PacketCellChangeContinue message.
Related: OS#6044
Change-Id: Idae86a458fd44ac81bab183ed1865b1c1bdbfd66
The testcase TC_nacc_outbound_success tests the NACC procedure. The cell
that is proposed in the PacketCellChangeNotification is a GERAN cell.
This means that the PCU should conclude the procedure with a
PacketCellChangeNotification that contains the ARFCN and BSIC of the
proposed cell. Let's make sure that this actually is the case.
Related: OS#6044
Change-Id: I4b8f3312088e3d2bc4b90702485e7c6a8d39f954
The record PCUIF_pch_dt uses ALIGN(left) variants for imsi data. This is
not correct, since it would left-pad the data with zeros if it does not
fit the specified length. This is a problem with IMSIs shorter than 17
characters, because the left padded zeros would appear like a
null-string to the receiving end.
When the ALIGN(left) modifier is removed, the encoder will apply the
padding from the right. This will fill the unused space after the string
with zeros.
Related: OS#5927
Change-Id: I011eb2496b1422c49736b227dfa1e2a2d6096d67
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
This patch fixes multiple compilation warnings like this one:
Inadequate restriction on the referenced template variable
`attach_req', this may cause a dynamic test case error at runtime
Change-Id: Iee7760d3dcf2a35d7fe612ed80dc13c1d11e0897
This patch fixes several problems:
* missing "vc_conn.done": the actual testsuite logic, which can be
found in f_TC_attach_timeout_after_pdp_act(), was never executed
fully because we did not wait for the BSSGP_ConnHdlr to complete;
* too short Tguard value: the testsuite logic takes slightly more
time to complete than the default timeout of 30.0 seconds;
* osmo-sgsn does not require authentication for the second ATTACH.req:
the testsuite logic gets stuck in f_gmm_auth() after sending the
second ATTACH.req because:
** osmo-sgsn is waiting for a response to GMM IDENTITY REQUEST,
** osmo-sgsn does not send GSUP SendAuthInfo.req again.
As can be seen from the test execution artifacts on Jenkins, this
testcase never passed: either failing due to an error, or declaring
no verdict at all. The average execution time is 650 ms.
Change-Id: Ibaf2134247153471bd45d7a7f91155294c6c6de5
Fixes: 3ede9e32b "sgsn: Add TC_attach_timeout_after_pdp_act"
Closes: OS#4221
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
osmo-hnbgw since recently sends own RANAP RESET out to the CN links. So
HNBGW_Tests.ttcn now receives a lot more UnitData messages.
Turns out that tests crash when no UnitData callback is provided.
Currently only osmo-hnbgw and RANAP, i.e. ranap_unitdata_cb, needs this
fix, but also apply the same safeguard to the BSSAP unitdata_cb.
Change-Id: I699a42de88b15f6f47b8feece7639e0dfaf31955
Fix for:
BSC_ConnectionHandler.ttcn:1546 Dynamic test case error: Using the value of an unbound boolean variable.
Fixes: 92b280c8 ("msc: new test: TC_lu_and_mo_csd")
Change-Id: I733db4dbc3ba3dd52ba501901b8b0ed36ff13344
Since osmo-pcu.git 95ec50c9e4821ed1bdd15e9e30da1278ec1280c1, OsmoPCU
doesn't allow receiving a FINAL_ACK in FLOW state. This test was not
written properly and was taking advantage of that permissive logic in
osmo-pcu to trigger the target use case. Fix it to have the PCU send the
last DL data block (FBI=1) so that it can send a PKT DL ACK/NACK with
FinalAck=1 to terminate the DL TBF.
Change-Id: Ibd445bdd5cc1d1ffd810eea157829403b4b65f1f
Current osmo-bsc master does not support the MGW keepalive yet, so
f_vty_mgw_cfg_keepalive() fails. This leaves osmo-bsc in unclean
state and makes all LCLS testcases fail. The problem is that before
calling it we also call f_vty_mgw_enable() and f_vty_mgw_block(),
but not calling their counterparts.
Rearrange the testcase to call f_vty_mgw_cfg_keepalive() first,
so that we fail early before calling f_vty_mgw_{enable,block}().
Change-Id: I6a94c441fe80a92c237c3c4a5481f2dac3376e35
Fixes: bd59842b6 "bsc: Introduce test TC_mgwpool_keepalive"
Check if the AoIP Transport Layer IE is present before checking its
value. This gives a more meaningful error than Dynamic Testcase Error if
it is not present.
Change-Id: I52fc829b017848b6afe7e637f1911a0976f9c91d
There is a typo in the CSN.1 definition for CCN Measurement Report.
While fixing this we can also shorten the record name to
"CCNMeasReport" to make it coherent to the Utran/Eutran related
definitions.
Change-Id: I1e44afdbede7420299435ddb7333dd151b5da4b3
The PacketCellChangeNotification type currently lacks the release 6 and
the release 8 additions. Those basically add 3G and 4g/5g compatibility to the
PacketCellChangeNotification message type.
Spec reference: 3gpp TS 44.060 11.2.3a
Related: OS#6044
Co-authored-by: Vadim Yanitskiy <vyanitskiy@sysmocom.de>
Change-Id: I4e1c63c06fb89111765df187a93db563e77c3fc4
Andreas Eversberg
Vadim Yanitskiy
Philipp Maier
Pau Espin
Neels Hofmeyr
Oliver Smith