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