This test validates that changing the local TEID through UpdatePDPContext
is correctly followed by the GGSN.
Change-Id: Ic6af25866bf7efc2cabf029e49abaf15d5857592
The existing test TC_pdp46_act_deact_gtpu_access_wrong_global_saddr_ipv6
was wrong, because the global address was being finally encoded as a
link local address by f_gen_icmpv6_router_solicitation().
Let's rewrite the test and add a new one for source link local addresses
simlar to the ones used to test IPv6-only APNs.
Change-Id: I3d0790104abea7acb4fa5e33109fe93cc51d94ea
Those tests validated several different scenarios, let's better handle
them separately one at a time, it makes it easier to understand the
behavior of the SUT and see what needs to be fixed.
Change-Id: I39342fcf2366030ce743dd4b4773f0fff5d61b9f
This patch fixes the following DTE happening sporadically:
04:09:29.373271 mtc GGSN_Tests.ttcn:1478 Dynamic test case error:
The first argument of function int2oct(), which is 256, does not fit in 1 octet.
Change-Id: I517b8e5d5872c36f7c759433a1cde338c90f16da
It's not really clear whether GTP should really be forwarding packets
with link-local address outside the tunnel. In theory the link-local
address should be used to communicate with the GGSN in order to get the
global link address, that's it. Running against open5gs it can be
observed that they are not forwarded, while osmo-ggsn forwards them
correctly.
Since it seems more like an implementation dependent detail, let's
accept any and adapt expectancies depending on what are we testing, this
way it ends up documented the current situation in case it ever changes
in the future.
Change-Id: Ieafd24c059b9341c702311c78caad3312db5f1f3
According to TS 29.060, sec 7.3.1 Create PDP Context Request:
"""
The SGSN shall include the User Location Information IE in the PDP
Context Activation procedure. The SGSN shall include the CGI or SAI
in the "Geographic Location" field of the User Location Information
IE depending on whether the MS is in a cell or a service area
respectively.
"""
Change-Id: Iaea95e5779d4f878023ce3f160ac69f092452056
According to TS 29.060, sec 7.3.1 Create PDP Context Request:
"The SGSN shall include the RAT Type IE during Primary PDP Context
Activation procedure."
Change-Id: Ibc57798e50ccd08ef6126f75f7c8134e56d2778a
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
GTP_Templates.ttcn new templates use BssgpCellId, hence it depends on Osmocom_Gb_Types.ttcn.
Related: SYS#5314
Change-Id: I9dcf6ee2dc55bc6aba178eca30080233254f025e
In TC_pdp4_act_deact_with_single_dns we activate, deactivate and then
re-activate a PDP context. Hoewver, we re-use the same variable and
don't reset the state in between. This results in the second PDP CTX
activation to include an end-user-address (static IP allocation), which
OsmoGGSN doesn't implement.
Before osmo-ggsn Change-Id Iac8868438655fe4e5e07d167d7dbd6273dbb7678,
the test passed as osmo-ggsn simply ignored the requested static address.
After that change, we reject static addresses and hence the test starts
to fail.
Change-Id: I1b1869bc2cee39c8fddd8fa63f48bdaa6a65e462
Related: OS#5097
Some stuff was wrong and some was missing after new features being
implemented in tests over time.
Change-Id: I7a279592a68ffc76408a8e728e76151534265cc0
This change fixes some GGSN_Tests failing lately since osmo-ggsn
correctly sends DeleteCtxReq for dangling pdp ctx upon increased
Recovery counter received, and tests are not expecting that (because
they don't expectect dangling pdp ctx from previous tests).
Change-Id: I232298e2bfd8bfc99d82cbf5803d11db7eb1786a
Some code is moved out of f_pdp_ctx_act() into f_handle_create_req() in
order to re-use it in the test.
Related: OS#4165
Change-Id: I48c1bc9287ce8b820e5ea672dffbc5a8503f16d7
VTY functionalities to enable and disable echo requests in osmo-ggsn are
added too as part of the test.
Depends: osmo-ggsn.git Id2c84165dc59dff495106758146a701ca488834f
Related: OS#4165
Change-Id: Ia37e48e7ff9ad063f9eabf447f8a6a0a3fc380d9
This test case reproduces a real-world PCO capture including a broken
PAP AuthenticationReq. It triggers some weird behavior in OsmoGGSN
1.3.0 where it would send duplicate IPCP repsonses and no PAP response.
Change-Id: Ie89d984ed9e26fbbb2e4914bdb8623446d462a4c
Related: OS#3914
Some of our files didn't have a copyright notice at all, let's add
it. Also, update the notices in other files and ensure a SPDX
identifier is present in all but the most trivial files.
Change-Id: If7fa19ce484b415bc645e39b3d0d666b44b5f0fd
Introduce a function to verify there's no duplicate ProtocolIDs
in the PCO returned from the GGSN.
Change-Id: I9d439dab1696196cd125f4d7113b426f1711a405
Related: OS#3914
Add related templates based on 3GPP TS 29.060 Figure 37A and create
tests based on existing IPv4 and v6 ones.
Related: OS#2900
Change-Id: I3bab7df5caddc5c8b973c81544f954d5473ac234
This function can now be called from anywhere to try and safely shutdown
a testcase. It is not optimal as we can't call "all component.stop" from
outside the mtc, but without any proper and orderly shutdown handling of
all our emulation components I believe this is the best we can do.
To use it:
import from Misc_Helpers all;
in your module and then call
Misc_Helpers.f_shutdown(__BFILE__, __LINE__);
You can also pass the function a verdict and a message and it will take care
of calling setverdict, but beware of the following:
While setverdict would accept any number of arguments as log message
and convert them to a log string f_shutdown expects one charstring.
It's possible to use the log2str function to use the log arguments in
setverdict for f_shutdown, for example
setverdict(fail, "Template didn't match: ", tmpl_foo);
would become
Misc_Helpers.f_shutdown(__BFILE__, __LINE__, fail, log2str("Template didn't match: ", tmpl_foo));
Change-Id: I84d1aa6732f6b748d2bfdeac8f6309023717f267
Pass the CTRL_DETECT_CONNECTION_ESTABLISHMENT_RESULT parameter to
the TELNET port by default. This allows tests to make progress
into an error handling path if they are started while the osmo-*
program they want to connect on VTY is not running.
Observed with osmo-ggsn tests, where if the one test runs
into a VTY connection failure the subsequent test would get
stuck forever in a map() call on the VTY TELNET port.
Teach the function f_vty_wait_for_prompt() about connection
reports by the TELNET module. We may now receive an integer which
represents the socket file descriptor for the telnet connection.
This case was not handled by the previous change made in
commit cb111b21ab. As a result,
BSC tests started failing with "VTY Timeout for prompt" because
the alt-statement in f_vty_wait_for_prompt() would not progress
past the integer sitting on the VTY port's receive queue.
Change-Id: I56925f93af6c55e93f3f417099db135744da6a40
Related: OS#3149
With this patch, I see all ttcn3-bsc-tests failing with
"Verdict: fail reason: VTY Timeout for prompt"
This reverts commit cb111b21ab.
Change-Id: I215d7ab5eee75cf6d3afaac760af64356c943140
Pass the CTRL_DETECT_CONNECTION_ESTABLISHMENT_RESULT parameter to
the TELNET port by default. This allows tests to make progress
into an error handling path if they are started while the osmo-*
program they want to connect on VTY is not running.
Observed with osmo-ggsn tests, where if the one test runs
into a VTY connection failure the subsequent test would get
stuck forever in a map() call on the VTY TELNET port.
Change-Id: I9acf7793d5d68aec6d087cff254a10d8b673dab1
Related: OS#3149
Do not delete the PDP context too early, and look for the second DNS
server in the correct place (2nd match on IPCP protocol, not 1st).
Update a comment which talks about a bug which has been fixed.
Change-Id: I109491cc9ccb060792e29bf6b2999ef48723edbf
Related: OS#3319
Related: OS#3381
When the protocol configuration options (PCO) contain an IPCP container
then lists only one one DNS server (normally there are two included, a
primary and a secondary). Than the parser in osmo-ggsn runs into an
endles loop. This testcase tries to provoke this behavior by sending
PDP CONTEXT ACTIVATE messages with PCO that contain only a single DNS
entry per IPCP container.
The hanging of osmo-ggsn is already fixed (see Depends). However when
Primary and Secondary DNS are in separate IPCP containers, then only
the first IPCP container is parsed (see also OS#3381)
Change-Id: I71761e1f9db7ceac3c3df43d2e539f8c8d53c4fc
Depends: osmo-msc Icffde89f9bc5d8fcadf6e2dd6c0b4de03440edd5
Closes: OS#3288
Related: OS#3381
GTP-U transmit sequence numbers are entirely optional and probably
don't serve any real purpose in real-world deployments.
While OsmoGGSN in userspace implements support for it, the kernel GTP-U
implementation doesn't. This means a number of tests fail against
kernel GTP-U only for that reason.
Let's switch all tests to disable GTP-U sequence numbers, and only
enable it in one specific test. This way, we can execute the tests
also against kernel GTP-U.
Related: OS#3215
Change-Id: I666f5276749ef6a1a4dc170a3b9a747f626f6b2c
'make clean' as generated by ttcn3_makefilegen removes all *.log files, which
of course cleans out expected-results.log, which should not happen. Since this
is a junit XML file, rename the suffix to .xml.
Change-Id: Ic334f6b758eef865e3a497aa430691a3ae696d25
Add VTY functionality to GGSN tests, and use the VTY to enable/disable
GTP-U Tx sequence numbers in the running osmo-ggsn.
The GTPU packet template now makes sequence numbers optional.
A template created with its sequence number set to 'omit' will result in
a packet without a sequence number, i.e. the 'sequence number present' bit
in the packet header is cleared, and the sequence number field is omitted
from the encoded GTPU T-PDU packet.
Re-use the existing TC_pdp4_clients_interact() test for testing the
behaviour of osmo-ggsn. This test is now run twice, once with and
once without GTP-U Tx sequence numbers. Verify that packets relayed by
osmo-ggsn match its "g-pdu tx-sequence-numbers" configuration setting.
Change-Id: I1dc299407c61b1c865035add44067b8ab89001b3
Related: OS#2519
Compare current test results to the expected results, and exit in error on
discrepancies.
Add compare-result.sh: (trivially) grep junit xml output to determine which
tests passed and which didn't, and compare against an expected-result.log,
another junit file from a previous run. Summarize and determine success.
Include an "xfail" feature: tests that are expected to fail are marked as
"xfail", unexpected failures as "FAIL".
In various subdirs, copy the current jenkins jobs' junit xml outputs as
expected-results.log, so that we will start getting useful output in both
jenkins runs and manual local runs.
In start-testsuite.sh, after running the tests, invoke the results comparison.
Due to the single-line parsing nature, the script so far does not distinguish
between error and failure. I doubt that we actually need to do that though.
Related: OS#3136
Change-Id: I87d62a8be73d73a5eeff61a842e7c27a0066079d
The purpose of the various IP addresses used by our GGSN tests is not
immediately clear. Add documentation based on the current status quo.
Change-Id: I079efcff3dab09d71330625f5b661cd81e42bf38
Pau Espin
Vadim Yanitskiy
Oliver Smith
Harald Welte
Daniel Willmann
Stefan Sperling
Neels Hofmeyr
Philipp Maier