summaryrefslogtreecommitdiffstats
path: root/ttcn3-tcpdump-start.sh
AgeCommit message (Collapse)AuthorFilesLines
2019-10-04Create dummy gsmtap sink with netcatPau Espin Pedrol1-6/+21
otherwise ICMP messages appear in pcap files and some messages are lost since they seem to be dropped by the kernel. Change-Id: Id69d98db63f8260067ad6bc1525fb05c936912f2
2019-03-19Use dumpcap for ttcn3-tcpdump-*.sh if availableMax1-0/+16
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
2019-03-14Generalize ttcn3-tcpdump-*.shMax1-9/+9
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
2019-03-07log time in tcpdump-start and -stop.shNeels Hofmeyr1-0/+3
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
2018-05-15ttcn3-tcpdump-start.sh: reduce snaplen of tcpdumpAlexander Couzens1-2/+2
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
2018-02-18ttcn3-tcpdump-start.sh: Don't call tcpdump log files ".log"Harald Welte1-1/+1
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
2018-02-15ttcn3-tcpdump-start.sh: Wait for tcpdump to start recordingPau Espin Pedrol1-5/+14
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
2018-02-15ttcn3-tcpdump-start.sh: Wait for pcap file creation to start testPau Espin Pedrol1-0/+10
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
2018-02-15ttcn3-tcpdump-start.sh: Log tcpdump output to filePau Espin Pedrol1-1/+1
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
2018-02-14re-organize configuration files; add tcpdump integrationHarald Welte1-0/+24
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