记录一次奇怪的tcpdump

tmpdump在我们日常的工作中经常使用，先介绍一下基本使用

tcpdump -i eth0 icmp

-i 是指定网卡， icmp是协议。
还有一些其他常用参数譬如
-b在数据-链路层上选择协议，包括ip、arp、rarp、ipx都是这一层的。tcpdump -b arp 将只显示网络中的arp即地址转换协议信息；

-l使标准输出变为缓冲行形式,如tcpdump -l >tcpcap.txt将得到的数据存入tcpcap.txt文件中；

-n不进行IP地址到主机名的转换；

-v输出一个稍微详细的信息，例如在ip包中可以包括ttl和服务类型的信息；

-vv输出详细的报文信息；
再举例一些常用的，

抓取包含特点主机的数据包

tcpdump -i eth0 -vnn host 10.10.10.10
如果是源地址 src host 
如果是目的地址 dst host
还可以通过 and  or 组合多个条件

特定端口

tcpdump -i eth0 -vnn port 22

特定协议

tcpdump -i eth0 -vnn icmp/udp/ip/arp

保存或者读取文件

tcpdump –i eth0 -vnn -w  /tmp/fil1 -c 100
tcpdump –i eth0 -vnn -r  /tmp/fil1 （ 筛选主机追加：host  10.10.10.10）

介绍完tcpdump的基本使用后，我们回到今天抓包的奇怪现象，在抓包的时候回会出现，我在抓包DNS时候发现

sudo tcpdump -i eth0 -vvv -nn udp dst port 53
 tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
 17:04:48.145904 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 61)
 10.0.0.2.56497 > 10.0.0.1.53: [bad udp cksum 0x8f54 -> 0xb8fc!] 30234+ AAAA? www.twitter.com. (33)
 17:04:48.145925 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 61)
 10.0.0.2.56497 > 10.0.0.1.53: [bad udp cksum 0x224d -> 0x2604!] 30234+ AAAA? www.twitter.com. (33)

虽然域名能解析但出现了一些bad udp之类的数据包，很奇怪，后来深入了解了一下网卡的checksum offloading 机制，它是负责计算需要发送或者接收到的TCP/UDP消息的校验和，从而节省CPU的计算开销的一种机制，CheckSum Offload实际上是将传输层的一部分工作交给了硬件完成，以节约系统的CPU资源。微软的测试表明它可以最多节约30%的CPU资源。
对于Tx，设置Checksum Offload有效之后，传输层将随机填充TCP校验和，因此在本机上抓取的数据包是Bad CheckSum。然后，网卡会自动计算正确的校验码然后发送，因此对方收到的仍然是正确的TCP/UDP包。
对于Rx，设置Checksum Offload有效之后，网卡在接收数据时，会填充一个NDIS_TCP_IP_CHECKSUM_PACKET_INFO 结构并设置标志位；如果由于某种原因失败，则不设置标志位，由TCP/IP协议栈来完成数据校验。

可以查看一下

sudo ethtool -k eth0 | grep on
 rx-checksumming: on
 tx-checksumming: on
 scatter-gather: on
 generic-segmentation-offload: on
 generic-receive-offload: on
 rx-vlan-offload: on
 tx-vlan-offload: on

关闭后再测试一下

sudo ethtool -K eth0 tx off rx off

udo tcpdump -i eth0 -vvv -nn udp dst port 53
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
17:06:09.355411 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 57)
10.0.0.2.18964 > 10.0.0.1.53: [udp sum ok] 292+ AAAA? twitter.com. (29)
17:06:09.355431 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 57)
10.0.0.2.18964 > 10.0.0.1.53: [udp sum ok] 292+ AAAA? twitter.com. (29)

就没有发现这个问题了。当然这个功能还是需要开启，毕竟通过网络分担cpu的部分计算是非常好的设计