【问题标题】:Reassembling fragmented UDP packet重组分片的 UDP 数据包
【发布时间】:2013-09-02 13:38:32
【问题描述】:

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

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

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

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

【问题讨论】:

    标签: c# ip packets fragmentation sharppcap


    【解决方案1】:

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

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

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

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

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

    我知道您可能很久以前就开始了,但也许这可以帮助其他人搜索相同的信息。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2018-04-20
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2012-09-06
      • 2021-09-22
      • 2018-06-22
      • 1970-01-01
      相关资源
      最近更新 更多