我的数据库中包含大量已记录的IPV4消息。它用于获取以下查询：“给我所有来自MacAddress的消息......在这段时间内记录下来...... ......有... ......”
某些查询会导致大量记录的消息。因此，如果提出此类请求，我们决定制作一份PCAP文件。
“请创建一个包含来自您的所有已记录消息的PCAP文件 数据库......“
因此，根据请求，我的服务应该从数据库中获取所请求的数据（在页面中）并创建一个填充了从数据库中获取的数据的PCAP文件。以后的调用者可以向此文件请求只读OWIN流
该服务可以创建这样的文件。问题是它不被识别为正确的WireShark文件。
我看过Libcap File Format。每当我必须创建一个填充了LoggedMessages的文件时，我按如下方式填写二进制文件。
Wireshark在尝试阅读 Ethertype 时开始抱怨该文件。它说这是一个长度。 Definition of Ethernet Frame with EtherType
所以下面我展示了我的文件的开头。每个字节的十六进制格式+我对它的解释。之后来自wireshark的评论
创建的流以Global 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 ThisZone 0 sigFigs 0 snapLen 0000FFFF datalinkType 1
请注意，幻数首先是LSB，表示每个多字节数首先都是最低有效字节。所以2字节值0x1234将在内存中先有34然后12
之后，数据包应该来了。每次一个数据包头，然后是一个数据包数据
=== Packet header ===
09 89 58 5A C8 85 0B 00
6B 00 00 00 6B 00 00 00
时间戳：1515751689.7551446（usec precision） 保存的字节数（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
数据包数据由Mac Header，IPV4标头和一对0x41作为数据
组成=== Mac Header ===
Destination Mac: CF:31:59:D3:E7:98
Source Mac: 53:39:17:F0:A9:9C
Ether type: 0800
请注意，幻数显示每个多字节数都有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
Bacause 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被解释为长度
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。
我展示的维基百科中的以太网帧链接说：
EtherType字段长度为两个八位字节，可用于两个字节 不同的目的。 1500及以下的值意味着它被用于 以八位字节表示有效载荷的大小，而值为1536和 以上表示它用作EtherType，用于指示哪个 协议封装在帧的有效载荷中。
我的值，如果0x0800 = 2048.这当然高于1536
例如，EtherType值0x0800表示该帧 包含IPv4数据报。
如果值0x0800的值不正确？或者是我在其他地方的错误？
答案 0 :(得分：1)
看起来您的ethertype的字节顺序错误。它应该是：
=== Packet Data ===
CF 31 59 D3 E7 98 53 39 - 17 F0 A9 9C 08 00 XX XX