USB迷 | 专注于互联网分享

    最新消息： USBMI致力于为网友们分享Windows、安卓、IOS等主流手机系统相关的资讯以及评测、同时提供相关教程、应用、软件下载等服务。
    你的位置： 首页 > 业界 > 《CWAP-404》，第7章：MAC操作（7.1，分析数据帧交换）

    《CWAP-404》，第7章：MAC操作（7.1，分析数据帧交换）

    业界 admin 4浏览 0评论
    数据帧交换是驱动用户使用WLAN的核心操作。用户通常不太关注信标帧（Beacon frames）、探测请求帧（Probe Request frames）等管理或控制帧，而是更关注数据帧。不要误解——他们并不知道数据帧才是其最关心的部分，但事实确实如此。当然，我们知道，如果没有其他控制帧和管理帧的正常工作，数据帧就无法完成其使命，但我们不妨将这个秘密留给自己。 本节中，您将学习如何捕获以下帧类型：
    • 数据帧
    • QoS数据帧
    • 确认帧（Acknowledgement frames）
    • RTS和CTS帧
    • 块确认帧（Block Acknowledgement frames）

    捕获数据帧

    数据帧的类型字段（Type）为10，子类型字段（Subtype）为0000。协议分析工具通常会解码并标注其为“数据帧”。由于数据帧的传输速率通常远高于信标帧、确认帧及其他管理/控制帧，因此需要尽可能靠近发送或接收数据帧的设备进行捕获。 例如，若尝试从位于接入点（AP）另一侧的客户端捕获数据帧，可能无法正确解调这些帧，因为它们以较高的速率发送，而您所在位置的信号噪声比（SNR）不足以支持解调。您可能会看到从AP发送至远端客户端的数据帧，但无法正确解调从远端客户端返回至AP的数据帧。 下图展示了一个典型的数据帧，其中标明了类型和子类型字段。 （注：以下内容对CWAP考试并非重点）Airtool工具可简化Macbook上的帧捕获流程。安装Airtool工具（截至本文撰写时版本为2）和Wireshark后，您便具备了捕获帧所需的所有工具。下图展示了Airtool的基本操作界面。 这款简单且免费的工具虽然界面简洁，但背后隐藏着强大的功能。您可快速启动捕获任务，并将结果保存至指定路径的Wireshark捕获文件（默认保存到桌面）。随后只需打开捕获文件即可查看结果。若希望使用比Wireshark更专业的Wi-Fi分析工具，可直接在这些工具中打开PCAP文件。如需在MacBook上下载安装该工具（暂不支持Windows用户），请访问 cvmp.link/airtool。

    捕获QoS数据帧

    QoS数据帧的类型字段（Type）为10，子类型字段（Subtype）为1000。大多数协议分析工具除显示类型/子类型值外，还会解码并标注该帧为“QoS数据帧”。QoS控制元素（QoS Control）将指示帧的优先级。下图展示了一个“尽力而为”（Best Effort）QoS数据帧，下下图则展示了一个“语音”（Voice）QoS数据帧。 捕获QoS数据帧与捕获标准数据帧的方法完全一致。需靠近目标设备以捕获其发送和接收的数据帧。QoS数据帧在介质上的传输方式与标准数据帧相同，因此捕获过程并无差异。QoS数据帧的核心区别在于其优先级设置，该设置决定了帧的发送顺序（优先或延后）。

    捕获确认帧与块确认帧

    标准确认帧（Standard Acknowledgements）是简短的帧，用于表示“我已收到你的通信”。这类似于对话时点头示意。确认帧（Ack）意味着接收方已成功接收数据帧；若无确认帧，发送方将认为需要确认的帧未被接收，从而触发重传机制。 有趣的是，如下图所示，确认帧也用于建立块确认（Block Ack）协议。 站点（STA）在接收到需要确认的非CRC错误帧后，应立即发送确认帧。若未发送，原帧将进行重传。重传帧可通过帧控制字段（Frame Control fields）中的重试位（Retry bit）是否为1来识别。 块确认（Block Acknowledgements）可能包含以下流程：
    • 数据交换前发送添加块确认请求（Add Block Ack Request）与添加块确认响应（Add Block Ack Response）。
    要捕获此类交换过程，需将捕获设备部署在接入点（AP）附近，或靠近与AP进行通信的客户端。无论选择哪一位置，都应能捕获完整的交换流程，因为AP和客户端均需发送并接收所有相关帧。添加块确认请求与响应在捕获文件中将显示为“动作帧”（Action frames）。上图以概念图形式展示了这一交换过程。 在下图中，您可以看到 添加块确认请求帧（Add Block Ack Request frame）。注意，此案例中该帧是从客户端发送至NETGEAR AP的。 在下图中，您可以看到 添加块确认响应帧（Add Block Ack Response frame）。此帧由NETGEAR AP发送至请求的客户端。在请求与响应之间以及响应之后，均存在标准的确认帧（ACK frame）。 上述交换为两个站点（客户端与AP）建立了执行块确认操作的能力。 添加块确认响应帧（Add Block Ack Response）将包含以下内容：
    • 块确认策略（Block Ack Policy）：指示采用“立即块确认”（Immediate Block Ack）或“延迟块确认”（Delayed Block Ack）。立即块确认是最常用的策略。
    • 块确认超时值（Block Ack Timeout Value）：以时间单位（TUs）指定协议有效时长，若超时未传输帧，则块确认协议终止。
    捕获确认帧（Ack）和块确认帧（Block Ack）时，可选择部署在AP附近或目标客户端附近。无论选择哪种位置，协议分析工具（及适配器/无线模块）都应能正确捕获并解调所需帧。

    捕获RTS/CTS交换

    最后一种与数据传输相关的捕获操作是RTS/CTS交换。该机制用于以下场景：
    • BSS中存在低性能站点时作为保护机制；
    • 解决“隐藏节点问题”（即两个客户端均可与AP通信，但彼此无法直接感知）。
    捕获RTS/CTS交换的准则与捕获数据帧、QoS数据帧一致：需靠近目标设备进行捕获。 下图展示了一个从客户端（本例为Apple iPhone）发送至AP（本例为NETGEAR AP）的RTS帧。注意其持续时间值（Duration value）设为154微秒。这一观察至关重要，因为后续CTS帧和数据帧中该值会逐步递减。本书其他章节已详细解释RTS/CTS帧的用途，此处重点在于捕获并解析其内容。 下一关键帧是CTS帧，如图7.9所示。注意其持续时间值（Duration）减少了44微秒，降至110微秒。下图截取部分未显示的是：802.11无线模块信息显示该CTS帧本身占用了28微秒的空口时间。有趣的是，在5 GHz频段中，HT和VHT设备（本例中使用的设备）的短帧间间隔（SIFS）为16微秒。28微秒加16微秒等于多少？没错！正是44微秒——这也恰好是上图中RTS帧持续时间值减少的数值。 在此次交换中，下一关键帧是大小为182字节的QoS数据帧。RTS和CTS帧以24 Mbps速率发送，以确保BSS内所有其他站点能侦听到并解码其持续时间值。QoS数据帧则以更高速率发送，其持续时间值设为48微秒（图中未显示），表示该帧传输完成后还需48微秒空口时间。 最后一个问题：数据帧之后是什么？本例中为块确认帧（Block Acknowledgement），它以24 Mbps速率发送。您能推测该块确认帧在介质上的传输时长吗？（假设系统工作正常且无驱动错误）答案如下：
    • QoS数据帧传输后需等待一个短帧间间隔（SIFS，16微秒）；
    • 从QoS数据帧的持续时间值48微秒中减去16微秒，剩余32微秒即为块确认帧的传输时长。
    Wireshark的持续时间计算原理
    需要了解的是，Wireshark并非通过无线电测量，而是基于以下已知参数计算持续时间：
    • 使用的物理层协议（PHY）
    • 前导码结构（长度与发送速率）
    • PLCP头结构（长度与发送速率，至少可近似）
    • MPDU大小与发送速率Wireshark通过以下公式（或类似逻辑）进行计算：前导码时间 + （帧长度 × 8） / 数据速率
    数据帧交换是驱动用户使用WLAN的核心操作。用户通常不太关注信标帧（Beacon frames）、探测请求帧（Probe Request frames）等管理或控制帧，而是更关注数据帧。不要误解——他们并不知道数据帧才是其最关心的部分，但事实确实如此。当然，我们知道，如果没有其他控制帧和管理帧的正常工作，数据帧就无法完成其使命，但我们不妨将这个秘密留给自己。 本节中，您将学习如何捕获以下帧类型：
    • 数据帧
    • QoS数据帧
    • 确认帧（Acknowledgement frames）
    • RTS和CTS帧
    • 块确认帧（Block Acknowledgement frames）

    捕获数据帧

    数据帧的类型字段（Type）为10，子类型字段（Subtype）为0000。协议分析工具通常会解码并标注其为“数据帧”。由于数据帧的传输速率通常远高于信标帧、确认帧及其他管理/控制帧，因此需要尽可能靠近发送或接收数据帧的设备进行捕获。 例如，若尝试从位于接入点（AP）另一侧的客户端捕获数据帧，可能无法正确解调这些帧，因为它们以较高的速率发送，而您所在位置的信号噪声比（SNR）不足以支持解调。您可能会看到从AP发送至远端客户端的数据帧，但无法正确解调从远端客户端返回至AP的数据帧。 下图展示了一个典型的数据帧，其中标明了类型和子类型字段。 （注：以下内容对CWAP考试并非重点）Airtool工具可简化Macbook上的帧捕获流程。安装Airtool工具（截至本文撰写时版本为2）和Wireshark后，您便具备了捕获帧所需的所有工具。下图展示了Airtool的基本操作界面。 这款简单且免费的工具虽然界面简洁，但背后隐藏着强大的功能。您可快速启动捕获任务，并将结果保存至指定路径的Wireshark捕获文件（默认保存到桌面）。随后只需打开捕获文件即可查看结果。若希望使用比Wireshark更专业的Wi-Fi分析工具，可直接在这些工具中打开PCAP文件。如需在MacBook上下载安装该工具（暂不支持Windows用户），请访问 cvmp.link/airtool。

    捕获QoS数据帧

    QoS数据帧的类型字段（Type）为10，子类型字段（Subtype）为1000。大多数协议分析工具除显示类型/子类型值外，还会解码并标注该帧为“QoS数据帧”。QoS控制元素（QoS Control）将指示帧的优先级。下图展示了一个“尽力而为”（Best Effort）QoS数据帧，下下图则展示了一个“语音”（Voice）QoS数据帧。 捕获QoS数据帧与捕获标准数据帧的方法完全一致。需靠近目标设备以捕获其发送和接收的数据帧。QoS数据帧在介质上的传输方式与标准数据帧相同，因此捕获过程并无差异。QoS数据帧的核心区别在于其优先级设置，该设置决定了帧的发送顺序（优先或延后）。

    捕获确认帧与块确认帧

    标准确认帧（Standard Acknowledgements）是简短的帧，用于表示“我已收到你的通信”。这类似于对话时点头示意。确认帧（Ack）意味着接收方已成功接收数据帧；若无确认帧，发送方将认为需要确认的帧未被接收，从而触发重传机制。 有趣的是，如下图所示，确认帧也用于建立块确认（Block Ack）协议。 站点（STA）在接收到需要确认的非CRC错误帧后，应立即发送确认帧。若未发送，原帧将进行重传。重传帧可通过帧控制字段（Frame Control fields）中的重试位（Retry bit）是否为1来识别。 块确认（Block Acknowledgements）可能包含以下流程：
    • 数据交换前发送添加块确认请求（Add Block Ack Request）与添加块确认响应（Add Block Ack Response）。
    要捕获此类交换过程，需将捕获设备部署在接入点（AP）附近，或靠近与AP进行通信的客户端。无论选择哪一位置，都应能捕获完整的交换流程，因为AP和客户端均需发送并接收所有相关帧。添加块确认请求与响应在捕获文件中将显示为“动作帧”（Action frames）。上图以概念图形式展示了这一交换过程。 在下图中，您可以看到 添加块确认请求帧（Add Block Ack Request frame）。注意，此案例中该帧是从客户端发送至NETGEAR AP的。 在下图中，您可以看到 添加块确认响应帧（Add Block Ack Response frame）。此帧由NETGEAR AP发送至请求的客户端。在请求与响应之间以及响应之后，均存在标准的确认帧（ACK frame）。 上述交换为两个站点（客户端与AP）建立了执行块确认操作的能力。 添加块确认响应帧（Add Block Ack Response）将包含以下内容：
    • 块确认策略（Block Ack Policy）：指示采用“立即块确认”（Immediate Block Ack）或“延迟块确认”（Delayed Block Ack）。立即块确认是最常用的策略。
    • 块确认超时值（Block Ack Timeout Value）：以时间单位（TUs）指定协议有效时长，若超时未传输帧，则块确认协议终止。
    捕获确认帧（Ack）和块确认帧（Block Ack）时，可选择部署在AP附近或目标客户端附近。无论选择哪种位置，协议分析工具（及适配器/无线模块）都应能正确捕获并解调所需帧。

    捕获RTS/CTS交换

    最后一种与数据传输相关的捕获操作是RTS/CTS交换。该机制用于以下场景：
    • BSS中存在低性能站点时作为保护机制；
    • 解决“隐藏节点问题”（即两个客户端均可与AP通信，但彼此无法直接感知）。
    捕获RTS/CTS交换的准则与捕获数据帧、QoS数据帧一致：需靠近目标设备进行捕获。 下图展示了一个从客户端（本例为Apple iPhone）发送至AP（本例为NETGEAR AP）的RTS帧。注意其持续时间值（Duration value）设为154微秒。这一观察至关重要，因为后续CTS帧和数据帧中该值会逐步递减。本书其他章节已详细解释RTS/CTS帧的用途，此处重点在于捕获并解析其内容。 下一关键帧是CTS帧，如图7.9所示。注意其持续时间值（Duration）减少了44微秒，降至110微秒。下图截取部分未显示的是：802.11无线模块信息显示该CTS帧本身占用了28微秒的空口时间。有趣的是，在5 GHz频段中，HT和VHT设备（本例中使用的设备）的短帧间间隔（SIFS）为16微秒。28微秒加16微秒等于多少？没错！正是44微秒——这也恰好是上图中RTS帧持续时间值减少的数值。 在此次交换中，下一关键帧是大小为182字节的QoS数据帧。RTS和CTS帧以24 Mbps速率发送，以确保BSS内所有其他站点能侦听到并解码其持续时间值。QoS数据帧则以更高速率发送，其持续时间值设为48微秒（图中未显示），表示该帧传输完成后还需48微秒空口时间。 最后一个问题：数据帧之后是什么？本例中为块确认帧（Block Acknowledgement），它以24 Mbps速率发送。您能推测该块确认帧在介质上的传输时长吗？（假设系统工作正常且无驱动错误）答案如下：
    • QoS数据帧传输后需等待一个短帧间间隔（SIFS，16微秒）；
    • 从QoS数据帧的持续时间值48微秒中减去16微秒，剩余32微秒即为块确认帧的传输时长。
    Wireshark的持续时间计算原理
    需要了解的是，Wireshark并非通过无线电测量，而是基于以下已知参数计算持续时间：
    • 使用的物理层协议（PHY）
    • 前导码结构（长度与发送速率）
    • PLCP头结构（长度与发送速率，至少可近似）
    • MPDU大小与发送速率Wireshark通过以下公式（或类似逻辑）进行计算：前导码时间 + （帧长度 × 8） / 数据速率
    继续浏览有关 的文章

    与本文相关的文章

    发布评论

    评论列表 (0)

    1. 暂无评论