4 ms·

Using something like "time tcpdump -c 1000 -w file.pcap ..." which stops after 1000 packets is always a good idea. It helps catch a too greedy BPF expression (P

Using something like "time tcpdump -c 1000 -w file.pcap ..." which stops after 1000 packets is always a good idea. It helps catch a too greedy BPF expression (PCAP filter), before using to many resources. Also always output to a file first, and then you can check the output afterwards with "tcpdump -nr file.pcap | less".

drewg123 11y ago
The -c option is indeed a good idea. However, one of the worst things that tcpdump does is to put the NIC into promisc mode. On a physical NIC, this can be VERY expensive and may involve bouncing the link (behind your back) and dropping packets. At the very least, it can wreak havoc with steering filters on some NICs. To prevent this, use the -p option to prevent tcpdump from putting the NIC into promisc mode. Another issue with tcpdump on an endstation is caused by stateless offloads like checksum offload and offloads like TSO on the send side, and GRO / LRO on the receive side. Because the BPF filters are applied between the network stack and the device driver, you may noticed tcpdump / wireshark complaining about bad checksums on transmit -- this is likely due to checksum offload. And you may see gigantic (way larger than MTU) sized frames. This is due to GRO/LRO on receive, and TSO on transmit. You can disable stateless offloads (ethtool -K on linux, ifconfig on bsd), but that will slow the entire system down.