We're getting a new TLLI assigned during the attach procedure (see
Allocated P-TMSI in the GMM Attach Accept message), which needs to
be registered in order to receive BSSGP PDUs from BSSGP_Emulation.
Change-Id: Idafcbd7e44a523a26dc34dc72e38ff879782148e
Ensure the expected default UEA configuration, which is always
reset properly even if one of the testcases aborts due to a DTE.
Change-Id: Ic2c5a11e86e4349796fa7508076ac27ef22815cd
Since recently, osmo-sgsn is requesting encryption (UEA1 + UEA2)
in RANAP Security Mode Command by default [1]. The testcase
TC_iu_attach is assuming no encryption (UEA0) and thus failing.
Fix this by explicitly setting UEA0 via the VTY, similarly to
what testcase TC_iu_attach_encr does.
Change-Id: Ibaf83db1ab0f82f7e934e89ae3f6c19d014be197
Related: [1] osmo-sgsn.git I4eb9451b4267fc1436ed90a55ff200cf36f16bf6
In 1ee1edd2 I changed f_routing_area_update() to actually use the
given RAI as Old RAI in the Routing Area Update Request. Not only
this broke the testcase scenario (Old RAI shall remain unchanged!),
but also started triggering a use-after-free bug in osmo-sgsn.
Passing 'ran_index := 1' is enough for the second Routing Area Update
Request to show up with a different RAI (at BSSGP level), however the
Old RAI IE shall obviously indicate the *old* RAI, not the new one.
A follow-up commit will add a separate testcase to reproduce the
use-after-free problem in osmo-sgsn.
Change-Id: Ib16985cb08834a238ca4f7a747c43097f430ed6f
Fixes: 1ee1edd2 "sgsn: fix unused param in f_routing_area_update()"
Related: OS#6439
The Types are already split in the dependent modules in GTPC_Types and
GTPU_Types.
There's no point in keeping them together in the same file since those 2
protocols are mostly independent.
Furthermore, testsuites using GTPv2C + GTPv1U don't need GTPv1C.
Change-Id: Ic15c9a2e92828cbafb4dda7355ee534107051e2d
The previous PDP-Type IE should have been a PDP-Address from the
start, since having only PDP-Type with no address is only a specific
case (dynamic addressing).
This becomes clear by looking at other similar protocols like:
* MAP: APN-Configuration IE has servedPartyIP-IP{v4,v6}-Address IEs
* Diameter S6b, 3GPP TS 29.272 7.3.35 APN-Configuration contains
Served-Party-IP-Address AVPs
* Diameter SWx, 3GPP TS 29.273 APN-Configuration.
* GTPv1C Ts 29.060 7.7.29 PDP Context containing PDP Address.
Since PDP-Type on its own really makes no sense, being it a special case
of PDP-Address, let's keep the IE by renaming it (keeping old name too
for API backward compat) and extend it to support lengths > 2 bytes.
Old implementation of libosmogsm gsup actually ignored lengths > 2
bytes, so we are safe acting against older implementations here, both
on the sending and receiving side on the wire.
Change-Id: I3e92368fff61694bcef6a48320595b59ae8f54ca
Related: OS#6091
Related: libosmocore.git Change-Id I775ff9c3be165d9f30d6ab55d03f99b6104eadd6
Related: osmo-gsm-manuals.git Change-Id I775ff9c3be165d9f30d6ab55d03f99b6104eadd6
When sending the RAN INFORMATION REQUEST on GTP-C, we do not add a RIM
ROUTING ADDRESS + RIM ROUTING ADDRESS DISCRIMINATOR field. Those fields
are optional but commonly added so that the SGSN does not have to
disassemble the RAN TRANSPARENT CONTAINTER to know the destination
address.
see also: 3gpp TS 29.060, section 7.5.14 and
3GPP TS 23.060, section 8.1.5.2.2
Change-Id: Id944c66f28d787a18c6c6f7c9dc885997d83e94c
Related: OS#6095
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 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
Until recently, the asp-clnt-* ASPs, which have specific handling in osmo_sccp_simple_client_on_ss7_id(),
were being always forcedly set to sctp-role CLIENT by code in that
function.
This prevented user of that API from explicitly configuring the ASP as
"sctp-role server" through the VTY as the option would be overwritten silently.
Now, the sctp-role from config is followed if the ASP is
defined/configured through the VTY (not dynamically created at the time
osmo_sccp_simple_client_on_ss7_id() is called).
Since the default for a VTY-specified ASP is to be in "sctp-role
server", the config files need to be updated to properly configure the
ASP to be in "sctp-role client", which is the desired mode here.
Same applies for "role", where the default is SG but it is actually used
as "ASP" here.
Change-Id: I4eb5b5f6b4b24df079b4c74e2a2e2ebb8769b0bd
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
Test new osmo-sgsn Iu attach with UEA (encryption) enabled
Related: SYS#5516
Depends: I27e8e0078c45426bf227bb44aac82a4875d18d0f (osmo-sgsn)
Change-Id: I1a7c3b156830058c43f15f55883ea301d2d01d5f
The resulting set of dependencies needed just to have one simple CellId
struct is huge. That was fine for sgsn testsuite since anyway those were
being used, but it's not acceptable for other testsuites (hnodeb) which
only really require the GTP side.
After this change, GTP_Templates only requires GSM_Types, which ends up
in a much smaller subset of dependencies being pulled in.
Change-Id: Icd8234908af445b798517fe110cd0648969179a4
Set the executable name in each regen_makefile.sh explicitly with -e,
instead of having it set indirectly from the first .ttcn file. Make it
consistent by placing the name on top of each of these files.
Fix for warning:
ttcn3_makefilegen: warning: File `BSC_Tests.ttcn' was given more than once for the Makefile.
Related: OS#5252
Change-Id: I5ed03f8f3ed905483620dc7bae33b617bbb8507f
Make all regen_makefile.sh more readable and diff friendly by moving
each entry in FILES and CPPFLAGS_TTCN3 into separate lines. Order
entries alphabetically.
Related: OS#5252
Change-Id: I6b6866eb9f6ec6232e4ae434517457a4c8c1c050
This adds a few tests that ensure that the encryption algorithm dynamically chosen is
1) one actually supported by both the sgsn and the UE
2) the strongest one available both have in common
Change-Id: Iad65cbf9840aa883cb34e53554b94a4142c82638
Related: SYS#5324
RAW_NS used previous a single TTCN3 port for a single UDP port
(source/listen side).
This has the limitation that only a single NSVC could be tested for a
local UDP port. However SNS tests require multiple NSVCs over a single UDP port.
NS_Provider_IPL4 already supports multiple NSVCs for the NS_Emulation.
Extend the support in NS_Provider_IPL4 to also allow RAW_NS to use
multiple NSVCs.
Related: OS#5036
Change-Id: Iafd9310e04066958914201da0cbdcd563bd5c976
GTP_Templates.ttcn new templates use BssgpCellId, hence it depends on Osmocom_Gb_Types.ttcn.
Related: SYS#5314
Change-Id: I9dcf6ee2dc55bc6aba178eca30080233254f025e
it has been deprecated in libosmocore.git 2.5 years ago:
commit 7e0686c6b4b456ec4e6e15689694b1bcf96c301f
Author: Neels Hofmeyr <neels@hofmeyr.de>
Date: Mon Sep 10 20:58:52 2018 +0200
Change-Id: Ieb9e958278e7bb9d5e798f83b70dcb873a25d06d
In libosmocore I34b8fde2955ecc010d1dcd9512e1bba9211e2c0d we introduced
a new log subsystem; enabel it in the related configs here
Change-Id: Ie3d178e68aa81d5636c87940074cb6582ac2f131
In f_routing_area_update() we are sending a RAU Complete to the SGSN
and then immediately afterwards send a GTP-U from the simulated
GGSN to the SGSN. That GTP might reach the SGSN faster than the
RAU Complete, resulting in a test failure.
Change-Id: Ic489e0857115cf24965e413a39918edc5a8f44f8
This was introduced in I7d859fd710dba96eb9b46c428243281183e1be12
and caused Iu related TTCN3 tests to fail with:
SGSN_Tests.ttcn:771 Dynamic test case error: Index overflow in a value of type @SGSN_Tests.BssgpCellIds: The index is 3, but the value has only 3 elements.
Change-Id: Iaae0015f5e7c7eabc426add91b5de1b63bf6d9f6
Test TC_cell_change_different_ci_data provides test case for
fix in osmo-sgsn.git Change-Id I2c14e1d65575f54212924f7c5f0a2f4c1b76ec81
Related: SYS#4909
Change-Id: I2158685bf817d4bf064bb4d2ef5aa96ca252fe21