从数据库中的值创建 PCAP 文件
Create PCAP file from values in a database
我有一个数据库，里面装满了很多记录的 IPV4 消息。它用于获取如下查询："give me all messages from MacAddress ... that were logged in the period ... to ... that have ..."
一些查询会产生大量的记录消息。因此，如果提出这样的要求，我们决定制作一个 PCAP 文件。
"Please create a PCAP file containing all logged messages from your
database that ..."
因此，根据请求，我的服务应该从数据库中获取请求的数据（以页面为单位）并创建一个 PCAP 文件，其中填充了从数据库中获取的数据。以后的调用者可以请求一个 read-only OWIN 流到这个文件
服务可以创建这样的文件。问题是它没有被识别为正确的 WireShark 文件。
我读过 Libcap File Format。每当我必须创建一个充满 LoggedMessages 的文件时，我都会按如下方式填充一个二进制文件。
- 全球Header
- 每条记录的消息：
- 一包header
- 数据包数据：
- 以太网帧：目标 Mac、源 Mac、EtherType (0x800)
- IPV4 header
- 记录的数据
Wireshark 在尝试读取 Ethertype 时开始抱怨该文件。它说这是一个长度。 Definition of Ethernet Frame with EtherType
所以下面我显示了我的文件的开头。每字节十六进制格式+我对它的解释。之后来自 wireshark
的评论
创建的流以全局 Header 开头：一个 32 字节的结构。首先是十六进制值，然后是解释：
=== Global Header ====
D4 C3 B2 A1 02 00 04 00
00 00 00 00 00 00 00 00
FF FF 00 00 01 00 00 00
幻数A1B2C3D4（原始时间精度）
版本：2 - 4
这个区域 0
信号图 0
snapLen 0000FFFF
数据link类型 1
请注意，幻数的 LSB 在前，表示每个 multi-byte 数字的最低有效字节在前。 因此 2 字节值 0x1234 将内存中先有 34，然后有 12。
之后应该会收到数据包。每次一个数据包Header，然后是一个数据包数据
=== Packet header ===
09 89 58 5A C8 85 0B 00
6B 00 00 00 6B 00 00 00
时间戳：1515751689.7551446（秒精度）
保存的字节数 (incl_len) 107 字节 (0x006b)
实际数据包长度 (orig_len) 107 字节 (0x006b)
=== Packet Data ===
CF 31 59 D3 E7 98 53 39 - 17 F0 A9 9C 00 08 45 00
5D 00 00 00 00 00 FF 00 - E0 0D 8A 84 77 44 E0 2B
9C FB 4D 43 D5 8A 00 00 - 00 00 41 41 41 41 41 41
41 41 41 41 41 41 41 41 - 41 41 41 41 41 41 41 41
// etc, until total 107 bytes
包数据由MacHeader、IPV4header和一对0x41作为数据组成
=== Mac Header ===
Destination Mac: CF:31:59:D3:E7:98
Source Mac: 53:39:17:F0:A9:9C
Ether type: 0800
请注意，幻数显示每个 multi-byte 数字的 LSB 在前，因此两个字节 00 08 将具有 16 位含义 0x0800
如果您查看我在下面显示的 PCAP 文件解释，那么问题就从这里开始：以太类型未被解释为以太类型，而是长度。
在其中一个答案中的评论之后，我尝试将两字节以太类型从 00 08 反转为 08 00（MSB 在前），但这使问题变得更糟。
=== IPV4 header ===
- 45 00 5D 00
- 00 00 00 00
- FF 00 E0 0D
- 8A 84 77 44
- E0 2B 9C FB
Specification of the IPV4 header structure
DWORD 0
- bits 00..04: version; bits 04..07 IP Header Length: 04 05
- bits 08..13 DSCP; bits 14..15 ECN: 00
- bits 16..31 Total Length (header + Payload): 93 (005D)
DWORD 1
- bits 00..15 Identification: 0000
- bits 16..18 Flags; bits 19..31 offset: 0000
DWORD 2
- bits 00..07 Time to Live FF
- bits 08..15 Protocol; used protocol 00
- bits 16..31 Header Checksum 3552 (0DE0)
DWORD 3 and 4
Source IP: 138.132.119.68
Destination IP: 224.43.156.251
因为 wireshark 抱怨校验和，我验证如下：
Verify checksum:
Header: 0045 005D 0000 0000 00FF 0DE0 848A 4477 2BE0 FB9C
69 + 93 + 0 + 0 + 255 + 3552 + 33930 + 17527 + 11232 + 64412 = 131070 (01FFFE)
0001 + FFFE = FFFF
1's complement: 0000 (checksum ok)
这就是 WireShark（2.4.4 版）的作用：
以下看似正常：
Frame 1: 107 bytes on wire (856 bits), 107 bytes captured (856 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 12, 2018 11:08:09.755144000 W. Europe Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1515751689.755144000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 107 bytes (856 bits)
Capture Length: 107 bytes (856 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:llc:data]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String [truncated]: eth.fcs.status=="Bad" ||
ip.checksum.status=="Bad" || tcp.checksum.status=="Bad" ||
udp.checksum.status=="Bad" || sctp.checksum.status=="Bad" ||
mstp.checksum.status=="Bad" || cdp.checksum.status=="Bad" ||]
第一个问题来了：EtherType被解释为Length
IEEE 802.3 Ethernet
Destination: cf:31:59:d3:e7:98 (cf:31:59:d3:e7:98)
Source: 53:39:17:f0:a9:9c (53:39:17:f0:a9:9c)
Length: 8
Padding: ff00e00d8a847744e02b9cfb4d43d58a0000000041414141...
Trailer: 414141414141414141414141414141414141414141414141...
Frame check sequence: 0x41414141 incorrect, should be 0xe19cae36
[FCS Status: Bad]
在长度（我指的是 EtherType）之后有很多填充，而不是对我的 5 个 DWORD 的解释。
我展示的维基百科中以太网帧的 link 说：
The EtherType field is two octets long and it can be used for two
different purposes. Values of 1500 and below mean that it is used to
indicate the size of the payload in octets, while values of 1536 and
above indicate that it is used as an EtherType, to indicate which
protocol is encapsulated in the payload of the frame.
我的值如果0x0800 = 2048。这肯定在1536以上
For example, an EtherType value of 0x0800 signals that the frame
contains an IPv4 datagram.
如果值 0x0800 是不正确的值？还是我的错误在其他地方？
看起来您的以太网类型的字节顺序有误。应该是：
=== Packet Data ===
CF 31 59 D3 E7 98 53 39 - 17 F0 A9 9C 08 00 XX XX
我有一个数据库，里面装满了很多记录的 IPV4 消息。它用于获取如下查询："give me all messages from MacAddress ... that were logged in the period ... to ... that have ..."
一些查询会产生大量的记录消息。因此，如果提出这样的要求，我们决定制作一个 PCAP 文件。
"Please create a PCAP file containing all logged messages from your database that ..."
因此，根据请求，我的服务应该从数据库中获取请求的数据（以页面为单位）并创建一个 PCAP 文件，其中填充了从数据库中获取的数据。以后的调用者可以请求一个 read-only OWIN 流到这个文件
服务可以创建这样的文件。问题是它没有被识别为正确的 WireShark 文件。
我读过 Libcap File Format。每当我必须创建一个充满 LoggedMessages 的文件时，我都会按如下方式填充一个二进制文件。
- 全球Header
- 每条记录的消息：
- 一包header
- 数据包数据：
- 以太网帧：目标 Mac、源 Mac、EtherType (0x800)
- IPV4 header
- 记录的数据
Wireshark 在尝试读取 Ethertype 时开始抱怨该文件。它说这是一个长度。 Definition of Ethernet Frame with EtherType
所以下面我显示了我的文件的开头。每字节十六进制格式+我对它的解释。之后来自 wireshark
的评论创建的流以全局 Header 开头：一个 32 字节的结构。首先是十六进制值，然后是解释：
=== Global Header ====
D4 C3 B2 A1 02 00 04 00
00 00 00 00 00 00 00 00
FF FF 00 00 01 00 00 00
幻数A1B2C3D4（原始时间精度） 版本：2 - 4 这个区域 0 信号图 0 snapLen 0000FFFF 数据link类型 1
请注意，幻数的 LSB 在前，表示每个 multi-byte 数字的最低有效字节在前。 因此 2 字节值 0x1234 将内存中先有 34，然后有 12。
之后应该会收到数据包。每次一个数据包Header，然后是一个数据包数据
=== Packet header ===
09 89 58 5A C8 85 0B 00
6B 00 00 00 6B 00 00 00
时间戳：1515751689.7551446（秒精度） 保存的字节数 (incl_len) 107 字节 (0x006b) 实际数据包长度 (orig_len) 107 字节 (0x006b)
=== Packet Data ===
CF 31 59 D3 E7 98 53 39 - 17 F0 A9 9C 00 08 45 00
5D 00 00 00 00 00 FF 00 - E0 0D 8A 84 77 44 E0 2B
9C FB 4D 43 D5 8A 00 00 - 00 00 41 41 41 41 41 41
41 41 41 41 41 41 41 41 - 41 41 41 41 41 41 41 41
// etc, until total 107 bytes
包数据由MacHeader、IPV4header和一对0x41作为数据组成
=== Mac Header ===
Destination Mac: CF:31:59:D3:E7:98
Source Mac: 53:39:17:F0:A9:9C
Ether type: 0800
请注意，幻数显示每个 multi-byte 数字的 LSB 在前，因此两个字节 00 08 将具有 16 位含义 0x0800
如果您查看我在下面显示的 PCAP 文件解释，那么问题就从这里开始：以太类型未被解释为以太类型，而是长度。
在其中一个答案中的评论之后，我尝试将两字节以太类型从 00 08 反转为 08 00（MSB 在前），但这使问题变得更糟。
=== IPV4 header ===
- 45 00 5D 00
- 00 00 00 00
- FF 00 E0 0D
- 8A 84 77 44
- E0 2B 9C FB
Specification of the IPV4 header structure
DWORD 0
- bits 00..04: version; bits 04..07 IP Header Length: 04 05
- bits 08..13 DSCP; bits 14..15 ECN: 00
- bits 16..31 Total Length (header + Payload): 93 (005D)
DWORD 1
- bits 00..15 Identification: 0000
- bits 16..18 Flags; bits 19..31 offset: 0000
DWORD 2
- bits 00..07 Time to Live FF
- bits 08..15 Protocol; used protocol 00
- bits 16..31 Header Checksum 3552 (0DE0)
DWORD 3 and 4
Source IP: 138.132.119.68
Destination IP: 224.43.156.251
因为 wireshark 抱怨校验和，我验证如下：
Verify checksum:
Header: 0045 005D 0000 0000 00FF 0DE0 848A 4477 2BE0 FB9C
69 + 93 + 0 + 0 + 255 + 3552 + 33930 + 17527 + 11232 + 64412 = 131070 (01FFFE)
0001 + FFFE = FFFF
1's complement: 0000 (checksum ok)
这就是 WireShark（2.4.4 版）的作用：
以下看似正常：
Frame 1: 107 bytes on wire (856 bits), 107 bytes captured (856 bits)
Encapsulation type: Ethernet (1)
Arrival Time: Jan 12, 2018 11:08:09.755144000 W. Europe Standard Time
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1515751689.755144000 seconds
[Time delta from previous captured frame: 0.000000000 seconds]
[Time delta from previous displayed frame: 0.000000000 seconds]
[Time since reference or first frame: 0.000000000 seconds]
Frame Number: 1
Frame Length: 107 bytes (856 bits)
Capture Length: 107 bytes (856 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:llc:data]
[Coloring Rule Name: Checksum Errors]
[Coloring Rule String [truncated]: eth.fcs.status=="Bad" ||
ip.checksum.status=="Bad" || tcp.checksum.status=="Bad" ||
udp.checksum.status=="Bad" || sctp.checksum.status=="Bad" ||
mstp.checksum.status=="Bad" || cdp.checksum.status=="Bad" ||]
第一个问题来了：EtherType被解释为Length
IEEE 802.3 Ethernet
Destination: cf:31:59:d3:e7:98 (cf:31:59:d3:e7:98)
Source: 53:39:17:f0:a9:9c (53:39:17:f0:a9:9c)
Length: 8
Padding: ff00e00d8a847744e02b9cfb4d43d58a0000000041414141...
Trailer: 414141414141414141414141414141414141414141414141...
Frame check sequence: 0x41414141 incorrect, should be 0xe19cae36
[FCS Status: Bad]
在长度（我指的是 EtherType）之后有很多填充，而不是对我的 5 个 DWORD 的解释。
我展示的维基百科中以太网帧的 link 说：
The EtherType field is two octets long and it can be used for two different purposes. Values of 1500 and below mean that it is used to indicate the size of the payload in octets, while values of 1536 and above indicate that it is used as an EtherType, to indicate which protocol is encapsulated in the payload of the frame.
我的值如果0x0800 = 2048。这肯定在1536以上
For example, an EtherType value of 0x0800 signals that the frame contains an IPv4 datagram.
如果值 0x0800 是不正确的值？还是我的错误在其他地方？
看起来您的以太网类型的字节顺序有误。应该是：
=== Packet Data ===
CF 31 59 D3 E7 98 53 39 - 17 F0 A9 9C 08 00 XX XX