简介：本资源是一份面向网络初学者与无线通信入门学习者的Wi-Fi基础知识系统性整理文档，聚焦3G/4G/Wi-Fi技术体系中的Wi-Fi核心原理，解决概念模糊、术语混淆、协议演进脉络不清等常见学习痛点。文档为单文件Word格式（.doc），全文88KB，结构清晰分为四大模块：从Wi-Fi与有线网络的对比优势及固有局限（如半双工、高误码率、易抓包、功耗大等）切入；详解IEEE 802.11协议族发展脉络（802.11a/b/g/n），特别说明802.11n在HT-40信道绑定与MIMO多天线技术上的关键改进；深入解析AP、Station、SSID、BSSID、BSS、DS等10余个无线网络核心术语及其协同关系；最后辅以MAC层基础与实践参数说明。内容兼顾中英文术语对照与原理阐释，适合自学打基础、备课教学或考前梳理。目前已有280人学习下载。
1. Wi-Fi 不是“无线以太网”：它连全双工都做不到，却靠半双工+重传+帧切片撑起整个移动互联网
你有没有试过在会议室里同时开三个视频会议、传一个 2GB 的设计稿、再让手机后台同步照片——结果所有设备集体卡成 PPT？不是路由器太老，也不是宽带不够，而是你正在用的 Wi-Fi，从协议底层就决定了：它根本不是为“并发高吞吐”而生的。它是一套在电磁噪声中搏命求存的通信机制：没有物理线缆兜底，信号在空气中自由散射，两个设备彼此“看不见”却要抢同一片频谱；一次传输失败不是丢一个 TCP 包，而是整帧（Frame）被空气吞掉，必须重发；哪怕只是发个 ACK 确认，都要先听半秒信道是否空闲——这哪是网络？这是无线电战场上的巷战。
这份《Wi-Fi 基础知识讲解.doc》不是教你怎么点“一键连接”，而是把 IEEE 802.11 协议栈从物理层（PHY）到介质访问控制层（MAC）一层层剥开，告诉你为什么 Wi-Fi 必须用 RTS/CTS 对抗“隐藏节点”，为什么 Beacon 帧里藏着省电的 DTIM 时钟，为什么抓包时看到的 MAC 地址和路由器背面贴的“MAC”对不上，为什么 WPA2-AES 是目前唯一能真正落地的安全闭环。它不讲“5G 频段更快”，而讲清楚：5GHz 频段本身不快，快的是它允许更宽的 Channel Width（40/80MHz），而 Channel Width 加倍的前提，是 MAC 层必须支持 HT-Mixed 模式下的帧聚合与 MIMO 空间流调度——这些全在 802.11n 的 MAC 子层里硬编码实现。看懂这个，你才真正理解：为什么换一个支持 802.11ax 的路由器，不改宽带，微信发高清视频却不再转圈；为什么企业级 AP 要配 RADIUS 服务器，而家用路由器只填个 PSK 密码就完事；为什么 Wireshark 抓出来的“Beacon”帧里，那个看似无用的 TIM（Traffic Indication Map）字段，其实是手机待机时省电 30% 的关键开关。这不是知识整理，这是 Wi-Fi 协议栈的 X 光片——照出每一处设计妥协、每一行生存逻辑。
2. 半双工困局：Wi-Fi 为何天生无法像以太网一样“边说边听”
Wi-Fi 的“慢”，根源不在天线，不在芯片，而在它被迫接受的一个物理铁律：同一时刻，一个无线设备只能发射或接收，不能同时进行。这就是半双工（Half-Duplex）的本质。以太网用双绞线隔离发送/接收通道，物理上就支持全双工；Wi-Fi 的收发共用同一根天线、同一段频谱，发射信号功率比接收灵敏度高 80dB 以上——相当于你对着喇叭喊话时，耳朵必须捂紧，否则会被自己震聋。这个限制像基因一样刻进整个 802.11 协议栈，所有上层优化，都是在给这个先天缺陷打补丁。
2.1 CSMA/CA：不是“载波侦听多路访问”，而是“先听后说+随机退避”的生存策略
以太网用 CSMA/CD（Collision Detection，冲突检测）：大家边发边听，一撞立刻停，随机等会儿再发。Wi-Fi 不能用 CD——因为发射时自己听不见别人，根本检测不到冲突。于是它改用 CSMA/CA（Collision Avoidance，冲突避免）：必须先听够时间（DIFS，DCF Interframe Space），确认信道空闲，再随机选个退避时隙（Backoff Slot），倒数到 0 才敢发。这个“听”不是礼貌，是保命。DIFS 时长由物理层决定：802.11a/g 是 34μs，802.11n 是 28μs，背后是 OFDM 符号周期与保护间隔（GI）的硬约束。
# 伪代码：CSMA/CA 的核心退避逻辑（简化版） def csma_ca_transmit(frame): while True: if channel_idle_for(DIFS): # DIFS = SIFS + 2 * SlotTime backoff = random.randint(0, CW_min) # CW_min = 15 for 802.11a/g/n while backoff > 0: if channel_idle_for(SlotTime): backoff -= 1 else: backoff = random.randint(0, min(2*CW_min, CW_max)) # 冲突后加倍窗口 break if backoff == 0: send_frame(frame) if not receive_ack(): # ACK 必须在 SIFS 后收到（SIFS < DIFS！） continue # 重试 break注意：SIFS（Short Interframe Space）是 ACK 帧的黄金时间窗。AP 发完数据帧，必须在 SIFS（16μs for 802.11a/g）内发出 ACK，否则 Station 认为丢包。这个时间比 DIFS（34μs）短，确保 ACK 永远插队成功——这是半双工下维持可靠性的唯一杠杆。
2.2 隐藏节点问题：为什么两个设备“互相看不见”，却能让整个 Wi-Fi 崩溃
想象一个典型家庭场景：AP 放在客厅中央，Station A（笔记本）在书房，Station B（手机）在厨房。A 和 B 到 AP 的距离都在信号覆盖内，但 A 和 B 直线距离太远，彼此信号强度低于接收灵敏度阈值——它们就是“隐藏节点”（Hidden Node）。当 A 和 B 同时向 AP 发送数据时，AP 会同时收到两个强信号，叠加成乱码（Collision），两帧全废。更糟的是，A 和 B 都没听到对方在发，所以不会退避，持续碰撞。
这就是 RTS/CTS 机制存在的唯一理由：用两个极短的控制帧，构建一个虚拟的“说话权”令牌系统。
- Station A 想发大数据前，先发 RTS（Request To Send）帧给 AP，里面声明：“我要发 X 字节，预计占用 Y 微秒”。
- AP 收到后，广播 CTS（Clear To Send）帧，告诉所有能听到 AP 的设备：“接下来 Y 微秒，信道归 A 专用，请静默”。
- B 听到 CTS，立刻明白 A 要发，停止自己的发送计划；A 收到 CTS，确认信道已清空，开始发数据。
// Linux kernel 中 802.11 MAC 层 RTS/CTS 触发逻辑（net/mac80211/tx.c） if (ieee80211_is_data_qos(hdr->frame_control) && skb->len > local->hw.conf.rts_threshold) { // RTS Threshold 可配置 // 构造 RTS 帧：目的地址=AP BSSID，持续时间=Data帧+ACK所需总时长 struct ieee80211_hdr *rts = (struct ieee80211_hdr *)skb_push(skb, sizeof(*rts)); rts->frame_control = cpu_to_le16(IEEE80211_FTYPE_CTL | IEEE80211_STYPE_RTS); rts->duration_id = ieee80211_get_duration(local, skb, type); // duration_id 是关键：它告诉所有监听者“静默多久” }提示：RTS Threshold 默认常设为 2347 字节（接近 MTU），意味着绝大多数数据帧都会触发 RTS/CTS。但实际部署中，若环境干扰小、距离近，关闭 RTS/CTS 反而提升吞吐——因为 RTS/CTS 本身也占带宽。这是典型的“安全 vs 性能”取舍。
2.3 帧重传：不是 TCP 的超时重传，而是 MAC 层的“秒级搏杀”
TCP 重传以秒计（RTO），Wi-Fi 的 MAC 层重传以微秒计。一个 Data 帧发出后，必须在 SIFS + ACK 传输时间（约 20-30μs）内收到 ACK，否则立即标记为失败。失败后不是等几秒，而是立刻进入重传流程：
- 将退避窗口 CW（Contention Window）翻倍（CW = min(2*CW, CW_max)）；
- 重新执行 CSMA/CA 退避；
- 若重传次数达上限（通常 7 次），该帧被丢弃，上层 TCP 才感知到丢包。
这意味着：Wi-Fi 的“丢包率”是 MAC 层实时计算的瞬时指标，不是网络层统计值。抓包时看到连续多个 Seq=100 的帧，后面跟着 Retry=1 标志，就是重传证据。而 Fragmentation Threshold（分片阈值）正是为此而生——把大包切成小片，单片丢失只需重传一片，而非整包：
# 查看当前网卡的分片阈值（Linux） $ iw dev wlan0 survey dump | grep "fragment" # 或通过驱动接口（如 ath9k） $ cat /sys/kernel/debug/ieee80211/phy0/ath9k/frag_threshold 2346分片阈值设为 2346 字节，意味着超过此长度的数据帧会被切片。每个分片独立编号（Fragment Number），独立 ACK。但切片越多，帧头开销越大（每个分片都有完整 MAC 头），所以阈值需权衡：太小则开销爆炸，太大则重传代价过高。
3. Beacon 帧：不只是“广播 SSID”，它是 Wi-Fi 网络的脉搏与日历
当你用手机扫描 Wi-Fi 列表，看到一堆 SSID，你以为是 AP 在“喊名字”？错。那是 AP 每隔固定毫秒（Beacon Interval，默认 100ms）发出的 Beacon 帧，它是一份结构化电子公告，承载着整个 BSS（Basic Service Set）的运行时态。它不只宣告存在，更在协调所有 Station 的行为节奏——从休眠唤醒，到信道切换，再到安全密钥更新，全靠它调度。
3.1 Beacon 帧结构：TIM、DTIM、ERP、HT Capability 字段如何定义网络能力边界
Beacon 帧是管理帧（Management Frame），类型为 0x0008。其核心字段远超 SSID：
| 字段名 | 长度 | 关键作用 | 协议版本依赖 |
|---|---|---|---|
| Timestamp | 8 字节 | AP 本地时钟，用于 Station 时间同步（如 TDMA） | 所有版本 |
| Beacon Interval | 2 字节 | 下一 Beacon 发送间隔（单位：TU，1TU=1024μs） | 所有版本 |
| Capabilities Info | 2 字节 | 标识网络能力：ESS（AP模式）、IBSS（Ad-hoc）、Privacy（加密）、Short Preamble 等 | 所有版本 |
| SSID | 可变 | 网络名称，IE Type=0 | 所有版本 |
| Supported Rates | 可变 | 支持的速率列表（如 1,2,5.5,11,6,9,12,18,24,36,48,54Mbps） | 所有版本 |
| DS Parameter Set | 3 字节 | 当前工作 Channel（如 Channel 6） | 802.11b/g |
| ERP (Extended Rate PHY) | 3 字节 | 指示是否启用 802.11g 的保护机制（如使用 CCK 速率时是否插入 RTS/CTS） | 802.11g |
| HT Capabilities | 26 字节 | 802.11n 的 MIMO 流数、Channel Width（20/40MHz）、MCS 支持表 | 802.11n |
| VHT Capabilities | 12 字节 | 802.11ac 的 80/160MHz、MU-MIMO、更高阶 MCS | 802.11ac |
| TIM (Traffic Indication Map) | 可变 | 位图，指示哪些 Station 有缓存数据待取（省电关键） | 所有版本 |
| Country IE | 可变 | 国家码（如 CN/US），约束发射功率与可用 Channel | 802.11d |
其中 TIM 字段最精妙：它是一个位图（Bitmap），每个 bit 对应一个 Association ID（AID），AID 由 AP 在 Station 关联时分配（范围 1-2007）。若 AP 为 Station A 缓存了数据，就在 TIM 的对应 bit 置 1。Station 在休眠前，会设置自己的 DTIM Interval（如 3），表示每 3 个 Beacon 帧醒来一次检查 TIM。当 Beacon 的 DTIM Count=0 时（即 DTIM Period 的起始帧），TIM 中所有 bit 有效，Station 知道该全面唤醒了。
// Beacon 帧中 TIM IE 解析逻辑（Wireshark dissectors/epan/dissectors/packet-ieee80211.c） static void dissect_tim_ie(tvbuff_t *tvb, packet_info *pinfo, proto_tree *tree, int offset) { guint8 dtim_count = tvb_get_guint8(tvb, offset + 2); // DTIM Count guint8 dtim_period = tvb_get_guint8(tvb, offset + 3); // DTIM Period guint8 bitmap_ctl = tvb_get_guint8(tvb, offset + 4); // Bitmap Control guint8 *bitmap = tvb_memdup(pinfo->pool, tvb, offset + 5, bitmap_len); // bitmap[0] 是 Partial Virtual Bitmap 的起始 AID（低 6 位） // bitmap[1..n] 是位图数据，bit i 表示 AID = start_aid + i 是否有缓存数据 if (dtim_count == 0) { // DTIM Beacon，所有 Station 必须唤醒 proto_tree_add_uint_format(tree, hf_ieee80211_tim_dtim, tvb, offset+2, 1, dtim_count, "DTIM Count: %u (DTIM Beacon)", dtim_count); } }提示：Beacon Interval 设得太小（如 20ms），AP 发送负担剧增，尤其在高密度 AP 环境下引发信道拥塞；设得太大（如 500ms），Station 扫描延迟升高，漫游切换变慢。100ms 是平衡点，但企业级 AP 常设为 50ms 以加速客户端发现。
3.2 Beacon 与漫游：为什么 SSID 不变，BSSID 一定变，且切换耗时取决于 Beacon Timing
漫游（Roaming）不是“断开旧 AP，连上新 AP”这么简单。它是 Station 基于 Beacon 信息做的主动决策：
- Station 持续扫描周边 Beacon，比较 RSSI（信号强度）、SNR（信噪比）、负载（通过 Vendor IE 或 802.11k Radio Resource Measurement 获取）；
- 当新 AP 的 RSSI 比当前 AP 高 8dB 以上，且满足厂商预设的漫游阈值，Station 启动重关联（Reassociation）；
- 关键点：重关联请求（Reassociation Request）必须在当前 AP 的 Beacon Interval 内完成，否则被视为超时断连。
因此，Beacon Interval 直接影响漫游速度。若 Interval=100ms，Station 最多等待 100ms 才能收到新 AP 的 Beacon 并发起关联；若 Interval=50ms，则响应更快。这也是为什么企业级 AP 允许调小 Interval——为 VoIP、视频会议等实时业务争取毫秒级切换窗口。
3.3 避坑：Beacon 相关的 4 类致命误配置
现象 → 原因 → 解决，全是血泪经验：
现象：手机显示“Wi-Fi 已连接”，但无法打开网页，ping 网关丢包率 80%。
原因：AP 的 Beacon Interval 被错误设为 1000ms（1秒），而 Station 的扫描周期默认 200ms。Station 在两次 Beacon 之间长时间“失联”，误判 AP 死亡，反复尝试重连。
解决：将 Beacon Interval 恢复为默认 100ms，或至少 ≤ 200ms。现象：多台设备连接同一 AP，其中一台笔记本休眠后，微信消息延迟 2 分钟才收到。
原因：DTIM Interval 设为 10，即每 10 个 Beacon（1 秒）才唤醒一次检查 TIM。而微信心跳包超时是 30 秒，导致消息积压。
解决：将 DTIM Interval 设为 1（每个 Beacon 都检查），或启用 U-APSD（Unscheduled Automatic Power Save Delivery）让 Station 主动请求缓存数据。现象：在 5GHz 频段，Wi-Fi 速度忽高忽低，Wireshark 抓包显示大量 “Beacon missed” 告警。
原因：AP 开启了 DFS（Dynamic Frequency Selection）雷达检测，当侦测到气象雷达信号，强制跳频并暂停 Beacon 发送 60 秒（FCC 规定）。
解决：在非雷达敏感区域（如室内），关闭 DFS，或手动指定非 DFS Channel（如 36, 40, 44, 48）。现象：Android 手机无法扫描到某 AP 的 SSID，但 iPhone 可以。
原因：AP 的 Beacon 帧中 SSID IE 被设为 “hidden”，即 SSID Length=0，不广播名称。iPhone 默认仍会探测并显示（基于 Probe Response），而部分 Android 厂商 ROM 的扫描逻辑跳过 hidden SSID。
解决：在 AP 设置中关闭 “Hide SSID”，或让手机手动输入 SSID 连接（此时不依赖 Beacon 广播）。
4. 数据帧方向：DS 字段不是“路由标志”，而是 Wi-Fi 网络拓扑的 DNA 编码
当你在 Wireshark 里看到一个 Data 帧，源 MAC 是手机，目的 MAC 是路由器，你以为这是“手机→路由器”的上行流？错。802.11 Data 帧的地址字段含义，完全由帧头中的To DS / From DS两位决定。这两位不是可选配置，而是 Wi-Fi 网络拓扑的硬编码标识——它直接告诉 MAC 层：“此刻，数据正穿越哪种网络结构”。忽略它，你就永远看不懂为什么同一个 AP 下，手机发给打印机的包，目的 MAC 却是打印机的 MAC，而不是 AP 的 MAC。
4.1 DS 字段的四种组合：解码 Wi-Fi 网络的骨架
802.11 Data 帧有 4 个地址字段（Addr1–Addr4），但常用的是 Addr1（Receiver）、Addr2（Transmitter）、Addr3（BSSID 或 Destination）。DS 字段（2 位）决定 Addr3 的语义：
| To DS | From DS | 场景 | Addr1（Receiver） | Addr2（Transmitter） | Addr3（Third Address） | 典型用途 |
|---|---|---|---|---|---|---|
| 0 | 0 | Ad-hoc（点对点） | 目的 Station | 源 Station | BSSID（IBSS ID） | 临时组网，无 AP |
| 0 | 1 | Station → AP（上行） | AP（BSSID） | Station | 源 Station（即 Destination） | 手机上传文件到云盘 |
| 1 | 0 | AP → Station（下行） | Station | AP（BSSID） | 目的 Station（即 Destination） | 路由器推送网页内容到手机 |
| 1 | 1 | WDS（无线桥接） | 接收端 AP | 发送端 AP | 目的 Station | 两个 AP 用无线链路互联 |
关键洞察：在基础结构型网络（Infrastructure BSS）中，To DS=1 & From DS=0 是最常见的下行帧（AP→Station），此时 Addr3 = 目的 Station 的 MAC 地址；而 To DS=0 & From DS=1 是上行帧（Station→AP），此时 Addr3 = 源 Station 的 MAC 地址。这解释了为什么抓包时，你看到手机发给服务器的包，Addr1 是 AP 的 BSSID，Addr3 却是服务器的 IP 对应的 MAC——因为数据要先到 AP，再由 AP 转发（Layer 2 Bridge），Addr3 记录的是最终 Layer 2 目的地。
4.2 BSSID 与 MAC 地址：为什么路由器背面贴的 MAC 和抓包看到的 BSSID 总是“差几位”
文档中明确指出：“BSSID 一般是 AP 的 MAC 地址”，但实践中，你常看到 BSSID 是a4:2b:b0:12:34:56，而路由器标签写的是a4:2b:b0:12:34:55。这不是故障，而是MAC 地址虚拟化（MAC Virtualization）的标准实践。
AP 的物理网卡（NIC）只有一个 MAC 地址（OUI + Extension），但一个 AP 可能同时提供多个服务：
- 2.4GHz WLAN 接口 → 分配 BSSID1
- 5GHz WLAN 接口 → 分配 BSSID2
- 有线 LAN 接口 → 使用物理 MAC
- Guest Network（访客网络） → 分配 BSSID3
为避免 MAC 冲突，厂商采用“MAC 偏移”策略：以物理 MAC 为基址，对不同接口加固定偏移。例如 Broadcom 芯片常用规则：
- 主 WLAN 接口：物理 MAC + 0x000000000001
- 5GHz 接口：物理 MAC + 0x000000000002
- Guest 网络：物理 MAC + 0x000000000003
所以a4:2b:b0:12:34:55的物理 MAC，其 2.4GHz BSSID 就是a4:2b:b0:12:34:56。Wireshark 抓包时显示的 BSSID，永远是当前帧所属 BSS 的标识，而非设备物理 MAC。
4.3 避坑：Data 帧解析的 3 个经典陷阱
现象：Wireshark 显示一个 Data 帧的 Addr1 是
ff:ff:ff:ff:ff:ff（广播 MAC），但帧类型是 Data 而非 Management。
原因：这是PS-Poll（Power Save Poll）帧的伪装。Station 休眠后，AP 为其缓存数据。Station 醒来时发 PS-Poll 帧（Control Frame）索要数据，但某些驱动或固件会将其封装为 Data 帧发送，Addr1 设为广播地址以绕过过滤。
解决：检查帧子类型（Subtype），PS-Poll 的 Subtype=10，而非普通 Data 的 0。现象：抓包看到大量 “QoS Data” 帧，但网络并未配置 QoS。
原因：802.11e QoS 是向后兼容的。即使 AP 和 Station 都未启用 WMM（Wi-Fi Multimedia），只要帧头中 QoS Control 字段存在（Subtype=8），Wireshark 就解析为 QoS Data。这是协议演进的痕迹，非配置错误。
解决：忽略，或过滤wlan.fc.type_subtype == 0x28（QoS Data）与wlan.qos.tid == 0（Best Effort）区分真实 QoS 流量。现象：同一台手机，在不同 AP 下抓包，Data 帧的 Addr2（Transmitter）有时是手机 MAC，有时是 AP MAC。
原因：这是WMM-PS（Wi-Fi Multimedia Power Save）的 U-APSD 模式。当启用 U-APSD，Station 可在发送 Trigger Frame（如 QoS Null Data）后，立即接收 AP 缓存的多个帧，此时 Addr2 是 AP，因为 AP 是数据发送方。
解决：检查 AP 的 WMM 设置，确认是否开启 U-APSD；或用wlan.fc.retry == 0 && wlan.fc.moredata == 1过滤多帧聚合包。
5. 安全演进：WEP → WPA2-AES 不是“升级”，而是密码学范式的彻底重构
Wi-Fi 安全史，是一部从“用胶带绑住门”到“装生物识别+防撬合金门”的进化史。WEP（Wired Equivalent Privacy）不是弱，而是设计哲学错误：它试图用静态密钥模拟有线网络的物理隔离，却忽略了无线信道的广播本质。而 WPA2-AES 的胜利，不在于 AES 算法本身多强，而在于它用CCMP（Counter Mode with CBC-MAC Protocol）将加密与完整性校验融为一体，让攻击者连“猜一个字节”都做不到。
5.1 WEP 的三重原罪：IV 重用、RC4 弱密钥、无完整性保护
WEP 的密钥 = 24-bit IV（Initialization Vector） + 40/104-bit 静态密钥。问题全出在 IV：
- IV 空间太小：24-bit 仅 1677 万种可能。在 11Mbps 速率下，1 小时内就能耗尽所有 IV，必然重用；
- IV 明文传输：每个帧都明文携带 IV，攻击者截获两个同 IV 的帧，即可用 XOR 恢复明文异或值，进而破解密钥流；
- 无 MIC（Message Integrity Check）：攻击者可篡改密文任意字节，接收方无法察觉，因为 WEP 只做 CRC-32 校验（可被同步修改）。
2001 年，Fluhrer 等人发表论文，证明用 40000 个 WEP 帧即可在几分钟内恢复密钥。WEP 彻底死亡。
5.2 WPA/TKIP：过渡方案的妥协艺术
WPA（Wi-Fi Protected Access）是 IEEE 802.11i 标准的临时实现，核心是 TKIP（Temporal Key Integrity Protocol）：
- 动态密钥：每发 10000 个帧，AP 自动更换 Pairwise Transient Key（PTK）；
- MIC 强化：用 Michael 算法生成 64-bit MIC，虽比 CRC 强，但仍可被注入伪造（2008 年被破解）；
- 重放保护：TSC（TKIP Sequence Counter）防止帧重放。
但 TKIP 仍基于 RC4，只是“给 RC4 戴上手铐”。它最大的价值是向后兼容 WEP 硬件——老网卡刷个驱动就能支持 WPA，无需换芯片。这是商业现实对技术理想的让步。
5.3 WPA2-AES/CCMP：密码学的降维打击
WPA2 强制要求 CCMP，它基于 AES-128，但不是简单加密：
- CTR 模式加密：用 AES 加密计数器（Counter），生成密钥流，与明文异或；
- CBC-MAC 认证：对明文+附加数据（如地址、QoS）做 AES-CBC-MAC，生成 64-bit MIC；
- 原子性绑定：加密与认证共享同一个 AES 密钥，且 MIC 输入包含加密后的密文。攻击者无法单独篡改密文或 MIC。
// CCMP 加密伪代码（RFC 3610） void ccmp_encrypt(uint8_t *plaintext, uint8_t *aad, uint8_t *nonce, uint8_t *key, uint8_t *ciphertext, uint8_t *mic) { // 1. 构造 Counter Block (C0) 和 Authentication Block (A0) uint8_t C0[16], A0[16]; make_C0(nonce, 0, C0); // C0 = nonce || 0x00...00 || 0x01 make_A0(aad, plaintext_len, A0); // A0 = aad || len(plaintext) // 2. CTR 加密：C0, C1, C2... 生成密钥流 uint8_t keystream[16]; aes_encrypt(C0, key, keystream); xor(plaintext, keystream, ciphertext); // 3. CBC-MAC 认证：用 A0 和密文计算 MIC uint8_t mic_input[16]; memcpy(mic_input, A0, 16); aes_cbc_mac(mic_input, ciphertext, plaintext_len, key, mic); }注意：CCMP 的 MIC 是 64-bit，但 WPA2 要求 MIC 至少 64-bit，实际实现常用 128-bit（如 AES-CCM）。Wireshark 抓包时，若看到
wlan.radiotap.flags.fcs_bad == 0且wlan.wfa.ie.type == 0xdd（Vendor IE），基本可判定为 WPA2-AES。
5.4 避坑：Wi-Fi 安全配置的 3 个致命误区
现象：AP 设置为 WPA2-Personal，但手机连接后显示“安全性：WPA/WPA2”。
原因：AP 启用了混合模式（WPA/WPA2），即同时支持 TKIP 和 CCMP。虽然兼容老设备，但一旦有任一设备用 WPA-TKIP 连接，整个网络降级为 TKIP，失去 CCMP 保护。
解决：在 AP 设置中禁用 WPA-TKIP，只选 WPA2-AES（或 WPA3-SAE）。现象：企业网络用 WPA2-Enterprise，但员工手机连接后无法上网，日志显示 “EAP timeout”。
原因：RADIUS 服务器证书未被手机信任（Android/iOS 默认不信任自签名证书），EAP-TLS 握手失败。
解决：为 RADIUS 服务器申请公信 CA 签发的证书，或在手机端手动安装根证书。现象：WPA2-AES 网络，Wireshark 抓包显示大量 “Decrypted data”（已解密），但实际未输入密码。
原因：Wireshark 启用了 “802.11 Decryption” 功能，并配置了 PSK（Pre-Shared Key）。只要知道 PSK 和四次握手（4-Way Handshake）的前两个帧（ANonce/SNonce），Wireshark 就能推导出 PTK 并解密所有后续帧。
解决：关闭 Wireshark 的解密功能（Edit → Preferences → Protocols → IEEE 802.11 → Enable decryption），或确保 PSK 不泄露。
6. 从协议到现实：为什么读懂 Beacon 和 DS 字段，比背熟所有参数更重要
我曾经调试一个医院 PACS 影像系统的 Wi-Fi 传输故障，症状是：CT 扫描图像上传到服务器时，前 30MB 速度稳定在 40Mbps，之后骤降至 2Mbps，且持续 2 分钟。工程师们查遍了信道干扰、RSSI、重传率，甚至换了三台高端 AP，问题依旧。最后我导出 AP 的 Beacon 帧，发现一个细节：Beacon Interval 被设为 200ms，但 DTIM Interval 是 5。这意味着 Station 每 1 秒才醒来一次检查缓存数据。而 PACS 上传是长连接流式传输，AP 为节省 Station 电量，把大量 TCP ACK 包缓存在 TIM 中，直到 DTIM Beacon 到来才批量下发。Station 醒来后，瞬间收到数百个 ACK，TCP 窗口猛增，但下一秒又沉睡——造成吞吐量锯齿状波动。
我们把 DTIM Interval 改为 1，问题消失。没有改硬件，没有调功率，只是让 Beacon 的“日历”更精准地匹配业务节奏。那一刻我意识到：Wi-Fi 的所有参数，从来不是孤立的数字，而是 Beacon 帧里 Timestamp、DTIM、TIM、Capabilities 织成的一张动态时间网；DS 字段也不是地址标签，而是网络拓扑的实时快照——它告诉你此刻数据正穿越 AP 的桥接引擎，还是直连另一台 Station。死记硬背“802.11n 最大 600Mbps”，不如亲手用 Wireshark 解析一个 Beacon 帧，看懂它的 HT Capabilities 如何宣告 MIMO 流数，看懂它的 ERP 字段如何为 802.11g 保护机制埋下伏笔。
现在，每次部署新 AP，我强制自己做三件事：
- 用
iw dev wlan0 scan抓原始 Beacon，用tshark -r beacon.pcap -Y "wlan.fc.type_subtype == 0x0008" -T fields -e wlan.sa -e wlan.da -e wlan.ssid -e wlan.beacon.interval提取关键字段； - 对照抓包结果，检查 AP Web 界面的 DTIM、Beacon Interval、Channel Width 设置是否与 Beacon 帧一致；
- 在手机端用
adb shell wpa_cli status验
本文还有配套的精品资源，点击获取
