Question

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

P.S。我今天坐在这里这个问题10小时，昨天大约14点。我做了很多谷歌搜索。请帮帮我。

我服务器上的文件：

帽： click

代码： click

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兼容的编译器，是将结构标记为＆＃34; packed＆＃34;，以便不会对齐这些值：

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机器上运行它，它就不能。修复这个问题还需要更多工作。）

（另一个潜在的问题是，如果802.11帧是从Atheros网络设备捕获的，那么802.11报头和有效载荷之间可能会有一些填充;请参阅＆＃34;帧在802.11报头和有效负载之间有填充（到32位边界）＆＃34;标记在the radiotap flags field。遗憾的是，这将要求您解析radiotap标头。）

（如果你想处理数据包其他而不是带有SNAP标头的数据帧，你需要检查DSAP和SSAP，如果它们不是0xAA，则处理它们没有 3字节OUI和SNAP头的2字节协议ID。如果都是0xAA，请注意2字节协议ID是以太网类型<如果OUI的所有三个字节都为零，则em> only 。）

Libpcap无线电分组数据包

1 个答案: