When running TCPDump with the -w flag, we expect it to create a packet capture file. But in this case, despite showing capture statistics (17 packets captured), no actual file appears in the directory. Let's analyze what's happening.
The critical clues in the terminal output are:
4294966881 packets dropped by interface
0 packets dropped by kernel
This massive packet drop count (2^32 - 415) suggests a fundamental issue at the network interface level.
Several scenarios can cause this behavior:
- Insufficient permissions on the target directory
- Filesystem being mounted as read-only
- Network interface in promiscuous mode failure
- Resource limitations (inode exhaustion, disk space)
- Special characters in filename causing issues
Here's how to systematically diagnose the problem:
1. Verify Basic TCPDump Functionality
# Test with simplest possible capture
sudo tcpdump -w test.pcap -c 5 icmp
ping -c 5 localhost
2. Check Filesystem Permissions
# Verify directory permissions
ls -ld ~/pcaps
# Check filesystem mount options
mount | grep $(df ~/pcaps | tail -1 | awk '{print $1}')
3. Alternative Capture Methods
Try different capture approaches:
# Capture to stdout first
sudo tcpdump -s 0 -i eth0 port 6667 -w - | dd of=test.pcap
# Use different interface
sudo tcpdump -i lo -w loopback.pcap
For immediate resolution, try these commands:
# Option 1: Specify full path
sudo tcpdump -w /home/akraut/pcaps/pyhole.pcap -s 0 port 6667
# Option 2: Use different interface
sudo ip link set eth0 promisc on
sudo tcpdump -i eth0 -w pyhole.pcap
# Option 3: Alternative capture tool
sudo tshark -i eth0 -f "port 6667" -w pyhole.pcap
To avoid similar issues:
- Always use absolute paths for output files
- Verify interface status before capturing:
ip link show eth0 | grep PROMISC - Implement capture monitoring:
watch -n 1 'ls -lh ~/pcaps/ && df -h .'
For persistent issues, consider:
# Check system logs
journalctl -xe | grep tcpdump
dmesg | grep eth0
# Test with raw socket capture
python3 -c "import socket; s = socket.socket(socket.AF_PACKET, socket.SOCK_RAW); s.bind(('eth0', 0))"
When attempting to debug a Python IRC bot connection issue, I ran this standard TCPdump command:
sudo tcpdump -w pyhole -s 0 "port 6667"
The output showed successful packet capture:
17 packets captured
17 packets received by filter
0 packets dropped by kernel
Yet no PCAP file appeared in the directory despite the successful capture count.
Several technical factors could prevent TCPdump from writing PCAP files:
- Permission Issues: The directory might not be writable by the executing user
- Filesystem Constraints: The storage location could be mounted with noexec or other restrictive flags
- Buffer Problems: Insufficient buffer space for the capture
- Interface Errors: The massive "packets dropped by interface" count (4294966881) suggests fundamental issues
First, verify basic functionality with a simple test:
sudo tcpdump -w test.pcap -c 5 "icmp"
ping -c 5 localhost
If this fails, the problem is systemic. If it works, focus on the specific port 6667 case.
For the original scenario, try these modifications:
# 1. Specify full path with .pcap extension
sudo tcpdump -w /home/akraut/pcaps/pyhole.pcap -s 0 "port 6667"
# 2. Add interface specification explicitly
sudo tcpdump -i eth0 -w pyhole.pcap -s 0 "port 6667"
# 3. Check filesystem permissions
ls -ld ~/pcaps
df -h ~/pcaps
mount | grep $(df -h ~/pcaps | tail -1 | awk '{print $1}')
If TCPdump persists in failing, consider these Python-based alternatives:
from scapy.all import *
capture = sniff(filter="port 6667", count=20)
wrpcap("irc_capture.pcap", capture)
Or using tshark (Wireshark CLI):
tshark -i eth0 -f "port 6667" -w irc_capture.pcap
The massive interface drop count suggests:
- Network interface driver issues
- Hardware problems with the NIC
- Kernel-level packet filtering
Check interface statistics:
ethtool -S eth0 | grep drop
cat /proc/net/dev