Bug 210031 - tcpdump -G flag unable to roll over pcap files
Summary: tcpdump -G flag unable to roll over pcap files
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Many People
Assignee: Allan Jude
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-04 18:43 UTC by Shirkdog
Modified: 2016-06-08 22:49 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Shirkdog 2016-06-04 18:43:44 UTC
Tested on the FreeBSD 11 Current:

FreeBSD  11.0-ALPHA2 FreeBSD 11.0-ALPHA2 #0 r301230: Fri Jun  3 03:01:37 UTC 2016     root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

Ideally, tcpdump can be used to log network traffic to disk and roll the pcap files based on a time setting, such as 60 seconds with -G 60.

On 11-Current, it appears that there is an issue with capabilities in using this feature. After 60 seconds with -G 60, tcpdump will write the file, but it will be unable to open up and write to a new file.

Here is the output from the cli (11-ALPHA Live CD under bhyve )

root@:~ # tcpdump -i vtnet0 -nns 0 -G 3 -w /tmp/test.pcap
tcpdump: listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
tcpdump: /tmp/test.pcap: Not permitted in capability mode
root@:~ # ls -ltra /tmp
total 36
drwxr-xr-x  17 root  wheel     4096 Jun  3 03:16 ..
drwxrwxr-x   2 root  operator   512 Jun  4 14:35 .snap
drwxrwxrwt   2 root  wheel      512 Jun  4 14:35 .X11-unix
drwxrwxrwt   2 root  wheel      512 Jun  4 14:35 .XIM-unix
drwxrwxrwt   2 root  wheel      512 Jun  4 14:35 .ICE-unix
drwxrwxrwt   2 root  wheel      512 Jun  4 14:35 .font-unix
drwxrwxrwt   8 root  wheel      512 Jun  4 14:38 .
drwxr-xr-x   2 root  wheel      512 Jun  4 14:38 bsdinstall_etc
-rw-r--r--   1 root  wheel       24 Jun  4 14:41 test.pcap
root@:~ #
Comment 1 Shirkdog 2016-06-04 18:51:39 UTC
This issue apparently does not affect 10.3-STABLE.

Here is a more realistic way to run this and output:

On FreeBSD-11
tcpdump -i vtnet0 -nns 0 -G 5 -w "test-%H%M%S.pcap"

root@:~ # tcpdump -i vtnet0 -nns 0 -G 5 -w "/tmp/test-%H%M%S.pcap"
tcpdump: listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
tcpdump: /tmp/test-144634.pcap: Not permitted in capability mode
root@:~ # 

On 10.3-STABLE

# tcpdump -i vtnet0 -nns 0 -G 3 -w "test-%H%M%S.pcap"
tcpdump: listening on vtnet0, link-type EN10MB (Ethernet), capture size 65535 bytes
21 packets captured
22 packets received by filter
0 packets dropped by kernel
# ls -ltra test*.pcap
-rw-r--r--  1 root  wheel   800 Jun  4 14:49 test-144926.pcap
-rw-r--r--  1 root  wheel  2084 Jun  4 14:49 test-144936.pcap
-rw-r--r--  1 root  wheel   216 Jun  4 14:49 test-144940.pcap
#
Comment 2 Allan Jude freebsd_committer 2016-06-08 21:48:38 UTC
I found the problem, it is a regression


When tcpdump was switched for casperd to libcasper, the ifdef's were spelled 'HAVE_CAPSPER', seemingly on purpose, but the define via the make file, spells it correctly, HAVE_CASPER, so the code to create the files safely within capsicum, is never compiled into tcpdump.

Opps.

I will talk to the author of the code today or tomorrow at BSDCan, and get it resolved.
Comment 3 commit-hook freebsd_committer 2016-06-08 22:30:37 UTC
A commit references this bug:

Author: oshogbo
Date: Wed Jun  8 22:30:22 UTC 2016
New revision: 301701
URL: https://svnweb.freebsd.org/changeset/base/301701

Log:
  Fix spelling of the casper introduced in the r296047.

  PR:		210031
  Reported by:	AllanJude, jmallett

Changes:
  head/contrib/tcpdump/addrtoname.c
  head/contrib/tcpdump/config.h.in
  head/contrib/tcpdump/configure
  head/contrib/tcpdump/tcpdump.c
  head/usr.sbin/tcpdump/tcpdump/config.h