ISDN-AddressString contains an initial byte at the start.
We didn't care so far because we were not yet checking the content of
msisdn, so the usual first '12'O byte was being considered as a header.
Let's store it in GTP format as before, but let's pass it as a
charstring when initializing the PdpContext, so that the human-style is
visible in the test for easy visualization/comparison (It will be
verified in a follow-up patch in Gy Diameter interface).
Change-Id: Ie1b65707d4b08f2201572e1fa44a1f9f985eb096
TS 29.060 states that it shall be included for primary PDP context
activation if the information is available, so let's add it by default.
Change-Id: I8c7e491a07cadfe09403504a82d34e412673a531
This IE is conditionally added if the HLR provides it to the SGSN.
Let's add it by default so that we test code paths where GGSN parses it.
Related: SYS#5925
Change-Id: Ia0f74041d2107afeaa36b94e33474370b7b07c0e
The new message is to be used by Gy interface emulation, which according
to RFC4006 uses AppId 4 "Credit Control Application". The application
is apparently not 3GPP vendor specific.
Change-Id: I0e33673d65140aad34d2efcae3c7f49154ceb99f
We'll start emulating other Diameter-based interfaces soon (Gy), so
let's rename existing stuff which is Gx specific.
The DIAMETER_Emulation only supports handling 1 application-id per
component, and that's fine anyway since the OCS is in general expected
to run in a different conn/node from PCRF.
Change-Id: I1eb03d907b46c4bb24491f390ef468e831190e08
Otherwise a new test may reuse the same GTP seqnum, and if it's still in
the gtp retransmit resp queue of the GGSN, it may be identified as a
duplicate retransmittion of a previous message (previous test) and send
back the previous response instead of processing the request.
Related: OS#5485
Change-Id: I1b04691987b883f63c95c0322a477db4a43df2b1
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
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
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
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
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
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
Various improvements to the comments documenting packet templates
used in GGSN_Tests: fix IPv4 vs. IPv6 confusion, clearly indicate
whether templates are used for sending or for receiving/matching
packets, and add a missing comment.
Found while studying code to prepare for issue OS#2519.
Change-Id: I3bfc21a5ba74e0505457e4874f93501ad7c68b7b
Related: OS#2519
It seems due to the current network configuration, pdp v4 ctx can talk
each other while pdp v6 ctx cannot.
Change-Id: I67c04b056cc5c092d357abbb084b7665f59eaf3a
New dependency is required: titan.ProtocolModules.ICMP
It tests that ICMP echo packets can be sent successfully (reply is
received or otherwise dest unreachable if routing is not set up
correctly during the test). It also tests some cases in which osmo-ggsn
is required to drop the packets (eg. unknown src ip unrelated to pdp
ctx). It also checks that IPv6 packets are dropped in IPv4 pdp ctx and
viceversa It also checks that IPv6 packets are dropped in IPv4 pdp ctx
and vice versa.
Change-Id: Ib9c6043a6cd3b6622782ec7e7fcd2815101755ba