Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rotational and cyclical second-marked captures #604

Open
diogo-fernan opened this issue May 26, 2017 · 2 comments
Open

Rotational and cyclical second-marked captures #604

diogo-fernan opened this issue May 26, 2017 · 2 comments

Comments

@diogo-fernan
Copy link

Suppose that it was needed to have tcpdump rotate six captures per minute in a cyclical manner, with each capture spanning the same time frame of 10 seconds. This should be achieved by specifying a rotational 10-second long capture with -G and a template name file with the %S modifier, such as:

# tcpdump -i en0 -n -G 10 -w dump-%S.pcap

The output of the above command should be sequential dumps with 10-second increments as file names, such as dump-01.pcap, dump-11.pcap, dump-21.pcap, dump-31.pcap, and so on.
However, tests reveal that the output is not consistent. Sometimes, it looks like tcpdump creates the files as intended, but other times the seconds on the file names drift. This behavior might happen particularly in captures where network traffic is scarce or nonexistent.

Below follow software, library and kernel versions for macOS Sierra and for an old Ubuntu 14.04 for comparison. The same behavior is observed on both systems.

$ uname -a
Darwin host.local 16.6.0 Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64 x86_64
$ tcpdump --version
tcpdump version tcpdump version 4.9.0 -- Apple version 79.60.1
libpcap version 1.8.1 -- Apple version 67.60.1
LibreSSL 2.2.7
$ uname -a
Linux host 4.4.0-75-generic #96~14.04.1-Ubuntu SMP Thu Apr 20 11:06:30 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
$ tcpdump --version
tcpdump version 4.9.0
libpcap version 1.5.3
OpenSSL 1.0.1f 6 Jan 2014
@mcr
Copy link
Member

mcr commented Apr 16, 2019

Can you provide more details as to how to reproduce your problem?
Can you reproduce the problem with a big -r input file?

@diogo-fernan
Copy link
Author

diogo-fernan commented Apr 16, 2019

Out of the box, make sure that there is network traffic, start a capture, disconnect the network for a while, and connect it back. The example below demonstrates the drift mentioned before when network traffic is scarce or nonexistent.

The capture started at second 29 with an immediate network disconnection following second 39. The network was reconnected on second 04 of the next minute. Should not the output file names be the sequence 29, 39, 49, 59, 09 and 19, regardless of the amount of network traffic (could be empty files)?

 $ ls -hl *.pcap
-rw-r--r--  1 root  staff   130K Apr 16 22:12 dump-04.pcap  # Wi-Fi reconnected
-rw-r--r--  1 root  staff   630K Apr 16 22:12 dump-14.pcap
-rw-r--r--  1 root  staff   259K Apr 16 22:12 dump-24.pcap
-rw-r--r--  1 root  staff   612K Apr 16 22:11 dump-29.pcap  # start of the capture, first 10 seconds
-rw-r--r--  1 root  staff    80K Apr 16 22:12 dump-34.pcap
-rw-r--r--  1 root  staff   435K Apr 16 22:12 dump-39.pcap  # next 10 seconds, Wi-Fi disconnected

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

2 participants