我在玩tcpdump，并且注意到在OS X上，该-xx选项所做的操作与手册页中描述的有所不同。
该man页面显示以下内容：
-x When parsing and printing, in addition to printing the headers of each packet, print the data of each packet (minus its link level header) in hex.
The smaller of the entire packet or snaplen bytes will be printed. Note that this is the entire link-layer packet, so for link layers that pad
(e.g. Ethernet), the padding bytes will also be printed when the higher layer packet is shorter than the required padding.
-xx When parsing and printing, in addition to printing the headers of each packet, print the data of each packet, including its link level header, in
hex.
因此，如果我理解正确，-xx将不会显示以太网标题-x。在Linux上是这样。但是，在OS X上，-x向我显示了以太网标头，同时-xx在其前面放了一些多余的垃圾。如您所见，ethernet标头同时0886 3b60 1d3c 28cf e919 a36d 0800出现在-x和中-xx，并-xx出现在标有的行中0x0060，我不知道数据的含义。
这是tcpdump -xxOS X上的一个示例输出：
$ sudo tcpdump -Sxx -e -n port 33407
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on pktap, link-type PKTAP (Packet Tap), capture size 65535 bytes
11:10:11.177881 28:cf:e9:19:a3:6d > 08:86:3b:60:1d:3c, ethertype IPv4 (0x0800), length 78: 192.168.2.8.49923 > 23.239.3.247.33407: Flags [S], seq 1859065803, win 65535, options [mss 1460,nop,wscale 4,nop,nop,TS val 461417464 ecr 0,sackOK,eol], length 0
0x0000: 6c00 0000 0100 0000 0100 0000 656e 3000
0x0010: 0000 0000 0000 0000 0000 0000 0000 0000
0x0020: 0000 0000 0200 0000 0200 0000 0e00 0000
0x0030: 0000 0000 4f10 0100 7373 6800 0000 0000
0x0040: 0000 0000 0000 0000 0000 0000 0000 0000
0x0050: 0600 0000 ffff ffff 0000 0000 0000 0000
0x0060: 0000 0000 0000 0000 0000 0000 0886 3b60
0x0070: 1d3c 28cf e919 a36d 0800 4500 0040 66af
0x0080: 4000 4006 f572 c0a8 0208 17ef 03f7 c303
0x0090: 827f 6ecf 17cb 0000 0000 b002 ffff c4d1
0x00a0: 0000 0204 05b4 0103 0304 0101 080a 1b80
0x00b0: abf8 0000 0000 0402 0000
这是以下示例输出tcpdump -x：
$ sudo tcpdump -Sxvv -e -n port 33407
tcpdump: data link type PKTAP
tcpdump: listening on pktap, link-type PKTAP (Packet Tap), capture size 65535 bytes
11:10:48.727138 28:cf:e9:19:a3:6d > 08:86:3b:60:1d:3c, ethertype IPv4 (0x0800), length 102: (tos 0x10, ttl 64, id 25163, offset 0, flags [DF], proto TCP (6), length 88)
192.168.2.8.49923 > 23.239.3.247.33407: Flags [P.], cksum 0x1126 (correct), seq 1859067461:1859067497, ack 2295673726, win 8192, options [nop,nop,TS val 461454802 ecr 120336925], length 36
0x0000: 0886 3b60 1d3c 28cf e919 a36d 0800 4510
0x0010: 0058 624b 4000 4006 f9ae c0a8 0208 17ef
0x0020: 03f7 c303 827f 6ecf 1e45 88d5 337e 8018
0x0030: 2000 1126 0000 0101 080a 1b81 3dd2 072c
0x0040: 321d cdac 025c 44d7 8043 f45e da96 1c0d
0x0050: fbf3 de02 c17e 03ef 1014 d6da 506f c0c3
0x0060: a405 8cbd fcdc
这些数据包的开头没有以太网头。链接层标头类型为DLT_PKTAP，这是其标头的外观。
如果您在OS X-或Linux上以监视模式捕获，也会得到类似的惊喜！-因为数据包可能以radiotap头开头。
文档和tcpdump本身是在一个更简单的时代编写的，在我们拥有链接层之前，我们已经有了链接层，其中有大量的元数据（例如802.11和MAC层以下层的元数据）以及提供其他种类的机制的机制。元数据（例如PKTAP提供）。
Tcpdump可能应该区分元数据标头和链接层标头，默认为不显示元数据层，-xx而仅使用-xxx或类似的东西将其转储。您可能想在tcpdump问题跟踪器上提交有关此问题的错误。（可能应该进行一些讨论，因为这将是对tcpdump输出的不兼容更改。）
至于未获得DLT_PKTAP，请尝试使用-i标志在特定接口上进行捕获；否则，请执行以下步骤。优胜美地的tcpdump默认默认为同时在所有网络接口上捕获。在Linux上，这可以通过在“ any”接口上捕获来完成-它也没有提供以太网标头，但为您提供了Linux熟制的捕获头-但它没有默认为“ any”接口。在优胜美地上，默认情况下同时捕获所有接口。
本文收集自互联网，转载请注明来源。
如有侵权，请联系 [email protected] 删除。
我来说两句