I see packets of 1520 bytes in the generated pcap running under the
docker setup. This happens when a lot of IPA concurrent clients send
messages and end up in the same TCP packet due to naggle algorithm.
Change-Id: I362371508ba83acc48376b6ed012a97a59d4b31b
The old output is preserved, too, in order to ensure
compatibility with expectations regarding legacy behavior.
Related: OS#5736
Change-Id: Ia92ff32c8ce09ab7805c5509837ec88fa4b864c5
After replacing debian-stretch-titan with debian-bullseye-titan, tcpdump
does not run anymore, the binary is in /usr/bin and not in /usr/sbin.
Related: OS#4969
Change-Id: I18c88c45c7522c1120ca42cd48d67fe8f155cd39
if we test if /sbin/setcap exists, we als should execute it from that
path, as running from a normal user doesn't have /sbin included in $PATH
Change-Id: I5131f869f86e6d136e0485da5e3749abbfc951e3
otherwise ICMP messages appear in pcap files and some messages are lost
since they seem to be dropped by the kernel.
Change-Id: Id69d98db63f8260067ad6bc1525fb05c936912f2
Check if dumpcap is installed (either as suid or with appropriate
capabilities) and use it for packet capture instead of
'sudo tcpdump' if available. This makes it easier to use TTCN-3
testsuite as regular user without altering sudoers.
Change-Id: I77df04d51a469c924cf727f0596cc33565909746
Prepare for supporting alternative packet dumpers:
* reword comments
* rename pidfile
* move tcpdump-specific option inside if
* move comment about sudo closer to actual sudo invocation
Those are cosmetic changes which do not affect how packet dump is made
but makes it easier to support alternative packet dumpers in follow-up
commit.
Change-Id: Ib2528db65348c0422fe8b7c7c53656fbce4f6405
Also log the testcase name in tcpdump-start.sh.
The output now looks like
------ MSC_Tests.TC_mo_cc_bssmap_clear ------
Thu Mar 7 13:21:00 UTC 2019
[...]
Thu Mar 7 13:21:04 UTC 2019
====== MSC_Tests.TC_mo_cc_bssmap_clear pass ======
The reason to log start and end dates came up like this: I noticed a segfault
in a tested program at a specific time. From the timestamp I tried to find out
which of the tests saw the failure. (After a segfault, all subsequent tests run
and fail, but it is not obvious which failure occured because of a segfault,
and which ones just normally failed before that.) Looking at the timestamps of
the log files didn't help, because the ttcn3_logmerge touched those after the
tests completed. So the only way is to cat each individual log file and find
the timestamp.
So this adds an overview of the timestamps without needing to open log files.
Change-Id: I0832d9b5df599baad5dec8d3a993481b4286fbb3
Improve speed of tcpdump startup. -s 0 sets the snaplen is 256k.
tcpdump will request the snaplen multiplied by the buffer as
a contigous buffer in the kernel. This could lead to higher
start time.
Change-Id: I8a372e71798b366faa3b723573c60de6e8fd128f
The problem is that we use ttcn3_logmerge FOO_Tests.*.log and that the
tcpdump stdout log files also match this pattern. Call them
.pcap.stdout in order to avoid them falling into the globbing pattern of
the TITAN log files.
Change-Id: Iac1ae217b006182121d86375ffa4d3c00ef37e8b
We generate some fake transit and we wait until we catch tcpdump already
saved some packet into the pcap file, this way making sure it is already
recording before starting the test.
The -U flag (--packet-buffered) is added to increase the chances to
sleep less time waiting for stuff being saved into the pcap file.
According to tcpdump manual:
"""
If the -w option is specified, make the saved raw packet output ``packet-buffered''; i.e., as each packet is saved, it will
be written to the output file, rather than being written only when the output buffer fills.
"""
Change-Id: I91cfd84ff5356857a13af1901abfe2204a93f76d
It was spotted in the jenkins artficats that pcap files for some tests
are missing. It is probably due to the fact that tcpdump is started in
the background and immediately after the test is started. Some tests are
really quick, which means they are executing before tcpdump starts
creating the file and recording.
While still having the file created doesn't mean tcpdump is already
recording, we at least ensure the file is created and we can see it's
empty at the end. Running this patch in my PC indeed shows that usually
the pcap file is not created immediately after and it waits for 1 second
to continue.
The hack to make sure tcpdump is already recording before starting the
test is to create some traffic (ie ping 127.0.0.1) and then check the
following condition: $(tcpdump -r file.pcap | wc -l) -gt 0
Change-Id: I17a456a27c8e33571f333f4b7efdf61161ebb174
This can be useful in case there was an error in tcpdump, or to make
sure no packets were lost while capturing.
Change-Id: I8d7570bba3c21c017ba38d36185f6ae042967599
Let's make sure we share common configuration between the test
suites and split the config file into a "default" part which is
used (but not copied) in the Docker images, and a "local" part
which is basically those overrides that the user (or docker image)
wants to do from the default.
Change-Id: I3db452e24e5238aa05254d903739c64d202e61db
Pau Espin
arehbein
Eric Wild
Oliver Smith
Harald Welte