上午写代码写到一半,Wi-Fi 图标又断了。一分钟不到自动连回来。
这个症状我上一篇文章刚排查过,当时的结论是 Verizon G3100 路由器的 Self-Organizing Network(SON)在主动踢设备。关了 SON 以为问题解决了。
然而并没有。
旧诊断哪里错了
上篇文章的分析逻辑是:RSSI 在 8 秒内骤降 10dB → 路由器主动降低发射功率 → SON 在搞频段切换。这个推理链看起来合理,但我忽略了一个更底层的可能性:Wi-Fi 芯片固件本身崩溃了。
固件崩溃也会导致 RSSI 急剧下降——不是因为信号真的变弱了,而是芯片在重启过程中无法正常测量信号。表象一样,根因完全不同。
这次的日志:driver unavailable
断连发生在 11:27。直接查 airportd 日志:
/usr/bin/log show --start "2026-03-31 11:27:00" --end "2026-03-31 11:28:00" \ --style compact --predicate 'process == "airportd"' 2>&1 \ | grep -iE "driver unavailable|watchdog|link"关键的一行:
11:27:05 Driver Event: _bsd_80211_event_callback: driver unavailable (reason=0xe0823801, subreason=0xe3ff841c, flags=0x0)这不是路由器踢我,是 Mac 的 Wi-Fi 芯片固件触发了 watchdog 超时。reason=0xe0823801 是一个固件级别的错误码,表示 Wi-Fi 驱动在规定时间内没有响应,系统强制重置了整个无线子系统。
紧接着的事件链:
| 时间 | 事件 |
|---|---|
| 11:27:05 | Wi-Fi driver watchdog 触发,固件重置 |
| 11:27:07 | link down,no SSID(IOCTL 错误 0xe0822403) |
| 11:27:10 | en0 link INACTIVE |
| 11:27:17 | DHCP 回收 IP,media inactive |
| 11:27:22 | link 恢复 ACTIVE |
| 11:27:32 | DHCP BOUND,完全恢复 |
整个过程约 27 秒。比上次的 SON 断连稍短,但体感一样——SSH 断了,网页加载中断,IDE 的 LSP 连接丢失。
不止一次:今天崩了 61 次
查一下今天所有的 driver unavailable 事件:
/usr/bin/log show --start "2026-03-31 00:00:00" --end "2026-03-31 12:00:00" \ --style compact --predicate 'process == "airportd"' 2>&1 \ | grep "driver unavailable" | wc -l61一天 61 次固件 watchdog 崩溃。
列出时间分布:
/usr/bin/log show --start "2026-03-31 00:00:00" --end "2026-03-31 12:00:00" \ --style compact --predicate 'process == "airportd"' 2>&1 \ | grep "driver unavailable" | sed 's/\.[0-9]* .*//' | sort -u2026-03-31 00:19:042026-03-31 00:19:182026-03-31 00:50:21# ... 凌晨密集出现,每 15-30 分钟一次 ...2026-03-31 05:35:532026-03-31 05:51:382026-03-31 06:07:23# ... 清晨到上午继续 ...2026-03-31 08:36:14 ← 上篇文章记录的那次断连!2026-03-31 10:26:242026-03-31 11:27:05 ← 今天触发这次排查的断连注意 08:36:14 那个时间——正好是上篇文章里分析的那次”SON 断连”。现在看来,那次很可能也是固件 watchdog 崩溃,不是(或不完全是)SON 的锅。
两个 reason code 交替出现:
0xe0823801(subreason0xe3ff841c):最常见,watchdog 超时0xe0821804(subreason0x0):较少见,出现在凌晨 1 点和 2 点左右
凌晨的高频崩溃很可能跟 macOS 的 DarkWake 有关——系统在睡眠状态下会周期性唤醒 Wi-Fi 来维持网络连接(接收邮件推送、iMessage 等),每次唤醒都可能触发固件问题。
信号和硬件信息
当前连接信息:
Card Type: Wi-Fi (0x14E4, 0x4388)Firmware: wl0: Dec 6 2025 00:30:14 version 23.41.8.0.41.51.201Driver: IO80211_driverkit-1540.16 (Jan 27 2026)信号质量在不崩溃的时候其实很好:
LQM: rssi=-52dBm snr=34 txRate=864.7Mbps rxRate=1201.0Mbps txRetrans=14 beaconRecv=41/49-52 dBm 的信号、34 dB 的 SNR、864 Mbps 的发送速率——这些指标都很健康。不是信号差导致的断连,纯粹是固件自己抽风。
这是 macOS Tahoe 的已知问题
搜了一下 Apple 社区论坛,发现 macOS Tahoe 的 Wi-Fi 问题是广泛存在的:
- M4 MacBook Pro 用户报告升级 Tahoe 后 Wi-Fi 子系统不停重置,重装系统、Safe Mode 都没用
- M4 Pro MacBook Pro 在 Tahoe 26.3/26.3.1 上出现方向相关的 Wi-Fi 延迟飙升(从 1-2ms 到 600-2600ms)
- M4 Pro Mac Mini 的 Wi-Fi 每 20 秒断一次,Teams 通话完全没法用
- 各种 Apple Silicon Mac(M1-M4)升级 Tahoe 后出现 DHCP 分配失败
Apple 到目前为止没有正式回应这个问题,也没有发布针对性的修复。
WARNINGmacOS Tahoe 的 Wi-Fi 固件更新是写入硬件的。即使降级回 Sequoia,固件也不会回滚。而且降级过程有报告导致 Secure Enclave 故障需要送修。不建议尝试降级。
和 SON 问题的区分
现在回头看,SON 和固件 watchdog 崩溃可能是同时存在的两个问题:
| SON 踢设备 | 固件 Watchdog 崩溃 | |
|---|---|---|
| RSSI 变化 | 渐进下降(路由器降功率) | 突然归零(芯片重置) |
| 日志特征 | Auto-join trigger=retry (assoc) | driver unavailable (reason=0xe0823801) |
| 断连时长 | ~40 秒 | ~27 秒 |
| 频率 | 偶发 | 今天 61 次 |
| 修复 | 关闭路由器 SON | 等 Apple 修固件 |
关掉 SON 确实消除了路由器端的干扰,但 Mac 端的固件问题一直在。只是之前两个问题叠加在一起,关了 SON 后频率降低了,让我以为修好了。
能做什么
说实话,固件级别的 bug 用户能做的有限。以下是按可行性排序的缓解措施:
1. 清除网络偏好文件
社区反馈最有效的方法:
# 先关闭 Wi-Fi# 然后备份并移除这些文件sudo mv /Library/Preferences/SystemConfiguration/com.apple.airport.preferences.plist ~/Desktop/sudo mv /Library/Preferences/SystemConfiguration/NetworkInterfaces.plist ~/Desktop/sudo mv /Library/Preferences/SystemConfiguration/preferences.plist ~/Desktop/重启 Mac,重新连 Wi-Fi。这相当于重置整个网络栈的配置状态。不能修复固件 bug,但可能减少触发条件。
2. 关闭睡眠时的网络访问
凌晨的 61 次崩溃里有很大一部分发生在 DarkWake 期间。减少 DarkWake 触发 Wi-Fi 的频率:
System Settings > Battery > Options > Wake for network access → 关闭
牺牲:睡眠时收不到推送通知和 iMessage。对于开发机来说基本无所谓。
3. 排查 Tailscale 的影响
我的 Mac 跑着 Tailscale,有 13 个 utun 隧道接口。虽然没有直接证据说 Tailscale 触发了固件崩溃,但额外的虚拟网络接口增加了 Wi-Fi 驱动的负担。可以临时关闭 Tailscale 观察几天。
4. 等 Apple 更新
最终的修复只能靠 Apple 发布新的固件和驱动。当前固件版本是 2025 年 12 月 6 日的,驱动是 2026 年 1 月 27 日的。macOS Tahoe 26.3.1 没有解决这个问题,只能等 26.4 或后续更新。
调试命令备忘
这次排查新学到的命令,加到之前的备忘里:
查 Wi-Fi 固件 watchdog 崩溃:
/usr/bin/log show --last 24h --style compact \ --predicate 'process == "airportd"' 2>&1 \ | grep "driver unavailable"统计今天的崩溃次数:
/usr/bin/log show --start "$(date +%Y-%m-%d) 00:00:00" \ --style compact --predicate 'process == "airportd"' 2>&1 \ | grep "driver unavailable" | wc -l查 Wi-Fi 芯片和固件版本:
system_profiler SPAirPortDataType | grep -A2 -E "Card Type|Firmware"TIP如果你也在用 Apple Silicon Mac + macOS Tahoe,跑一下第一条命令看看有没有
driver unavailable事件。即使你没感觉到明显断连,固件可能已经在频繁崩溃——只是每次恢复得快到你没注意。
这台 G3100 和这台 Mac 的网络事故编年史
这是我第四次写 Wi-Fi/网络排查的文章了:
- 树莓派 WiFi “DHCP 失败” — Pi 的 WPA 握手超时 + NM 不重试,顺手搭了个 OpenWrt AP,踩了七个坑
- Tailscale DNS 死锁 — Tailscale 接管 DNS 后自身掉线,系统 DNS 全断,无法自愈
- MacBook Wi-Fi 断连(SON 篇) — 路由器 SON 功能主动踢设备
- 本文 — macOS Tahoe Wi-Fi 固件 watchdog 崩溃,一天 61 次
每次都以为找到了真正的根因,每次都发现还有更深的一层。网络排查就是这样——你以为问题在应用层,结果在传输层;你以为在传输层,结果在链路层;你以为在链路层,结果在固件里。
至少这次我确定问题在固件了。再往下就是硅片级别的 bug,那就真的只能换硬件了。希望不要走到那一步。