废话比较多，如果你没有遇到同样的问题，就直接忽略吧。

一直用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，而不是用实际抓到包的大小，所以速度慢下来来不及去取内核缓存的数据。