tcpdump抓包丢失问题

1
近日用tcpdump抓包，发现有大量的丢包出现("packets dropped by kernel"),
如下：
tcpdump -i eth0 dst port 1234 and udp -s 2048 -X -tt >a.pack
264 packets captured
3043 packets received by filter
2706 packets dropped by kernel
丢包原因：
经过google以及分析，造成这种丢包的原因是由于libcap抓到包后，tcpdump 上层没有及时的取出，导致libcap缓冲区溢出，从而覆盖了未处理包，此处即显示为dropped by kernel，注意，这里的kernel并不是说是被linux内核抛弃的，而是被tcpdump的内核，即libcap抛弃掉的，上层监听到
1234端口的server可以正常的获取数据。

解决方法：
根据以上分析，可以通过改善tcpdump上层的处理效率来减少丢包率，下面的几步根据需要选用，每一步都能减少一定的丢包率
1.最小化抓取过滤范围，即通过指定网卡，端口，包流向，包大小减少包数量
2. 添加-n参数，禁止反向域名解析
tcpdump -i eth0 dst port 1234 and udp -s 2048 -n -X -tt >a.pack
大多数情况这样就可以解决了
可以通过改善tcpdump上层的处理效率来减少丢包率
3. 将数据包输出到cap文件
tcpdump -i eth0 dst port 1234 and udp -s 2048 -n -X -tt -w a.cap
用了这一步，基本上所有的网络server都可以搞定了
4. 用sysctl修改SO_REVBUF参数，增加libcap缓冲区长度
这一步是绝招了，由于设计内核参数修改，尽量不要使用，要用了不行，那就没办法了 ^_^
2
通过tcpdump抓包时，结束后tcpdump会给出如下统计信息：
1552 packets captured
1586 packets received by filter
34 packets dropped by kernel
其中“captured”的计数指的是应用层捕获到的数据，“received by filter”和“dropped by kernel”的计数由内核维护，应用层通过getsockopt来获取。

收到一个包，“received by filter”会加1，如果sock的接收buffer被填满时，则把这个数据包丢弃，将“dropped by kernel”加1。

if (atomic_read(&sk->sk_rmem_alloc) + skb->truesize >= (unsigned)sk->sk_rcvbuf){
spin_lock(&sk->sk_receive_queue.lock);
po->stats.tp_drops++;
spin_unlock(&sk->sk_receive_queue.lock);
}
通过调节/proc/sys/net/core/rmem_default和/proc/sys/net/core/rmem_max能够改变sk_rcvbuf的大小。

正常“captured”加上“dropped by kernel”应该等于“received by filter”的大小，有的时候出现不等的情况应该是还有一些数据包在sk_rcvbuf中，还没有被应用层收到的原因。

tcpdump做pcap丢包
一直用tcpdump做pcap，忽然从某一天开始做的pcap稍微大一点，就开始丢包，给出的哦信息大概是”xxxx packets dropped by kernel”，可能出问题的也就是vmware/linux kernel/libpcap/tcpdump，这里边的每一个我都经常升级，太复杂了，不知道是哪个引入的问题。

于是就一直得过且过，大文件就凑合着在windows上用wireshark。

今天实在是想搞清楚怎么回事，就仔细看了一下。

仔细想想，首先排除vmware的问题，因为所有网络程序都正常工作，没有理由vmware或者tcp/ip本身出问题。

所以大概就只是libpcap和 tcpdump的问题。

搜到一篇文章，大概的意思就是是因为内核skb的buffer太小，tcpdump还没有来得及取下一个包，这个就已经被内核里边来的下边的包给覆盖掉了。

试着改了一下还是不行，那看来不是内核缓存的问题，应该就是libpcap或者tcpdump 取包比较慢。

起了GUI用wireshark抓了一下，NND也是正常的，那就只可能是tcpdump的问题了。

仔细看了一下我的tcpdump参数，一般都是”tcpdump port 80 -w aaa.pcap -s 0″，唯一不同的就是”-s 0″，之所以用这个参数，是因为好久以前tcpdump 如果加上”-w”，默认不记录数据，只记录包头，加上”-s 0″，那就是每个包最大记录65535的数据，不过现在默认也改成了65535，所以这个参数有没有都没什么区别。

剩下的就是”tcpdump port 80 -w aaa.pcap”，完全正常，彻底抓狂了。

抓狂中无聊试了一下”-s 2000″，哇，一下不丢包了。

反正tcp MTU是1500，这个数字也没啥问题。

问题解决，看来估计是tcpdump某一个memcpy或者类似的内存操作的参数是用最大65535，而不是用实际抓到包的大小，所以速度慢下来来不及去取内核缓存的数据。

Tcpdump丢包问题
The kernel has a buffer for packets to be delivered to tcpdump. If tcpdump doesn't respond quickly enough, the kernel will overwrite old packets with new ones.
使用tcpdump抓包时，内核分配缓冲区存放向tcpdump传送的数据包，如果tcpdump处理的不够快，新到达的包会覆盖缓冲区中较早的包，即出现dropped 丢包的情况。

解决方法：
1. 增大系统缓冲区大小 bpfbufsize
2. 避免tcpdump进行dns解析，使用tcpdump -n参数。

尽量减少tcpdump的工作量，其他的参数如-nn等可参考。

Pf_ring
PF_RING包括一个linux内核模块和该模块在用户层的库, 这个库符合libpcap标准。

你需要将应用程序在链接时链接到这个库，才能发挥作用。

简单说，千兆抓包使用
普通linux性能上是不够的，必须使用专用的抓包库。

pf_ring，通过修改系统内核提高基于Linux和libcap的抓包效率
官方网站：
pf_ring 使用心得
[i=s] 本帖最后由pdsxw123 于2010-08-09 20:54 编辑[/i]
在论坛里已经有人把pf_ring的原理大概讲述了，在此不再累述。

大家如果想了解或者学习的话，可以直接从官方网站上下载，[url][/url]
最新版本为4.4.0，目录为：
drivers\
drivers\broadcom
drivers\intel
drivers\myricom
kernel/ Kernel related patches
userland/ User space code
userland/lib/ User space library used to manpulate PF_RING
userland/libpcap-XXX-ring/ Libpcap enhanced with PF_RING support
userland/examples/ P(acket)count application (use it for your tests)
1.编译安装之前需要卸载网卡驱动,卸载之前可以使用ethtool -i ethx 查看当前网卡类型和驱动版本。

2.cd 到kernel下，make,然后sudo make install
3.cd 到userland/lib/下，make，然后sudo make install
4.如果需要使用libcap抓包做分析，请先卸载之前装的libcap，然后cd 到userland/libpcap-XXX-ring/
./configure ---> make -----> sudo make install
5.cd 到drivers下，根据ethtool -i ethx 命令看到的网卡驱动和类型，进入指定的目录。

假设你看到如下信息：
driver: e1000e
version: 1.0.2-k2
firmware-version: 0.4-3
bus-info: 0000:00:19.0
cd 到drivers\intel\e1000e-1.0.15下，
make ----> sudo make install
6.开始安装驱动，cd 到lib/modules/xxx/kernel/net,可以看到有个pf_ring的目录,cd 到pf_ring 下
使用命令sudo insmod pf_ring.ko transparent_mode=1
7.安装网卡驱动，cd到目录lib/modules/xxx/kernel/driver/net下，
使用命令sudo insmod e1000e.ko
安装完毕，现在我们可以使用命令dmesg 查看驱动是否安装成功，如果成功的话，可以看到
[PF RING].................. ............................... 信息
pf_ring 会安装一个类型为27的协议簇，可以使用sock(PF_RING,SOCK_RAW,0)打开一个socket
使用libcap的朋友不需要修改程序，需要重新编译，链接的时候请加上libpfring.so.
最近在使用的时候，发现pf_ring只做了intel e1000e的DNA的实现，局限性太大了。

现在的网卡类型，特别是服务器上的基本上是HP、broadcom等，如果只是使用PF_RING 抓包的话，经过简单测试后暂时发现与用libcap没什么区别。

并且pf_ring定制的libpcap没有缓存功能
pf_ring有两种工作模式，可以使用transparent_mode设置，0：表示与libpcap什么区别，pf_ring.ko注册个回调函数到网卡驱动，经过此网卡的包会复制一份。

如果设置为1，表示打算使用dna技术，这一般是使用pf_ring的目的，也就是打算使用此特性，使网卡收到的包，不经过kernel的捣腾，由pf_ring直接mmap到用户空间。

也就是实现了zero copy。

大大的提升了抓包的性能（官网上说的），本人还没有验证。

在pf_ring.ko中只是实现了intel 的独立网卡的dna处理。

在非intel的独立网卡，如果非要使用的话，transparent_mode设置0，在这种情况下，建议直接使用libpcap。