我正在玩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
在它前面放一些额外的垃圾。如您所见,以太网报头0886 3b60 1d3c 28cf e919 a36d 0800
出现在 和 中-x
,-xx
并且在 中-xx
它出现在 标记的行中0x0060
,我不知道它之前的数据是什么意思。
tcpdump -xx
以下是OS 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
答案1
这些数据包的开头没有以太网报头。链路层报头类型为 DLT_PKTAP,并且它的标题是这样的。
如果你在 OS X 的监控模式下拍摄,你也会得到类似的惊喜 -或 Linux!- 因为数据包可能以radiotap 标题。
文档和 tcpdump 本身都是在一个比较简单的时代编写的,在我们拥有链路层之前,链路层有理由拥有大量元数据(例如 802.11 和 MAC 层以下层的元数据)和提供其他类型元数据的机制(例如 PKTAP 提供的)。
Tcpdump 或许应该区分元数据报头和链路层报头,默认不显示元数据层,-xx
只转储它们-xxx
,或者诸如此类。您可能想在tcpdump 问题追踪器(可能应该有一些讨论,因为这会对 tcpdump 的输出产生不兼容的改变。)
至于不是获取 DLT_PKTAP,尝试使用标志在特定接口上进行捕获-i
;Yosemite 中的 tcpdump 默认在全部网络接口。在 Linux 上,可以通过在“任何”接口上进行捕获来实现 -还它不提供以太网标头,而是提供Linux 熟捕获头- 但事实并非如此默认到“任何”接口;在 Yosemite 上,它默认同时在所有接口上进行捕获。