diff --git a/reports/2026-10-28-linksys-mx8500-wwan-recovery.md b/reports/2026-10-28-linksys-mx8500-wwan-recovery.md
index a2ca287..4c5b9b3 100644
--- a/reports/2026-10-28-linksys-mx8500-wwan-recovery.md
+++ b/reports/2026-10-28-linksys-mx8500-wwan-recovery.md
@@ -23,7 +23,7 @@
 | 接口 | 状态 | 处理 |
 |---|---|---|
 | wwan5（5G） | 已解决 | radio0 HE160 → HE40，观察 63 分钟无故障 |
-| wwan2（2.4G） | 已缓解，看门狗兜底 | radio1 HE40 → HE20，故障频率大幅下降；**下次编译固件加入 `CONFIG_HE_OVERRIDES`，对 wwan2 设置 `disable_he=1`**（见“未处理 / 后续”） |
+| wwan2（2.4G） | 初步解决，看门狗兜底 | radio1 HE40 → HE20，再去掉 `txpower='13'` 限制（现 29 dBm）后观察 41 分钟无故障、tx failed 约 0.1%，需更长时间确认。如果仍复发，下次编译固件加入 `CONFIG_HE_OVERRIDES`，对 wwan2 设置 `disable_he=1`（见“未处理 / 后续”） |
 | 两者 | 自动恢复 | 新增 `wwan-watchdog`，断流约 2 分钟内自动重连 |
 
 ## 排查结果
@@ -85,7 +85,7 @@ wifi up radio0
 
 代价：2.4G 热点从 40 MHz 降到 20 MHz，5G 热点从 160 MHz 降到 40 MHz。高带宽需求由 6 GHz 热点（radio2，HE160）承担，未改动。
 
-`txpower='13'` 保持不变。
+radio1 原有 `txpower='13'`，后来去掉了（见“验证”中的 txpower 一节）。
 
 注意：`wifi up radioX` 会断开该射频上的 STA。如果 SSH 正好走这条上联，命令可能执行到一半就断，应在路由器上放到后台执行（BusyBox 没有 `nohup`）：
 
@@ -176,6 +176,43 @@ wifi up radio0
 
 一分钟内 tx failed 从 182 涨到 853、速率掉到 MCS0，与最初的故障特征一致。两次都是断流约 1.5 分钟，看门狗自动恢复。同一时间 wwan5 正常（两条 SSID 走同一个 Nomadix 网关），说明是 2.4G 本机无线问题，不是上游故障。HE20 大幅降低了频率，但没有根治 wwan2。
 
+### wwan2：去掉 radio1 发射功率限制后
+
+00:41 删除了 radio1 的 `txpower='13'`，实际发射功率从 13 dBm 变为 29 dBm（radio0 原本就是 28 dBm）。
+
+观察期间发生了一次意外重启（见下方“事故”），所以观察从开机算起：00:44 – 01:25，共 41 分钟。
+
+| 项目 | HE20、13 dBm | HE20、29 dBm |
+|---|---|---|
+| 故障间隔 | 25 – 52 分钟一次 | 41 分钟内 0 次 |
+| tx failed / tx packets | 故障前一分钟内 182 → 853 | 56 / 42954（约 0.13%） |
+| tx 速率 | 故障时 HE-MCS0 8.6 Mbit/s | HE-MCS8 NSS2 206.5 Mbit/s |
+| 看门狗动作 | 每次故障都触发 | 0 次 |
+| mwan3 wwan2 状态变化 | offline / online | 只有开机时一次 online |
+
+结果很好，但 41 分钟比之前最长的 52 分钟间隔还短，不能确定已根治，需要观察一天以上。查看方法：
+
+```sh
+logread -e wwan-watchdog | grep -v crond
+logread | grep -E 'mwan3track.*wwan2 .*(offline|online)'
+```
+
+推测：发射功率低时，上行（STA → AP）的帧更容易失败，ath11k 的速率控制退到 MCS0 后没能恢复，进入“半死”状态。
+
+### 事故：误杀 procd 导致路由器重启（00:44）
+
+停止上一轮监控循环时，在路由器上执行了：
+
+```sh
+for p in $(pgrep -f 'sleep 60'); do pp=$(awk '{print $4}' /proc/$p/stat); kill $pp $p; done
+```
+
+本意是杀掉监控循环的 shell。但路由器上还有其他已被 init 收养的 `sleep 60` 进程，它们的父进程是 PID 1（procd），所以实际执行了 `kill 1`。procd 收到 SIGTERM 会重启系统。
+
+影响：路由器重启一次，两条上联断线约 1 分钟。重启后检查，所有设置都在（HE40 / HE20、去掉的 txpower、crontab、看门狗、路由规则脚本、mwan3.user），wwan2 / wwan5 自动上线，prio 100 规则自动加回。
+
+教训：不要按进程名批量 kill，更不要 kill 查到的父进程。停止远程监控只需结束本机的 ssh 进程。
+
 另外试过把 radio1 改成 `HT20`：只有热点变成 HT，wwan2 仍然以 HE 连接上游（`tx bitrate ... HE-MCS 6`），没有意义，已改回 HE20。
 
 ### wwan5：HE160 时看门狗触发一次，HE40 后稳定
@@ -215,6 +252,8 @@ radio0 仍为 HE160 时，wwan5 出现了同样的故障，看门狗自动恢复
 
 ### wwan2：下次编译固件时加入 HE overrides，对 wwan2 关闭 HE
 
+去掉 txpower 限制后 wwan2 暂未复发。如果长时间观察确认不再复发，这一步可以不做；如果仍复发，再按下面的方案处理。
+
 目前 wwan2 靠看门狗兜底：wwan2 只是副线路（mwan3 权重 3），断流期间流量会自动走 wwan5，约 2 分钟内恢复。
 
 要根治，需要让 wwan2 不用 HE（Wi-Fi 6）连上游，只用 HT（Wi-Fi 4）。wpa_supplicant 有网络级参数 `disable_he=1`，但现有固件不支持：
@@ -280,7 +319,6 @@ logread -e wwan-watchdog | grep wwan2
 ### 其他
 
 - **wwan5 登录过期**：看门狗只记录日志，不会自动登录。如果上游登录页能用简单的 HTTP 表单提交，可以再加自动登录。
-- **txpower**：radio1 的 `txpower='13'` 没有动。如果关 HE 后 wwan2 仍有问题，下一个可以试的是去掉这个限制。
 - 每天 07:00 的定时重启（`0 7 * * * reboot`）保持不变。
 
 ## 回滚