企业官网建设流程全解析

如果你搞过 ESP32 的 WiFi 调试，大概率经历过这种时刻：串口刷出一行又一行的错误码、日志里全是 "disconnected"、任务重启，但代码看起来完全没问题。这时候光靠串口日志已经不够了，因为你看到的是结果，不是过程。真正的问题发生在空中：ESP32 发出什么、路由器回了什么、握手走到哪一步断掉——这些信息只存在于 WiFi 的协议帧里，也就是所谓“WiFi 的语言”。用 Wireshark 去嗅探这些帧，就能把那段看不见的对话录下来，一帧一帧翻译给人看。

这篇文章就来拆解怎么用 Wireshark 抓取并读懂 ESP32 的 WiFi 通信数据。我会先把抓 WiFi 包的几种路线讲清楚，再带你从零搭建抓包环境，接着逐个拆解管理帧、数据帧、握手过程，最后用一次完整的排查实录演示“看不懂日志但抓包一目了然”的实战流程。不管你是在做物联网产品、搞智能家居，还是单纯想弄懂 802.11 协议，这篇文章都值得看完再动手。

1. 动手之前先搞清楚：抓WiFi包和电脑上普通抓包不是一回事

很多人在 Wireshark 里选了自己电脑的无线网卡就开始抓，结果发现包列表里全是些“莫名其妙”的帧，既看不到自己的流量，也不知道抓的有什么用。这是因为普通网卡默认只关心发送给自己的数据，而 WiFi 无线链路上的管理帧、广播帧它根本不收。要抓到空中的完整通信，必须先理解 WiFi 抓包和有线抓包的本质区别。

1.1 WiFi抓包的三种常见路线

针对 ESP32 的通信数据，我实际用过的路线有三条，各有适用场景。

第一条是“无线网卡监听模式”路线。让电脑上的一张支持监听模式的无线网卡进入 monitor 模式，在空中被动接收同一信道上的所有 802.11 帧。这条路的优点是全链路可见，从 Beacon 到 Probe、从认证到数据帧都能看到；缺点是需要额外的网卡，而且 WPA2 加密后看不到应用层明文。

第二条是“ESP32 自己抓包”路线。ESP32 的射频硬件本身带有 promiscuous 接收能力，可以写一段代码让芯片把所有收到的 802.11 帧转成 pcap 格式，通过串口传到电脑再导入 Wireshark。这条路的优点是不需要额外网卡，缺点是需要烧录抓包固件，而且如果设备本身同时在跑业务，抓包逻辑会抢占 WiFi 栈资源。

第三条是“路由器侧抓包”路线。如果路由器支持 shell 抓包（常见于各类刷了开源固件的路由器），可以直接在路由器的无线网卡上抓包，再把 pcap 导出来分析。因为路由器在驱动层面处理的是解密后的数据，所以能看到完整的 IP/TCP 报文；但缺点也很明显：它通常看不到无线侧的 Beacon、Probe 和重传细节。

对绝大多数“ESP32 连不上 WiFi”的排查，第一条路线最直观，也是本文的讲解重点。第二条路线作为补充，适合手边没有监听网卡、或者需要贴近设备本身去抓信号细节的情况。

1.2 监听模式这步为什么绕不开

普通网卡的“工作模式”里，有一个关键选项叫杂散接收，也就是常说的混杂模式（promiscuous mode）。在这个模式下，网卡不再只看发给自己的帧，而是把收到的所有帧都交给系统处理。WiFi 网卡对应的更强模式叫监听模式（monitor mode），它不仅能接收所有帧，还会把 802.11 头部、RadioTap 头部这些“无线链路特有信息”一并保留下来。

为什么要保留 RadioTap 头？因为 RSSI 信号强度、信道、噪声、帧速率、时间戳这些信息，普通 TCP/IP 抓包里没有，但排查 WiFi 问题时恰恰是最关键的。比如你想确认 ESP32 在某位置的信号到底是多少 dBm，单看软件的“WiFi 信号格数”不靠谱，看 RadioTap 里的 dBm 数值才是硬指标。这就是 Wireshark 能当“WiFi 语言翻译官”的前提：监听模式让它看到了完整的帧，RadioTap 让它知道每个帧“听得多不清楚”。

实现上有坑：Windows 自带网卡驱动对监听模式的支持非常糟糕，真正可用的方案基本都在 Linux 上。我的习惯是准备一张支持 monitor 的 USB 无线网卡，配合一台 Linux 主机，或者给电脑装上 Linux 虚拟机并直通 USB 网卡。别指望 Windows 下随便买个 USB 无线网卡就能成功开启监听，很多网卡驱动根本不开放这个能力。

1.3 硬件的兼容性检查清单

这里给一份我反复验证过的硬件检查清单，照着选基本不出错。

无线网卡要选“驱动能开 monitor、芯片方案支持包转发”的型号。这里有个省钱技巧：老款USB网卡（使用某些经典芯片方案）比新款更容易进监听模式，新款网卡虽然速率高，但驱动限制也多。确认方法是插上网卡后在 Linux 终端执行 iw list，看输出里是否有 “Supported interface modes” 中包含 monitor。看到 monitor 字样，才有抓包的基础。

ESP32 开发板不需要特殊的型号，常见开发板自带板载天线就够用。抓包时要把板子放在 AP 附近或者明确“弱信号区”，这样才能测出不同位置下的帧交互质量。另外，如果你需要抓 5GHz 频段的数据，一定要确认网卡和 ESP32 都支持 5GHz；不少 2.4G 网卡便宜，但面对 5GHz 网络就无能为力。

还有一条很容易忽略：抓包用的无线网卡一旦进入监听模式，它就失去了正常联网能力。所以电脑最好同时保留一个有线网口作为“管理网口”，否则一边抓包一边上网查资料都做不到。实在没有有线口，也可以用手机热点给电脑供网，但要保证这个热点和被抓的 AP 不在同一信道，否则监听网卡会被干扰。

2. 第一次抓包：让ESP32在我的Wireshark里现身

第一次抓 WiFi 包最怕的是抓了很久，打开文件却不知道抓到了什么。这里分享一下我总结的最小化操作流程，按步骤来，5 分钟内就能在 Wireshark 里看到 ESP32 主动发出的 Probe Request 帧。

2.1 3分钟搭建最小化抓包环境

环境准备：一台 Linux 电脑，一张支持 monitor 的 USB 无线网卡，一个 ESP32 开发板，一台路由器或手机热点当作 AP。

先把网卡切到监听模式。假设网卡识别为 wlan1，终端执行：

sudo ip link set wlan1 down sudo iw dev wlan1 set type monitor sudo ip link set wlan1 up sudo iw dev wlan1 set channel 6

这里 set channel 6 很关键。WiFi 2.4G 在多个信道上工作，监听网卡一次只能听一个信道，而 ESP32 连的路由器可能落在信道 6 上。如果你的设备在信道 1，监听信道 3，那你看到的只有零星广播帧，目标设备的帧都错过了。想自动锁信道，也可以先用手机 WiFi 扫描工具看一下周围网络落在哪个信道，再手动锁到对应信道。

接着打开 Wireshark，在捕获接口列表里选这个 monitor 网卡接口，双击开始抓包。这时候把 ESP32 上电并让代码执行 WiFi.begin("MySSID", "password")，如果一切正常，Wireshark 里会开始出现大量帧。

2.2 让ESP32按需产生“可读性”高的流量

抓包的时候，你希望 ESP32 做“高频动作”而不是静止待机。如果它已经连上一个网络、长期不发数据，那抓到的几乎只有周期发送的 Beacon，看了半天也不知道它在干嘛。正确做法是让 ESP32 执行一次完整的连接-断开循环。

我一般会先让代码里 WiFi.disconnect() 再 WiFi.begin() 连续循环。这样每次循环，ESP32 都会发出 Probe Request、接收 Probe Response、走一遍认证和关联流程，随后进入 4 次握手。这一整套流程在 Wireshark 里是非常清晰的一坨事件，一眼就能看到。

代码不需要多复杂，核心就这几行：

void setup() { WiFi.disconnect(); delay(100); WiFi.begin("MySSID", "password"); delay(5000); WiFi.disconnect(); } void loop() { WiFi.begin("MySSID", "password"); delay(5000); WiFi.disconnect(); delay(5000); }

抓完这一轮，整个链路里“ESP32 有没有扫描”“AP 有没有回应”“认证成不成”“握手到哪一步”全部有据可查。

2.3 第一眼应该看到的帧

抓起包后，列表里最显眼的通常是一堆 Beacon 帧，这是 AP 在周期性广播自己的存在。按 Wireshark 默认的着色规则，Beacon 通常是淡黄色。这个阶段你要确认两件事：一是抓到的帧确实带 RadioTap 头部，二是抓到的目标信道上有没有你要找的 AP。

如果 Beacon 里看不到目标 SSID，说明网卡锁的信道和 AP 不在同一个信道。此时可以按组合键 Ctrl+Alt+Shift+C 调出“捕获选项”，调整监听信道，或者返回终端重新 iw dev wlan1 set channel。

如果 Beacon 能看到 SSID，但抓不到任何来自 ESP32 的 Probe Request，多半是 ESP32 已经连上过这个网络、固件里保存了配置，不再主动探测。把 ESP32 复位一次、或者在代码里主动断开 WiFi，就会立刻看到它的 Probe 帧。

3. 看懂管理帧：WiFi世界里设备是怎么说话的

802.11 协议把帧分成三类：管理帧、控制帧、数据帧。管理帧负责“建立和维护连接关系”，对排查连接问题最有价值，因为它们大多不加密，Wireshark 里可以直接看到字段内容。下面几个常用过滤器，建议收藏。

3.1 Beacon帧：路由器在喊“我在这，来连我”

Beacon 帧是 AP 每隔 100ms 左右就会广播一次的“存在感宣告”。在 Wireshark 里用下面的过滤器可以只看 Beacon：

wlan.fc.type_subtype == 0x08

点开一个 Beacon，你能看到 SSID、支持速率、信道、加密套件、以及一些可选能力字段。对我这种经常跑现场的人来说，Beacon 最大的用处是定位“这个 AP 到底在哪个信道”“信号强度多少”“网络是否开放或加密”。

比如排查覆盖盲区，把抓包网卡放在不同位置各抓 30 秒，看同一个 AP 的 Beacon 对应 RadioTap 里的 dBm 数值变化，马上就知道哪里信号差、差多少 dB。这个比拿着手机到处走看格数直观得多。

3.2 Probe Request/Response：ESP32出门问路

当 ESP32 要主动连接一个 AP，或者仅仅是想扫描周围环境，它会发送 Probe Request 帧。这种帧带有发送设备的 MAC 地址，也可能带着想要连接的目标 SSID。Wireshark 过滤器：

wlan.fc.type_subtype == 0x04

Probe Request 是诊断“ESP32 到底有没有去找这个网络”的第一手证据。如果代码写错 AP 名，Probe Request 里就会带着错误的 SSID，一眼就能看出来。AP 收到后会回 Probe Response，过滤器：

wlan.fc.type_subtype == 0x05

如果只看到 ESP32 发 Probe Request，却看不到 AP 回 Probe Response，那基本说明信号太弱，或者 AP 侧拒绝了探测。别小看这个细节，很多“ESP32 老是 reconnecting”的问题根源就是某个角落信号质量太差，AP 根本听不到它。

3.3 Auth 和 Assoc：从敲门到进屋的完整过程

Probe 阶段之后是认证（Authentication）和关联（Association）。这两步像是敲门和登记。ESP32 发出 Authentication Request，AP 回 Authentication Response；如果成功，ESP32 再发 Association Request，AP 回 Association Response。过滤器：

wlan.fc.type_subtype == 0x0b || wlan.fc.type_subtype == 0x00 || wlan.fc.type_subtype == 0x01

• 0x0b：Authentication
• 0x00：Association Request
• 0x01：Association Response

分析这组帧时，重点看状态码（Status Code）。如果 Association Response 里 Status Code 不是 0，而是比如 17（AP 已满）、12（能力不匹配），问题就定位了。多数情况下，连不上的根因就藏在这些管理帧的状态码里，比串口日志里那句“Wifi disconnected”有用十倍。

3.4 以Wireshark过滤器为关键词快速筛选

当你抓到上万帧时，靠眼睛找目标设备很痛苦。我常用的筛选策略是先锁定设备 MAC：

wlan.addr == 30:ae:a4:xx:xx:xx

wlan.addr 只要目标 MAC 出现在帧的任一地址字段（源、目的、BSSID）就匹配，非常粗暴好用。然后在这个基础上叠加类型：

wlan.addr == 30:ae:a4:xx:xx:xx && wlan.fc.type == 0

这样就只剩管理帧。如果再加一个 eapol：

wlan.addr == 30:ae:a4:xx:xx:xx && eapol

你就能看到完整的四次握手过程。先把这些过滤器存在 Wireshark 的“显示过滤器”栏里，实战时切换效率高很多。

4. 数据帧才是干活的：从握手到上层协议

管理帧负责“建立连接”，数据帧才承载真正的业务流量，比如 ESP32 上发的 MQTT 消息、HTTP 请求。这部分要看懂，需要理解 802.11 数据帧的头部结构和加密带来的影响。

4.1 802.11数据帧的“信封结构”

数据帧有很多种，最常见的是普通数据帧（Subtype 0）和 QoS 数据帧（Subtype 8）。和以太网帧不同，802.11 数据帧头部里有四个地址字段，但这几个地址不一定是“源地址 + 目的地址”这么简单。关键在于 Frame Control 里的两位标志：To DS 和 From DS。

初次看这个表可能有点绕，但实际操作时你不需要每次都猜地址含义。Wireshark 会根据 To DS/From DS 自动把各个地址翻译成含义明确的列，比如 “Source”“Destination”“BSSID”。你知道这个对应关系，主要是为了看懂“为什么这个帧的源地址是路由器的 MAC，而目的地址不是 ESP32 的 MAC”——因为在 AP 向 ESP32 发包时，Address 1 是接收方，Address 2 才是 AP 自身。

还有一类容易被忽略的帧是 QoS Null 帧。它不带有效载荷，但很重要：ESP32 在省电模式下会用它告诉 AP“我要睡觉了”，AP 醒了会缓存数据；当 ESP32 发 QoS Null 通知“我醒了”，AP 再把缓存数据推过来。排查“ESP32 收不到下发的指令”时，看到设备频繁发 QoS Null 就有嫌疑。

4.2 想看应用层内容？WPA2下先做这一步

很多新手抓了一堆数据帧，发现点开全是乱码，payload 里看不到 HTTP、MQTT 的名字。这是因为 WPA2 对整个数据帧的 payload 做了加密，被动监听抓到的只能是一堆密文。想解开，有几条路。

路就是在 Wireshark 里配置解密。打开“Edit -> Preferences -> Protocols -> IEEE 802.11”，勾选 “Enable decryption”，填入 SSID 和 WPA2 密码（PSK）。只要 PSK 正确，Wireshark 就能自动解密加密帧，然后你就能用它解析上层的 TCP/IP 和 MQTT 内容。

这个过程之所以能解，是因为四次握手过程中 Wireshark 可以从 EAPOL 帧里算出成对密钥。如果你抓包时设备已经连上很长时间，错过了握手，可能抓不到足够的密钥信息，建议在抓包前重新触发一次连接，让四次握手重新发生。

另一个更省事的路是回到“路由器侧抓包”。路由器在驱动层收到帧时已经是解密后的以太网格式，直接 tcpdump 导出 pcap，加载到 Wireshark 就能看到完整应用层协议。如果你只是调试 MQTT 消息内容、不看无线细节，这反而是最快的方法。

4.3 用统计功能画出“通信肖像”

Wireshark 不只是抓包工具，它的统计面板能帮你把一堆帧变成直观图表。我常用两个功能。

第一个是“Statistics -> WLAN -> Traffic”。它会按 BSSID 列出各网络的使用流量统计。如果你怀疑“ESP32 是不是一直在盲目重传”，就按 BSSID 看发送速率和帧数，再叠加 wlan.fc.retry == 1 过滤器，统计重传帧占比。重传率太高通常表示信号差或信道拥挤。

第二个是“Statistics -> IO Graph”。可以以时间为横轴画一条吞吐曲线。比如测试 ESP32 每 5 秒上报一次 MQTT 数据，IO 图上应该能看到稳定的周期性峰值。如果某个时间段曲线消失，再对应看该时段有没有断网、重新握手，问题就能关联起来。

给我印象最深的一次，是查一块 ESP32 板子会间歇性卡死，IO Graph 显示每 20 秒左右总有一段 1 秒的空白。后来发现是设备频繁进入省电模式，等唤醒后 AP 缓存的大量 QoS 帧同时涌过来，芯片处理不过来导致看门狗复位。这类时序问题，全靠 IO Graph 才发现。

4.4 用过滤表达式锁定ESP32的具体流量

当你给 Wireshark 配置好 WPA2 解密后，就可以用 IP/TCP 层的过滤器了。假设 ESP32 的 IP 是 192.168.1.50，MQTT broker 是 192.168.1.100，那我通常会这么筛：

ip.addr == 192.168.1.50 && tcp.port == 1883

这样所有 MQTT over TCP 的报文一键到位。如果想看 DHCP 过程（ESP32 有没有拿到 IP、网关是谁）：

bootp || dhcp

这是排查“连上了 WiFi 但没有 IP”的好帮手。抓到 DORA 流程里哪一步缺失，问题就落在是 DHCP 服务器没响应、还是 AP 把广播挡了、还是设备发 DHCP Discover 时就已经被踢掉了。

还有一个很有用的过滤是看 TCP 的重传和乱序：

tcp.analysis.flags && ip.addr == 192.168.1.50

注意 TCP 层的重传和 802.11 层的重传不是一回事。前者是上层协议发现数据丢了所以再发，后者是 WiFi 链路层丢了帧所以重发。排查时要分清是 WiFi 空气环境差（链路层重传高）还是网络拥塞（TCP 重传高），两个过滤器分别看才能定位。

5. 一次完整排查实录：ESP32连不上路由器，问题藏在哪个环节

光讲理论不实战说明不了问题。这里分享一个我最近做的模拟排查案例，过程完全真实，设备代号就叫“模拟项目X”。

5.1 现场现象与我的初步判断

同事拿着一块 ESP32 开发板过来说：设备反复打印 “WiFi disconnected”，偶尔能连上，但过几十秒又掉线。他怀疑是路由器兼容性问题，理由是换了另一个路由器就能稳定连。我看了一眼代码，SSID 和密码写的是对的，波特率也正常。接着我没急着改代码，而是先搭了一套监听环境：USB 网卡锁在设备所在信道上，Wireshark 开抓，同时给 ESP32 上电触发连接循环。

初步判断是 RF 环境问题，但“环境差”这种结论不能靠猜。抓包的目的，是把“环境差”变成具体可观测的证据。

5.2 三步定位：看扫描、看认证、看握手

第一步，看 Probe。过滤 wlan.fc.type_subtype == 0x04，能看到 ESP32 在广播自己的探测请求。奇怪的是它发出的 Probe 里带的目标 SSID 是对的，而且 AP 的 Probe Response 也正常返回。这说明 ESP32 能听到 AP，AP 也能听到 ESP32，双向信号不是完全断开。

第二步，看 Auth 和 Assoc。过滤 0x0b、0x00、0x01。我抓到了 ESP32 发出 Authentication Request，AP 回了成功，随后 Assoc 也成功。到这里还没问题，链路层连接已经建立。

第三步，看 EAPOL。这是关键。过滤 eapol 后，我看到 AP 发出了 M1（握手第一包），ESP32 回了 M2，但很快 AP 突然回了一个 Disassociate 帧，然后流程从头开始。反复几次都是“M1->M2->M3 之前掉线”。

分析到这一步，问题基本清楚了。M3 是 AP 发给 ESP32 的最后一包，用于确认密钥安装完成。如果 M3 一直不出现，多半不是密码问题，而是 AP 侧主动中止了握手。结合 AP 在 M2 之后立刻 Disassociate 的行为，基本可以判定：AP 的加密套件或 PMF 设置与 ESP32 固件不匹配。

5.3 结论与修复动作

从抓包里确认问题不是密码、不是信号、不是扫描不到，而是 AP 在关联后拒绝继续握手。查了一下路由器设置，发现它强制开启了 WPA3-SAE，而这款 ESP32 的 WiFi 库只支持 WPA2-PSK。两者兼容性不佳，AP 就会在握手阶段直接把设备踢掉。

修复动作分两步：一是把路由器的加密模式改为 WPA2/WPA3 混合模式，或升级 ESP32 的 WiFi 库；二是如果产品要卖到别人的网络环境，最好在固件里做加密能力降级重试——先按 WPA3 连，断开后回退到 WPA2。这两步改完，再抓包验证，M3 正常收到，M4 正常返回，开始跑 DHCP，问题消失。

这次排查给我最大的启发是：看起来神秘的“连不上”，用 Wireshark 把 Probe、Auth、Assoc、EAPOL 四段流程逐一过一遍，几乎总能定位到某个具体的协议环节。串口日志只会告诉你“成功”或“失败”，抓包能告诉你“失败发生在哪一步、谁先拒绝谁、协议参数差在哪”。

6. 常见问题与避坑技巧

抓 WiFi 包这事，经验不足很容易在环境上浪费大量时间。下面把容易踩的坑集中列出来，有些是我自己交了学费才搞明白的。

6.1 抓包常见问题速查表

这张表是我平时调试时放在手边的速查清单。出现新问题时，先对号入座，再去查具体细节，比从头读一遍协议文档快得多。

6.2 容易被忽略的六条实战心得

第一，抓包时如果发现帧校验错误太多（wlan.fcs.status == 0），不要急着怀疑网卡坏了。大部分情况是信号太弱导致接收的帧不完整，或者周围干扰源过多。把这个当成“环境差”的一个定量指标，而不是失败抓包。

第二，要把“无线链路重传”和“TCP 重传”分开看。我之前遇到过一个业务卡顿，排查发现 TCP 重传几乎没有，但 WiFi 链路重传很高，说明问题出在空气链路，不是网络服务器。诊断顺序建议先看 wlan.fc.retry == 1，再看 tcp.analysis.retransmission。

第三，ESP32 自带的 promiscuous 抓包虽然方便，但它会把芯片置于极高频中断状态，不适合在业务生产环境长期挂机。临时采集 30 秒到 1 分钟的数据是它的舒适区，不要想着拿它当长期监听的“探针”。

第四，千万别贪心把网卡放在“自动信道”上。监听网卡自动扫信道会导致每个信道只待一小段时间，抓到的帧连续性和时序完全没法看。固定锁在目标信道，比自动扫频有效得多。

第五，做 WiFi 抓包时，尽量让 ESP32 和监听网卡保持在同一个小范围内，但要稍微拉开一点距离。太近了，两点之间的信号太好，反而暴露不了真实场景中的弱信号重传问题；太远了，又可能抓不到任何帧。距离 2-3 米是个不错的起点。

第六，也是我最想强调的：抓包文件一旦离开抓包现场，一定要用 Wireshark 的“File -> Export Packet Dissections”或 tshark 导出关键帧摘要，因为完整 pcap 可能很大，里面夹杂大量无关的 Beacon 和广播。分析时先过滤出目标 MAC，再导出 CSV 或文本，后续复盘才高效。

最后一个心得，算是我自己的小偏好：每次抓包前，先记录一下抓包时间、信道、AP MAC、ESP32 MAC、SSID 这五项信息，写在文件名里。比如 esp32_ch6_ap-xxxx_sta-xxxx_issue1.pcap。几周后回看这个文件，光从文件名就能知道当时的场景，省去很多回忆成本。这个习惯救过我不少次，强烈建议你也试试。