一个险恶bug的深入分析(4)

　　这条if语句会进行索引判断，对比从内核中读取数据包使用的索引号是否和用户通知libpcap监控网络设备使用的索引号相同。如果索引号匹配失败，pcap_read_packet函数会直接返回，不再调用libpcap提供的回调函数。

　　这段代码是为了防止内核中可能出现的竞争情况，比如虽然已经创建了socket但还没有来得及绑定到一个特定设备上，这种情况下AF_PACKET会在调用socket和bind中间把所有的数据包存储到队列中。

　　然而，当数据包发向作为bond设备一部分的物理设备时这个检查会失败。

　　用户向libpcap请求对这个物理设备监控，但正如我们上面看到的，当有数据包到来时内核会用netif_receive_skb中的bond设备指针覆盖dev结构。这样就会造成bond设备的索引和物理设备的索引不一致。

　　这条if语句就是为什么发送的数据包在修改了内核以后仍然无法被类似tcpdump或者边界流量测量器捕获。

　　这个检查在从内核读取数据包的“新方法”中不存在，因为支持新mmap方法的内核不会产生上述代码需要防止的竞争条件。因此，把一个更新版本的libpcap链接到tcpdump上(内核已经过修改)就能看到发送给bond上物理设备的数据包。

　　这个检查在当前版本的libpcap上仍然存在。

　　总结

　　计算机能够正常运行真是个奇迹。

原文转自：http://www.ltesting.net