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
In commit 0b7545dff1 I accidentially
committed incomplete support for user plane (GTP-U) testing to
the GGSN test.
This code has caused the jenkins tests since August 26th to fail,
let's revert it until this is fully implemented + tested.