13

我有一个.pcap我正在分析的 Wi-Fi 捕获 ( )，并且遇到了在我看来 802.11 规范和 Wireshark 对数据的解释之间的不一致之处。具体来说，我要分解的是 2 字节 802.11帧控制字段。

取自http://www4.ncsu.edu/~aliu3/802.bmp，Frame Control 字段的子字段格式如下：

帧控制子字段。

下面是让我感到困惑的数据包的 Wireshark 屏幕截图：

Wireshark 中令人困惑的帧控制

因此，根据 Wireshark 屏幕截图，帧控制字段的标志部分（最后 8 位）是 0x22，这很好。版本/类型/子类型如何0x08与 Wireshark 对框架的描述相匹配，这让我感到困惑。

0x08= 0000 1000b，我认为这将转换为 Version = 00， Type = 00（我认为这意味着管理而不是数据帧）和 Subtype = 1000（我认为这将是一个信标帧）。所以我希望这个帧是一个管理帧，更具体地说，是一个信标帧。然而，Wireshark 将其报告为数据框。让我感到困惑的第二件事是 Wireshark 甚至0x20排在哪里Type/Subtype: Data (0x20)。

谁能为我澄清我对 802.11 规范/Wireshark 捕获的解释以及为什么两者不一致？

4

3 回答 3

18

您示例中的数据帧为 0x08，因为帧控件 (FC) 的该字节的布局。0x08 = 00001000 - 前 4 位 (0000) 是子类型。0000 是此帧的子类型 - 接下来的 2 位 (10) 是类型，它是十进制的 2，因此是数据类型帧 - 最后 2 位 (00) 是版本，即 0

下表将 FC 的 subtype-type-version 字节的十六进制值转换为几种帧类型。将 QoS 数据与正常数据帧进行比较可能真的有助于解决这个问题。请注意，桌子可能有一两个错误，因为我刚刚把它弄好了。

你是对的，1000 是一个信标帧，你只是在看错误的位。

在此处输入图像描述

您有一个 radiotap 标头，您可以从 pcap API 中获取该类型的 dec 表示形式：

int type = pkt_data[20] >> 2;
于 2012-10-04T01:04:43.307 回答
3

这是一个常见的错误，肯定已经咬了我好几次了。

这取决于字节顺序。

当你有一个多字节数来表示时，问题就出现了，你首先放置/发送哪个字节？

自然（人）字节顺序是先放大部分，后放小部分，从左到右，也称为大端。请注意，从程序员的角度来看，每个字节中的位永远不会出错。

例如 1234 十进制需要 2 个字节，04D2 十六进制。你写/发送 04 D2 还是 D2 04 ？第一个是大端，第二个是小端。

更令人困惑的是，所涉及的机制可能使用不同的字节顺序。

有网络字节顺序，在这种情况下是 Little-endian，架构字节顺序（每个 CPU 架构可能不同）并且数据可能在缓冲区中，因此它会根据您是否从上到下读取缓冲区而有所不同- 自下而上或自下而上。

正如您的原始帖子中那样，对哪些位的解释也可能是“向后”的，这无济于事。

于 2013-01-13T08:55:06.213 回答
0

我wireshark version-2.4.3在窗户上使用。我的数据帧捕获文件如下所示。

Frame control field = 0x0842 i.e., in binary format 0000 1000 0100 0010 
Framecontrol flag field = 0x42.i.e., in binary format 0100 0010

因此，据我了解LSB 8bits，framecontrol 字段中的字段将对应于标志。

MSB 8bits 将对应于子类型、类型、版本，即在我的情况下0000-subtype是 & 10-type& 00-version。

这是子类型0的数据框。

在您的情况下，这可能是wireshark的错误。它应该显示帧控制字段0x0822而不是 0x2208。

标志字段正确显示为0x22.

在我的情况下，我正在使用并且在 flags 所在的位置wireshark-2.4.3显示帧控制字段是正确的。0x08420x42

我的捕获文件：

在此处输入图像描述

于 2018-03-30T14:23:45.553 回答