use*_*104 6 c# ip packets fragmentation sharppcap
我在 udf 上有超过 802.11 (wifi) 的各种类型流量的 pcap。由于 MTU，udp（或更准确地说是 IP）对 wifi 数据包进行分段。我目前正在使用 SharpPcap 读入并尝试访问 wifi 流量，并且遇到了必须手动重新组装 udp 数据包的问题。
我看到两个选项，我想检查它们是否可行，最好的解决方案，或者是否有我忽略的东西。最终，我将访问通过 UDP 传输给我的实时提要（相同格式，UDP 上的 wifi）（珍贵提到的那个），但出于测试目的，我必须使用 pcap。
我可以手动加载 pcap 文件，通过片段偏移和数据包 id 重新组装它，让状态机跟踪所有数据包。或者我可以尝试避免重新组装，（我认为套接字应该为我完成）加载 pcap 文件，输出到本地主机上的原始套接字，并侦听本地主机上的 UDP 套接字。我正在避免第一个，直到真正有必要（是吗？），而第二个似乎应该有效，但没有。我已经完成了所有设置，但是数据包仍然作为字节数组一一发送和接收 - 并且是碎片化的。
这可能是因为 IP 层仍然包含原始捕获的 IP dest 地址和端口（不同）？我尝试在发送之前更改这些，尽管我没有更改校验和，但它仍然是碎片化的。
遇到你的旧问题，寻找解决我自己的碎片整理问题的方法。
我理解的方式 - 由于您正在进行数据包捕获/ pcap 读取，因此您必须自己对 IP 数据包进行碎片整理。如果您是在网络上进行通信的实际应用程序，您操作系统的 IP 堆栈会为您完成此操作，您可以按原样读取数据。但是数据包捕获发生在此重组之前。您看到的是数据包在电线上（或在您的情况下在空中）传输。
理论上，碎片整理相对容易——具有相同 ID、源/目标 IP 地址和协议类型的 IP 数据包属于一起。第一个数据包的分段偏移量为 0，“更多片段”字段设置为 1。下一个数据包（如果有）将“更多片段”设置为 1，并且偏移量为非零。最终数据包将具有非零偏移量且未设置“更多片段”。
以某种方式摆脱重复项，按偏移量排序。每个数据包的有效载荷在 packet.fragmentationOffset*8 处进入最终缓冲区。使用此信息计算最终数据包大小也很简单。
更详尽的解释可以在这里找到：http : //en.wikipedia.org/wiki/IPv4#Reassembly
我知道您可能很久以前就已经离开了，但也许这可以帮助其他人搜索相同的信息。