This option should be used for any executables which are used only
for testing, or for generating other files and are consequently never
installed. By specifying this option, we are telling Libtool that
the executable it links will only ever be executed from where it is
built in the build tree. Libtool is usually able to considerably
speed up the link process for such executables.
Change-Id: I2ca675e93dc5b34bb08d3b841adc115e93558137
When using 'check_PROGRAMS', autoconf/automake generates smarter
Makefiles, so that the test programs are not being compiled during
the normal 'make all', but only during 'make check'.
Change-Id: Ia8b8dade0056c51d2dd1d814a89d1de064597344
QUEUE_SIZE holds the number of pending transmitted messages
which can be handled concurrently.
Current value was 1024, same as PDP contexts (PDP_MAX). However, that
seems to be a quite low amount, which can be filled under certain
conditions, for instance if recovery procedure is triggered on the GSN
which is running full (around PDP_MAX pdp contexts created).
In this scenario, the GSN would need to send around PDP_MAX concurrent
messages (DeletePDPContextReq), which means the queue would very likely
end up being full.
Hence, let's define QUEUE_SIZE based on PDP_MAX, and set it to twice the
size to make sure it won't be filled in extreme conditions.
Change-Id: I6034b0fab2b2e5962314c2fca2f893246ce5cf4f
Coverity warns around that test code:
"Overrunning struct type in46_addr of 20 bytes by passing it to a
function which accesses it at byte offset 39."
That's basically because in64a_from_eua expects to be passed a 2 element
array to be filled. The second element, though, is only accessed in the
case where an IPv4v6 EUA is passed, so in the cases where the test
explicitly passes an IPv4 or IPv6 EUA it's not really an issue, hence
coverity throwing a false positive here.
Let's anyway rewrite the code to pass a 2 element array for completeness,
since it doesn't hurt and makes coverity happy.
Related: Coverity CID#249006
Change-Id: Idfc9104f48eeee6e7f11ebc5c17d4b0e4b2fe9e2
Let's disable category here since we don't care about its formatting here.
In any case, every test relying on logging output validation should
always explicitly state the config to avoid issues in the future if
default values change.
Change-Id: Icce09882ef3ed07328679594ff84902383d16c72
Related: OS#5034
queue_test.c:39:3: warning: format '%ld' expects argument of type
'long int', but argument 9 has type 'unsigned int' [-Wformat=]
Change-Id: Ie9530cdd191386ca3f6c336684f81c4582c4d962
Before this commit, when an MS requested an ipv4v6 context osmo-ggsn
returned an error stating the type was unknown, and this text was
printed in the log:
Processing create PDP context request for APN 'ims'
Cannot decode EUA from MS/SGSN: f1 8d
This patch has been tested with an MS running the 3 types of addresses:
- IPv4 and IPv6: no regressions observed, the context is activated and
packets are sent to the ggsn.
- IPv4v6: Wireshark correctly parses request and reponse, and then
ICMPv6 traffic from both sides. Finally I see the MS using the IPv4 and
IPv6 DNS addresses advertised and TCP traffic over IPv4 (because
probably my IPv6 network setup is not correct). I also checked I can
disable/enable data (pdp ctx delete and activate) several times without
any issue.
Change-Id: Ic820759167fd3bdf329cb11d4b942e903fe50af5
Commit dda21ed7d4 modified previous calls
to ippool_new() removing the pass of flags to avoid allocating certain
problematic IPs from the pool to MS, such as the network, gateway and
broadcast IPs.
Today I did some unsucessful tests with osmo-ggsn with a pool "ip prefix
dynamic 176.16.222.0/24", and thus IP 176.16.222.0 was being assigned to
the MS. De-capsulated DNS packets were received in the tun interface,
but the Linux system in there was unable to correctly forward the
packets to the gateway interface connected to the Internet. However,
adding a second MS which got 176.16.222.1 had its packets forwarded
correctly.
However, previous implementation relies on flag IPPOOL_NOGATEWAY flag to
blindly blacklist first IP after the network ip (ie, .0 and .1 are
removed), which limits the IP reserved for the tun device to be .1. If a
different IP in the range is assigned, it may cause issues. As a result,
a blacklist is introduced in this commit to dynamically fetch the tun IP
address and exlucde it from the pool of available IPs.
Change-Id: I8e91f7280d60490c858a769dd578c1c8e54e9243
Take the chance this commit is changing test output to also remove use
of IPPOOL_NOGATEWAY which is going to be removed soon, and instead test
IPPOOL_NOBROADCAST.
Change-Id: I95c24bc690490155bec9e3933d678e4668d7745f
This doesn't yet cover all the functions in gtpie.[ch], but testing half
of them is better than not testing any of them, so let's merge this
current state with a couple of TDOO's on what we still need to test.
Change-Id: I30a6dd8a01b7a074ef2d3936d186dfff6c79e6c0
This test creates a variety of v4 (and one v6) pool and performs
allocations until the pool is full, then frees a random number of
randomly distributed addresses, re-allocates them and again checks that
they're all available and finally once the pool is full allocations
fail.
Change-Id: Ibf4588e8f3ae71684e5262c0caaa2689aee73a94
All those will be re-generated by "autoreconf -i" anyway, so
there's no point in keeping them in the repository.
Also, the 'bootstrap' script is no longer working with recent
autotools versions anyway.
Vadim Yanitskiy
Pau Espin
Neels Hofmeyr
Harald Welte