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
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
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
When introducing the rewriting for 6.3.0 we broke the 6.1.0 support.
Now the result should build on Debian with both 6.1.0 and 6.3.0
Change-Id: I263a6abd2d9eb15ce5778ef8dbfcdac2a228b77d
I spent numerous hours in trying to avoid the dual faced port from
segfaulting, but in the end didn't succeed :(
The easy way was then simply to fall back to the known-working pattern
of the dual-faced port, which I already successfully used also on the NS
module for the Gb Inteface