先聊个实际场景：办公室无线网时不时断一下，AP日志看着都正常，重启设备能管半天，再犯的时候你连原因都说不清。我碰到过类似问题，后来用抓包把WLAN工作流程从头到尾过了一遍，5分钟就锁定了问题所在——是某台终端的认证重试行为异常，反复和AP做关联协商，把正常的连接流程硬生生挤占了。从那以后我就养成个习惯：无线网络排查，除非明摆着是硬件物理损坏，否则第一件事就是抓包，把“终端从发现网络到正常上网整个流程”看清楚。

这篇内容就围绕两件事展开：WLAN工作流程到底分几个阶段、每个阶段有什么标志性帧；以及抓包概述里最核心的方法——抓什么、怎么抓、重点看什么。适合刚接触Wireshark、想做无线运维的网络工程师，也适合那些已经被间歇性断网、漫游慢、弱信号这类问题折腾过几次、想系统化排查思路的人。你可以把它当成一份带过滤器和排查思路的现场笔记。

1. WLAN的“一生”：终端从发现网络到正常上网要闯几关

平时我们说的“连上Wi-Fi”，在协议层面其实是拆成好几个阶段的。你看起来好像只是点了一下连接，然后输入密码，实际上帧的交互分了好几轮，每一轮没走通，表现出的故障都不一样。要抓包定位问题，先得把这套工作流程刻在脑子里。

1.1 第一关：网络发现——被动扫描和主动扫描

终端不知道周围有哪些可用网络，第一步是发现。802.11协议里给了两种方式：被动扫描和主动扫描。

被动扫描很简单，AP会周期性发送Beacon帧，相当于在信道里“广播自己的存在”。通常AP每隔100ms左右发一次，里面带着SSID、支持的速率、信道、加密方式、DTIM等一堆信息。终端把网卡设置成监听模式后，安静地收Beacon，就能知道周围有哪些网络。这个过程不需要终端发任何数据，所以也最隐蔽。

主动扫描则更常见，终端主动发Probe Request帧，然后等AP回Probe Response。拿手机或者笔记本连Wi-Fi时，你会看到设备不停地发Probe Request，里面可能带着一个目标SSID（单播探测），也可能不带SSID，就是单纯问“周围有谁”（广播探测）。AP收到后会根据自己的配置决定是否回应Probe Response，里面携带的信息和Beacon基本一致，额外还有AP自身的信号覆盖信息。

这里有个实战认知：如果终端说“找不到家里的Wi-Fi”，可以先抓包看这个频段上是不是一直有Beacon在发。如果Beacon正常但终端没扫描到，问题可能出在AP的信道配置和终端支持的频段不一致，比如AP配置在某个5G高信道，而终端对这个信道支持不好。反过来，如果Beacon都没有，那就要先怀疑AP射频模块或者天线馈线的问题。

另外我还习惯在抓包里加一列“Beacon间隔”，正常情况下间隔很稳，如果看到Beacon帧间隔忽大忽小，那多半是信道里的共享介质被占用严重，或者设备本身处理不过来。这个现象比丢几个数据包更容易被忽略，但往往是干扰问题的早期信号。

1.2 第二关：认证与关联——连接建立的“准入门”和“登记处”

扫描到网络之后，终端决定连接，接下来就是认证（Authentication）和关联（Association）。

认证阶段听起来很高大上，实际上在个人家庭网络里大部分情况是“开放系统认证”，也就是AP问一声“你要不要进来”，终端回一句“我要进来”，然后就过了。这个过程就两个帧：Authentication Request和Authentication Response，基本不承载什么实质性的鉴权工作，真正的密钥验证放在后面的四次握手阶段。

而在企业网络里，认证通常会使用802.1X、EAP等机制，那就复杂得多，涉及RADIUS交互、证书验证、EAPOL帧的多次往来。但即便企业网络，它的第一个“认证帧”本身也是开放系统认证打底，只是后续的802.1X认证会支配整个会话状态。

认证通过后才是关联（Association）。可以这样理解：认证是“确认你有资格进这个门”，关联是“在门口登记，给你发个号牌”。关联过程里，终端发Association Request，带上自己支持的能力（速率集、HT/VHT能力、是否支持802.11n/ac/ax等），AP评估后回Association Response，里面会有一个关键字段AID（关联标识符），相当于这个房间里的临时工号。拿到AID，才算真正“连上了”。

很多人把认证和关联混为一谈，排查时也容易搞混。见过不少案例：终端在Authentication阶段反复失败，看抓包全是一串Auth Response里的StatusCode不是0（成功），结果问题根源是AC上配置错了MAC白名单，把特定终端的认证给拒了。不抓包的线，只看到AP日志里“Authentication failed”一行字，很难进一步理解。

1.3 第三关：DHCP与数据交换——真正的上网起点

关联成功后，终端只会得到一个二层连接资格，还不会访问互联网，因为广播域和IP地址还没配置完成。

紧接着，终端就会发DHCP Discover，寻找网络里的DHCP服务器，经过Offer、Request、Ack三个步骤后拿到IP地址，才算具备网络通信的完整条件。别小看这一步，DHCP超时或者交互异常，会造成“Wi-Fi显示已连接但就是上不了网”的经典故障。

抓包看这个阶段时，我一般用dhcp过滤，直接看四步交互是否完整，顺便确认服务端地址是不是预期的网关。实际故障里，DHCP经常因为交换机端口VLAN配置错误、DHCP Snooping拦截、地址池耗尽而出问题。这些原因用抓包一眼就能看出来，不需要瞎猜。

DHCP之后，终端真正开始发送用户业务数据了，这时候802.11帧的“To DS/From DS”字段会发生变化，数据帧取代管理帧成为主角。相应的，如果后面发生漫游，终端到新AP时会重走认证、关联，然后可能重新获取或保留IP；如果掉电、主动断开，会有Deauthentication或者Disassociation帧出现。

所以你看，所谓的“工作流程概述”，在协议栈里其实是一条清晰的链路：Beacon/Probe → Auth → Assoc → DHCP（→ EAPOL四次握手）→ 数据交换 → 漫游/断开。每一个环节在抓包里都有对应的标志帧，哪一环断了，故障点就在哪一环。

2. 抓包前的三件准备：监听位置、信道选择和过滤思路

不少人一上来就点开Wireshark的“开始捕获”，结果抓到一堆莫名其妙的帧，过滤半天也不知道自己在看什么。这是因为无线抓包和有线抓包是两套逻辑，无线是共享介质，抓包前不做好准备工作，抓到的东西要么重复几百遍，要么缺关键帧。

2.1 要抓的包在哪？

先想清楚抓包位置。同一个无线事件，在AP侧抓和在终端侧抓，看到的视角完全不一样。

项目排查中，我最常用的是“第三方探针”方式：一台带监听模式网卡的笔记本，放在问题发生区域，监听对应信道。因为这个位置能完整看到空口上实际发生了什么，不受AP日志的限制。AP侧抓包虽然方便，但很多设备只提供管理面日志，不提供空口原始帧，而且AP自带的抓包往往看不到其他AP的Beacon，对排查干扰和漫游就有限制。

如果条件不允许，也可以在AP本机抓包，至少要选支持远程抓包或者信号镜像的设备，但要知道它的捕获范围是有限的。

2.2 无线网卡与监听模式配置

普通有线网卡抓包是即插即用，但无线网卡能不能看到802.11管理帧，要看它是否支持监听模式（Monitor Mode），以及驱动是否允许。Windows下有不少网卡驱动会过滤掉管理帧，Wireshark只能看到数据帧甚至什么都看不到；Linux下通过mac80211或特定驱动可以进入监听模式。

推荐的做法是，准备一张可进入监听模式的USB无线网卡，专门给抓包用。在Linux系统上，我常用的配置步骤大致是：

# 查看网卡是否支持monitor模式 iw list | grep -A 5 "Supported interface modes" # 将接口切换到monitor模式 sudo ip link set wlan0 down sudo iw dev wlan0 set type monitor sudo ip link set wlan0 up # 锁定具体信道（例如2.4G的6信道） sudo iw dev wlan0 set channel 6

切换完成后，Wireshark启动捕获，就能看到802.11帧了。注意，监听模式下网卡通常不能正常连接网络，所以最好用有线网卡连管理通道，或者先把抓包数据保存成pcap文件再离线分析，保证工作流不断。

Windows下的经验是，WinPcap/Npcap安装后，部分网卡可能显示为“普通无线网卡”，但捕获选项里无法看到monitor模式开关。这时候要么换网卡，要么用Windows下的专用抓包工具间接实现，但也依赖于驱动支持。所以做无线抓包尽量准备一台Linux试验机，成本低还不限驱动。

2.3 频段与信道：监听模式最容易被忽略的坑

无线抓包有个很基础但容易踩坑的地方：监听模式下你只能监听一个信道，不能同时监听2.4G所有信道，更不能同时抓2.4G和5G。

如果你不确定问题发生在哪个信道，可以先借用Wireshark的“信道扫描”方式粗略看看各信道占用情况，或者直接在多个频段各抓一个代表性信道。最常用的思路是：2.4G抓1、6、11信道里的一个（大多数场景至少覆盖这三个互通信道），5G抓36、40、44、48这类中央控制信道，或者根据现场AC设备配置确定工作信道。

锁定信道是个决定成败的小细节。不锁信道的话，网卡会在信道上跳来跳去，抓到的帧是各信道的碎片拼接，看起来五花八门，但没法完整还原某一个AP下终端的完整交互流程。曾经有同事拿着没锁信道的抓包文件来找我，说“为什么这么乱，完全看不出关联过程”——这就是典型的没锁定信道。

2.4 抓包过滤器先想好

无线抓包的数据量非常惊人，信道稍微忙一点，几秒钟就能弄出几千帧。如果不用过滤条件，分析效率极低。

Wireshark里有两类过滤：捕获过滤器（BPF语法，抓包阶段高效丢弃不需要的数据）和显示过滤器（展示阶段筛选）。无线抓包中我一般不用捕获过滤器，因为宁多勿缺，防止关键帧被提前丢掉，而是抓完后用显示过滤器来做筛选。

常用显示过滤器整理如下：

实战里我常常组合使用，比如想看某台终端从Probe到关联的完整过程，就过滤wlan.addr == XX:XX:XX:XX:XX:XX && wlan.fc.type == 0，再配合时间列，就能看到一系列管理帧的先后顺序。

3. 拆帧看流程：从原始802.11帧里读出的关键信息

很多教程喜欢把802.11帧结构从头讲到尾，实际动手时哪些字段最影响判断，可能并不明显。这里挑几个排查时几乎必看的字段讲透，顺便复盘一次关联过程的帧序。

3.1 帧头部：Frame Control和地址字段怎么读

802.11帧的最前面是Frame Control，2字节。别嫌它短，信息量极大。

Frame Control里有Protocol Version（目前固定为0）、Type（2bit，管理/控制/数据）、Subtype（4bit，具体帧类型）、To DS和From DS（各1bit，表示帧的方向）、More Fragments、Retry（这个很关键，重传帧会置1）、Power Management等。

以数据帧为例，To DS和From DS的组合可以提示帧的流向：00表示终端到终端的Ad-Hoc，01表示从AP发给终端，10表示从终端发给AP，11表示无线桥接场景。排查二层转发问题时，我会很关注这个字段，它决定了你要看的地址字段含义。

无线帧里有几个地址字段（Address 1/2/3/4），每个字段在转发链路里的角色不同。AP收帧时，Address1通常是AP自己的MAC（即收件人），Address2是发送方终端MAC，Address3是BSSID或目标MAC。AP发帧时，Address1是目标终端MAC，Address2是AP自身MAC，Address3通常是源MAC。记不住的话，可以这么想：无线帧和有线帧不一样，中间多了一个无线媒介，所以必须额外标出“这段无线链路两端是谁”。

看Frame Control时我用一个土办法：直接选中Wireshark里的Frame Control字段，展开显示就能看到各位的解释，不用手算二进制。真正的价值在于理解Retry标志：如果一个管理帧或者数据帧带着Retry=1，并且反复出现，说明空口上对端没收到ACK，很可能是信号边缘或者干扰导致的丢帧。这是现场排查里最有用的信号之一。

3.2 Beacon帧内部剖解：SSID、RSN、速率集、信道号

Beacon帧是了解AP配置状态的窗口。展开一个Beacon帧，你能看到一串信息元素（Information Element，简称IE），其中几个排查必看：

• SSID元素：AP广播的名字。隐藏SSID时Beacon里不携带SSID，但Probe Response里会有。
• DS Parameter Set：当前信道编号。如果发现Beacon信道和预期不符，说明AP射频配置可能被人改过，或者自动信道选择功能把信道切了。
• Supported Rates和Extended Supported Rates：速率集。老设备和新型设备协商速率时会不会出问题，可以先看这里。
• HT Capabilities / VHT Capabilities / HE Capabilities：对应802.11n/ac/ax能力。终端连不上高规格速率时，需要看AP是否真的打开了这些能力。
• RSN信息：里面会带有认证类型、加密套件、AKM套件等。如果你的终端连接时提示“密码不对”，但输入的密码确认无误，一定要看看RSN里的加密套件是否匹配，比如AP强制WPA3，但终端只支持WPA2时，握手阶段就会失败。

Beacon里携带的信息越是丰富，越能看出AP的配置倾向。有一次现场反馈说5G信号下某些终端速率上不去，我抓包一看，AP的Beacon里VHT Capabilities只有80MHz频宽支持，没有160MHz，而终端能力是160MHz，两个端能力不匹配，协商出来自然只是80MHz。这个结论直接指导了配置修改，问题随之解决。

3.3 关联过程的一次完整抓包复盘

下面模拟一次典型的终端连接过程，用帧序的形式把它串起来。这个帧序在实际项目里几乎天天能见到，只是终端型号不同、AP品牌不同，细节稍有差异。

上面第1到第6步都属于管理帧，Wireshark里过滤wlan.fc.type == 0后能很清楚地看到，几乎是一对一对出现的。如果看到第3步和第4步之间夹了一大堆重传，就要考虑空口质量问题。

四个EAPOL密钥帧是验证密钥协商是否正常的关键。它的实现方式是：AP先发一个EAPOL Key帧给终端，里面带Anonce；终端回一个带Snonce的帧，同时带上MIC；AP验证MIC后，再发第三个带GTK的帧；终端回第四个帧确认。四个帧走完，加密链路建立，数据帧才会开始加密传送。如果卡在第1帧或第2帧，一般是密码套件不匹配或终端配置问题；如果卡在第3帧以后，有可能是AP密钥传递超时，或者广播组密钥更新导致的周期性问题。这方面能讲的点很多，但记住核心判断顺序就够了。

4. 实战排查思路：弱信号、漫游慢、干扰，三大典型问题怎么用抓包定位

流程和帧结构是基本功，真正考验人的是实际问题怎么通过这些帧得到答案。这里挑三个最常见的无线网络投诉场景，讲讲抓包思路。

4.1 弱信号申诉与重传率分析

用户投诉“信号满格但网速很慢”，这是最经典的一类问题。信号满格是终端UI显示的，不代表空口质量好。抓包后第一件事是确认RSSI，Wireshark里可用wlan_radio.signal_dbm或者radiotap.dbm_antsignal字段查看信号的强度值。RSSI是负数，数字越小信号越弱，比如-45dBm属于优秀，-75dBm已经比较差，-85dBm以下基本属于不可用了。

除了看RSSI，更要关注重传率。在Wireshark里，只要RadioTap头部元数据完整，就能看到wlan_radio.retries或直接用“分析→统计→流量图”观察。实操上，我会用显示过滤器筛出某个终端的帧，然后统计Retry标志为1的帧占比，正常占比应该在5%以内，超过10%就要警惕，超过20%你的无线质量基本已经很差了。

重传率高的诱因不只是弱信号，干扰也一样，甚至AP负荷过高也会导致来不及处理。所以第二步是用管理帧的Beacon信息做交叉验证：如果同一信道能收到好几个其他AP的Beacon，且功率都比较强，那大概率是同频干扰或信道重叠；如果Beacon干净但重传高，则要考虑信号弱或硬件问题。

4.2 漫游慢：不是切换瞬间慢，而是“想走没走成”

跨AP漫游在办公室、园区网里特别常见。用户常常抱怨“走到另一个房间视频卡5秒”，表面上看只是切换耗时，其实根因往往在漫游决策滞后。

终端漫游的决策通常由终端自己主导，它需要持续扫描邻信道，发现信号更好的AP才发起重关联。抓包时如果只盯着当前AP的帧看，会很奇怪：完全看不到切换行为。正确做法是把问题区域附近的AP MAC都列出来，过滤wlan.ta == 当前AP_MAC || wlan.ta == 目标AP_MAC，再看终端发的Probe Request是否出现。

一个典型的“漫游慢”抓包特征：终端已经在一个角落，RSSI低到-80dBm，却迟迟不发Probe Request，或者发了好几个间隔都很长的Probe，直到彻底丢包才切换。这说明终端的扫描机制过于保守，不是AP能直接解决的，只能通过提升AP间切换参数优化、减少环境盲区来缓解。而另一类特征是Probe正常、重关联也发了，但新AP回了Association Response之后，上层认证/AC下发配置超时，导致切换中断。这时要看EAPOL和DHCP是不是卡在下行方向，通常是AP间配置不一致或AC策略问题。

漫游慢的问题，我最常给的建议是抓包时一定要加时间戳和GPS坐标（如果现场允许），至少得记录终端走过的轨迹，不然很难把漫游发生的位置和抓包帧关联起来。

4.3 干扰类问题的证据链

无线干扰是最难跟用户解释的问题之一，因为“看得到信号，但体验很差”。抓包可以为干扰建立一条比较完整的证据链，避免空口争执。

抓包证据可以从几方面入手：

• 非本网Beacon密度：在同一信道抓到大量来自其他SSID的Beacon，且这些SSID不在你的管理范围内，说明信道里存在外部AP占用。
• 非WiFi干扰（微波炉、蓝牙、无线摄像头等）：这些设备通常不产生802.11帧，Wireshark里看不到直接证据，但能看到整体噪声。如果RadioTap信息里有Signal quality和Noise相关字段，可推定信噪比明显低于正常值。
• 信道利用率：大量控制帧如CTS、RTS交互异常频繁，或者数据帧的重传率整体偏高，也侧面说明信道竞争激烈。

有一次我处理楼宇无线卡顿的投诉，抓包一看，2.4G的信道上充斥着十几个陌生SSID的Beacon，信道利用率长期接近100%，而目标AP自身根本没有多少数据业务。这个结论拿出来，用户自然就理解了为什么“信号满格但还是卡”——信号不是问题，介质太挤才是。

5. 进阶习惯：三个常见误区与我保留的分析习惯

做无线抓包分析时间长了，发现很多同行会在同样的地方翻车。这里直接说误区，顺带讲讲我现在养成的分析习惯。

5.1 误区一：只看数据面，不看控制、管理面

有人抓包只盯着数据帧，觉得管理帧“不过是一堆信标而已”，结果面对连接建立失败、DHCP超时这些问题时一头雾水。

我的建议是，分析开始时先按帧类型比例过一遍：管理帧、控制帧、数据帧各占多少。正常情况下管理帧和数据帧的比例有一定规律，如果管理帧疯涨，比如Beacon或者Probe请求异常密集，至少说明空口上存在大量扫描或AP故障循环。再进一步，把同一终端的认证失败次数统计一下，能直接判断是配置因素还是环境因素。这一步往往比分析几十万条业务流量更能快速找到突破口。

5.2 误区二：忘记考虑捕获位置对结果的扭曲

抓包结论没有绝对客观，不同抓包位置看到的结果不同。举个例子，你在AP旁抓信号，RSSI也许是-50dBm，但在投诉用户所处的位置，同样一个帧可能到-80dBm。所以做现场抓包时，我会养成记录抓包位置和天线的习惯，并且在报告中注明“该结果反映抓包点空口情况”。

如果抓包点和问题发生点差距较大，宁可多跑几次，把探针放到关键位置再抓。一次抓完下结论，容易把空口差异误判成AP故障。

5.3 误区三：把一次快照当成长期结论

无线环境是实时变化的，一天中高峰和低谷的空口状态差异极大。抓包只代表抓包时段的状态，不能覆盖长期趋势。

我现在的做法是：如果条件允许，抓包至少持续15到30分钟，覆盖业务高峰时段；如果只能短抓，就在结论里标明局限性，别把一次抓包的结论当“终极答案”。某些间歇性故障，短抓大概率正好错过，需要多次定点抓包才能找到规律。

5.4 一个有用的习惯：把抓包导出为CSV快速统计帧类型分布

Wireshark自带“统计协议分级”和“统计I/O图”，但如果你想对一段长时间抓包做快速分拣，我习惯用tshark将关键字段导出成CSV，再做轻量统计。比如统计某终端发出的所有管理帧子类型分布，一个命令就能搞定：

tshark -r capture.pcap -Y "wlan.addr == 00:11:22:33:44:55" -T fields -e frame.time_epoch -e wlan.fc.type -e wlan.fc.type_subtype -E separator=, > stats_ap_client.csv

拿这个CSV在Excel里做个数据透视，几秒钟就能看出重传比例、管理帧集中度、信令频率，比一帧一帧翻高效得多。这个习惯帮我少挨了不少折腾，后续遇到大型巡检或者疑难杂症，底稿都是这样整理出来的。

从事无线网络运维这些年，我最大的心得就是：无线问题十有八九不是“拍脑袋”能猜中的，而是要靠抓包还原现场。WLAN工作流程就那么几个环节，抓包概述也就是抓位置、锁信道、过滤帧、拆关键字段这几板斧。当你把每一条异常都能对应到具体某个阶段、某个字段的时候，再难缠的无线故障也会变得有条理。下次遇到断连或者卡顿，别急着重启AP，先把抓包流程走一遍——大概率会有不一样的发现。