6

我有一个通过 udf 的 802.11 (wifi) 上各种类型的流量的 pcap。由于 MTU，udp（或更准确地说是 IP）对 wifi 数据包进行分段。我目前正在使用 SharpPcap 读取并尝试访问 wifi 流量，并且遇到了必须手动重新组装 udp 数据包的问题。

我看到两个选项，我想检查它们是否可行，最好的解决方案，或者是否有我忽略的东西。最终，我将访问通过 UDP 流式传输给我的实时提要（相同格式，通过 UDP 的 wifi）（被珍贵提及的那个），但出于测试目的，我必须使用 pcaps。

我可以手动加载 pcap 文件，通过片段偏移量和数据包 ID 重新组装它，让状态机跟踪所有数据包。或者我可以尝试避免重新组装，（我认为套接字应该为我做）加载 pcap 文件，输出到本地主机上的原始套接字，并监听本地主机上的 UDP 套接字。在真正有必要之前，我会避免第一个（是吗？），第二个似乎应该有效，但没有。我已经完成了所有设置，但是数据包仍然以字节数组的形式一一发送和接收 - 并且是碎片化的。

这可能是因为 IP 层仍然包含原始捕获的 IP 目标地址和端口（这是不同的）？我尝试在发送之前更改这些，虽然我没有更改校验和，但它仍然是碎片化的。

4

1 回答 1

8

遇到你的老问题，寻找我自己的碎片整理问题的解决方案。

我理解它的方式 - 因为您正在执行数据包捕获/pcap 读取，您必须自己对 IP 数据包进行碎片整理。如果您是在网络上通信的实际应用程序，您的操作系统的 IP 堆栈会为您执行此操作，您可以按原样读取数据。但是数据包捕获发生在此重组之前。您所看到的是数据包在电线上（或在您的情况下是在空中）传输的数据包。

碎片整理在理论上相对容易——具有相同 ID、源/目标 IP 地址和协议类型的 IP 数据包属于同一类。第一个数据包的分片偏移量为 0，“更多片段”字段设置为 1。下一个数据包（如果有）将“更多片段”设置为 1，并且偏移量为非零。最终数据包将具有非零偏移量并且没有设置“更多片段”。

以某种方式摆脱重复项，按偏移量排序。每个数据包的有效负载在 packet.fragmentationOffset*8 处进入最终缓冲区。使用此信息计算最终数据包大小也很简单。

更详尽的解释可以在这里找到： http ://en.wikipedia.org/wiki/IPv4#Reassembly

我知道您可能很久以前就已经继续前进了，但这也许可以帮助其他人搜索相同的信息。

于 2014-03-15T08:46:55.037 回答