Libpcap 无线电窃听数据包

Question

我正在尝试在监控模式下捕获和处理 802.11 流量。我可以使用 tcpdump 捕获它，但无法使用 libpcap 处理它。我需要将所有数据包传递给深度数据包检查方法，该方法对于以太网数据包非常有效。所以我的问题是我可以打开转储文件，读取无线电接头标头并检查它的长度是否与wireshark显示的长度相同。之后我尝试读取以太类型并得到一些未知的值。我找不到有关返回 0x4500 的任何信息，所以我认为我应该将指针移到其他地方，但我不熟悉这种类型的编程，我问是否有人可以检查我的 cap 文件和代码以便告诉我怎么了？我的观点是了解数据和标头位于数据包中的位置，以便将数据发送到 DPI。

附注今天我坐在这里解决这个问题 10 个小时，昨天大约 14 个小时。我已经做了很多谷歌搜索。请帮我解决一下。

我的服务器上的文件：

帽： 点击

代码： 点击

Answer 1

LLC 标头：

struct snap_llc_header           
{
    u_int8_t    dsap; 
    u_int8_t    ssap;
    u_int8_t    ctl;
    u_int16_t   org; 
    u_int8_t    org2;
    u_int16_t   ether_type; /* ethernet type */              
};

是错误的。默认情况下，C 编译器将尝试在适当的边界上正确对齐长度超过 1 字节的整数和浮点值；这意味着

u_int16_t

值将在 2 字节边界上对齐，并添加填充。

因此，结构实际上看起来像：

struct snap_llc_header           
{
    u_int8_t    dsap; 
    u_int8_t    ssap;
    u_int8_t    ctl;
    u_int8_t    pad1;
    u_int16_t   org; 
    u_int8_t    org2;
    u_int8_t    pad2;
    u_int16_t   ether_type; /* ethernet type */              
};

它将比实际的 802.2 LLC+SNAP 标头长 2 个字节。

快速而肮脏的修复方法仅适用于 GCC 和 GCC 兼容编译器，即将结构标记为“打包”，以便值不会对齐：

struct snap_llc_header           
{
    u_int8_t    dsap; 
    u_int8_t    ssap;
    u_int8_t    ctl;
    u_int8_t    pad1;
    u_int16_t   org; 
    u_int8_t    org2;
    u_int8_t    pad2;
    u_int16_t   ether_type; /* ethernet type */              
} __attribute__((packed));

如果您想在不支持GCC

__attribute__((packed))

扩展的编译器上进行这项工作，您将需要做更多的工作。

（另请注意，您的代码假设它在小端机器上运行 - 如果您在个人计算机上运行它，则可能是这样，但如果您在非 x86 和非 ARM 上运行它它还假设它可以安全地引用未对齐的数据 - 如果您在 SPARC 机器以外的其他机器上运行它，它可能可以，但如果您在 SPARC 机器上运行它，它不能。解决这个问题还需要更多的工作。）

（另一个潜在问题是，如果从 Atheros 网络设备捕获 802.11 帧，则 802.11 标头和有效负载之间可能存在一些填充；请参阅“帧在 802.11 标头和有效负载之间有填充（至 32 位边界）” “ radiotap 标志字段中的标志。不幸的是，这将要求您解析 radiotap 标头。）

（如果您想处理带有 SNAP 标头的数据帧以外的数据包，则需要检查 DSAP 和 SSAP，如果它们不都是 0xAA，则处理它们不使用 3 字节 OUI 和SNAP 标头的 2 字节协议 ID。如果它们都是都是 0xAA，请注意，2 字节协议 ID 是以太网类型仅如果 OUI 的所有三个字节都为零。）