| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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
|
