3、MAC层连接问题：MAC地址过滤、关联拒绝、认证失败、速率协商失败
各位做WiFi开发的同行，咱们接着聊。上一章我们把扫描阶段的问题捋了一遍，设备能看见AP了，接下来就该“敲门”了——也就是MAC层的连接过程。
这一层的问题，说白了就是设备跟AP之间“对上暗号”的过程出了岔子。我这些年排查过的连接失败案例，至少有一半都卡在这一步。你想想看，扫描都过了，信号也看到了，就是连不上，多让人抓狂。
MAC层连接，核心就四件事：认证、关联、速率协商，以及AP端可能存在的MAC地址过滤。任何一个环节出问题，设备就只能在“已保存”状态里打转，永远拿不到IP。
核心观点：MAC层连接失败，抓包看Management Frame的Status Code，比看日志快10倍。我个人的习惯是，遇到连不上的问题，先开抓包工具，直接过滤 wlan.fc.type_subtype == 0x00 || wlan.fc.type_subtype == 0x01 || wlan.fc.type_subtype == 0x02，看AP返回的Status Code是多少。
3.1 MAC地址过滤：AP端的“门禁系统”
MAC地址过滤，是AP最基础的访问控制手段。说白了，就是AP维护一个白名单或黑名单，只有MAC地址在名单上的设备才让连。
我在项目中遇到过好几次，客户反馈“WiFi信号满格，就是连不上”。我过去一看，AP的MAC过滤列表里根本没加这个设备的MAC。嗯，这种问题最隐蔽，也最容易被忽略。
排查技巧：如果设备能扫描到AP，但连接时立即被拒绝（通常1-2秒内），优先检查AP的MAC过滤设置。我建议在AP后台查看“无线MAC过滤”或“访问控制”列表，确认设备的MAC地址是否在白名单中。
MAC地址过滤的典型表现：
- 白名单模式：设备MAC不在列表中，AP直接丢弃认证请求或关联请求。抓包能看到AP回复
Deauth或Disassoc，Reason Code通常是0x0001（Unspecified reason）。 - 黑名单模式：设备MAC在列表中，AP同样会拒绝连接。抓包表现类似，但Reason Code可能不同。
注意：有些AP的MAC过滤是“静默拒绝”——AP根本不回复任何帧，设备会一直重试直到超时。这种情况最容易误判为“信号问题”或“AP死机”。我曾经被这种坑过，排查了半天才发现是MAC过滤没加。
3.2 认证失败：密码对不上，还是算法不匹配？
认证失败，是MAC层最常见的连接问题。设备发送 Authentication Request，AP回复 Authentication Response，如果Status Code不是0，那就是认证失败了。
认证失败的常见原因：
| Status Code | 含义 | 常见原因 |
|---|---|---|
| 0 | 成功 | 认证通过 |
| 1 | Unspecified failure | AP内部错误，或MAC过滤拒绝 |
| 2 | Capabilities mismatch | 设备与AP的能力集不匹配（如WPA版本） |
| 3 | Reassociation denied | 重关联被拒绝（通常因漫游场景） |
| 4-9 | 其他认证失败 | 密码错误、算法不匹配等 |
| 13 | Invalid authentication IE | 认证信息元素无效（如WPA2/WPA3混用） |
我个人习惯，遇到认证失败，先看AP的日志。很多企业级AP会记录“Authentication failure: wrong password”或“Unsupported authentication algorithm”。如果AP日志不详细，那就抓包看Status Code。
举个例子，有一次一个客户说“手机能连，但智能家居设备连不上”。我抓包一看，智能家居设备发的是 Open System Authentication，但AP配置的是 WPA2-PSK。设备根本不支持WPA2，认证算法就不匹配。嗯，这种问题，换设备或者改AP配置才能解决。
实战经验：WPA3的SAE认证，对设备兼容性要求更高。我遇到过一些老设备，明明支持WPA2，但AP开了WPA3过渡模式后，设备认证就失败了。抓包看，设备发的是 SAE Commit，但AP回复 SAE Reject，Status Code是 0x004C（SAE authentication failure）。这种问题，要么升级设备固件，要么关闭WPA3。
3.3 关联拒绝：AP说“我不带你玩”
认证通过了，设备开始发 Association Request。如果AP回复 Association Response 的Status Code不是0，那就是关联被拒绝了。
关联拒绝的常见原因：
- AP已达最大关联数：很多家用AP限制同时连接的设备数量（通常是16-32个）。如果连满了，新设备就会被拒绝。抓包能看到Status Code是
0x0011（Association denied because AP is unable to handle additional associated stations）。 - 速率集不匹配：设备支持的速率AP不支持，或者AP要求的速率设备不支持。Status Code通常是
0x0012（Association denied due to unsupported rates）。 - AP配置了白名单/黑名单：有些AP在关联阶段才做MAC过滤，而不是在认证阶段。表现就是认证通过了，但关联被拒绝。
排查技巧：关联拒绝后，设备通常会重试几次。如果一直失败，抓包看AP回复的Status Code。如果是 0x0011，去AP后台看“已连接设备数”；如果是 0x0012，检查设备支持的速率集和AP配置的速率集是否一致。
3.4 速率协商失败：WiFi的“语言不通”
关联成功后，设备和AP会进行速率协商。这个过程在802.11n/ac/ax中尤其复杂，涉及HT（High Throughput）、VHT（Very High Throughput）、HE（High Efficiency）能力集的交换。
速率协商失败，说白了就是设备说“我能跑80MHz频宽”，但AP说“我只支持20MHz”，或者设备说“我支持MCS 9”，但AP说“我只能到MCS 7”。双方能力不匹配，连接就会不稳定，甚至直接断开。
我遇到过最典型的案例：一款智能摄像头，连接802.11n的AP没问题，但连802.11ac的AP就频繁掉线。抓包发现，摄像头在Association Request里声明支持HT（802.11n），但AP在Association Response里要求使用VHT（802.11ac）。摄像头不理解VHT，双方协商失败，AP直接发Deauth。
速率协商失败的常见场景：
| 场景 | 原因 | 排查方法 |
|---|---|---|
| 设备不支持AP的频宽 | AP强制80MHz，设备只支持20MHz | 抓包看HT/VHT Capabilities中的Channel Width字段 |
| MCS索引不匹配 | AP要求MCS 8-15，设备只支持MCS 0-7 | 检查设备支持的MCS集，AP是否开启了HT40+/- |
| GI（Guard Interval）不匹配 | AP要求Short GI，设备只支持Long GI | 抓包看HT Capabilities中的Short GI字段 |
| 802.11n/ac混用问题 | AP强制ac only，设备只支持n | 检查AP的无线模式设置 |
注意：有些AP在速率协商失败后，不会立即断开连接，而是降速到最低速率（如1Mbps）。这种“假连接”状态最坑人——设备显示已连接，但实际无法通信。我曾经排查过一个智能门锁的案例，门锁显示WiFi已连接，但APP就是控制不了。抓包发现，门锁和AP协商到了1Mbps，根本跑不动数据。
3.5 综合排查思路：三步定位MAC层问题
好了，上面把四个问题都讲了一遍。实际排查时，我建议按这个顺序来：
- 第一步：抓包看Management Frame。过滤
wlan.fc.type_subtype == 0x00 || wlan.fc.type_subtype == 0x01 || wlan.fc.type_subtype == 0x02，看认证和关联的Status Code。如果Status Code不是0，直接定位问题类型。 - 第二步：检查AP配置。如果Status Code是0但连接还是失败，去AP后台看MAC过滤、最大关联数、无线模式（b/g/n/ac/ax）、频宽设置、速率集。
- 第三步：检查设备能力。如果AP配置没问题，抓包看设备的Association Request里的HT/VHT/HE Capabilities，跟AP的Capabilities对比，看哪里不匹配。
我的经验：80%的MAC层问题，抓包看Status Code就能定位。剩下20%，需要对比设备和AP的能力集。我建议在开发阶段，就把设备和AP的Capabilities信息打印出来，方便调试。量产之后，至少要在日志里记录连接失败的Status Code和Reason Code。
嗯，MAC层的问题就聊到这里。这一层是WiFi连接的“敲门砖”，门敲不开，后面的事都白搭。下一层，我们该聊聊网络层的问题了——DHCP和IP地址获取，那又是另一番风景。