Cudy TR3000 report: wwan2 enabled, source routing rules, 2.4G HE20

reports/2026-10-28-cudy-tr3000-wwan-watchdog.md

@@ -1,4 +1,4 @@
-# Cudy TR3000：部署 Wi-Fi 上联看门狗与日志优化
+# Cudy TR3000：部署 Wi-Fi 上联看门狗、双上联策略路由与日志优化
 
 - 日期：2026-10-28
 - 设备：Cudy TR3000 256MB v1（`cudy-tr3000.tail694d4.ts.net`，远程）
@@ -10,16 +10,20 @@
 
 Linksys MX8500 上发现 Wi-Fi 上联（STA）会卡在“已关联但发不出包”的状态，且不会自动恢复（见相关报告）。本次把同一套看门狗和日志设置部署到 Cudy TR3000，并检查它是否存在同样的问题。
 
-这台路由器是远程设备，唯一在用的上联就是 Wi-Fi。改 Wi-Fi 设置会导致一段时间断线，所以只做了不影响 Wi-Fi 的改动。
+这台路由器是远程设备，上联只有 Wi-Fi。改 5G 设置会断开 wwan5、导致远程断线，所以 5G 只做了不影响 Wi-Fi 的改动。
+
+部署完成后，wwan2 被启用，变成两条上联同时在线。随即发现 mwan3 的路由问题（见“启用 wwan2 后的问题”），并做了相应修改。
 
 ## 现状
 
 | 接口 | 设备 | 射频 | 上游 | 状态 |
 |---|---|---|---|---|
-| wwan5 | `phy1-sta0` | radio1（5G） | eduroam（WPA2-Enterprise，PEAP/MSCHAPv2） | 在用，mwan3 online |
+| wwan5 | `phy1-sta0` | radio1（5G） | eduroam（WPA2-Enterprise，PEAP/MSCHAPv2） | 在用，mwan3 online，权重 80 |
-| wwan2 | `phy0-sta0` | radio0（2.4G） | eduroam | `wireless.wifinet2.disabled='1'`，未启用 |
+| wwan2 | `phy0-sta0` | radio0（2.4G） | eduroam | 00:10 启用，mwan3 online，权重 50 |
 | wan | `eth0` | — | 有线 | 无载波，未使用 |
 
+两条 eduroam 上联拿到的是不同网段：wwan5 `172.27.64.0/20`（网关 172.27.64.1），wwan2 `172.27.80.0/20`（网关 172.27.80.1）。mwan3 策略 `balanced` 按权重在两条之间分配连接。
+
 注意射频编号和 MX8500 相反：这台的 5G 是 radio1 / phy1，2.4G 是 radio0 / phy0。
 
 5G 射频上同样存在热点与 STA 频宽不一致：
@@ -43,6 +47,39 @@ Linksys MX8500 上发现 Wi-Fi 上联（STA）会卡在“已关联但发不出
 
 结论：mt76 驱动目前没有表现出 ath11k 的“半死”问题。频宽不一致本身不一定会触发故障。
 
+## 启用 wwan2 后的问题：绑定接口的流量被 mwan3 分到另一条上联
+
+wwan2 启用后，看门狗使用的检测方式（`ping -I <设备>`）出现大量失败：
+
+| 测试 | 结果 |
+|---|---|
+| `ping -I phy0-sta0`（wwan2）1.1.1.1 | 3/3 失败 |
+| `ping -I phy0-sta0`（wwan2）8.8.8.8 | 时通时不通 |
+| `ping -I phy1-sta0`（wwan5） | 正常（启用 wwan2 的瞬间因防火墙重载短暂失败） |
+| 不绑定接口的普通 ping、按源 IP 绑定的 ping | 正常 |
+| `iw` 链路状态 | 正常，HE-MCS 11，不是无线卡死 |
+
+证据：
+
+- wwan2 这次 ping 的 conntrack 条目带的是 `mark=16128`（0x3f00），不是 wwan2 的 0x500，且 `[UNREPLIED]`。
+- `phy0-sta0` 的邻居表里出现 `1.1.1.1 FAILED`、`8.8.8.8 FAILED`：路由器把公网地址当作直连地址，直接在 Wi-Fi 上发 ARP。
+
+原因：本机发出、绑定到某个设备的流量，经过 mwan3 的 OUTPUT 钩子时会被打上 mark，mark 由 `balanced` 策略决定，可能指向另一条上联的路由表。查到的路由出口和绑定的设备不一致时，内核找不到可用路由，就退化成直连 ARP，包发不出去。时通时不通，是因为不同连接被分到了不同的上联。
+
+后果：
+
+1. **看门狗误判**：wwan2 实际可用，却会被判定为“不通”而强制重连。发现问题时，看门狗的下一次运行在 00:12，已在 00:11:43 先暂停了它的 cron 任务，修好后才恢复，未发生误触发。
+2. 本机其他绑定接口的程序（mwan3track 自己有处理，不受影响）也可能受影响。
+
+验证：手动添加源地址规则后，两条上联、两个探测地址各测 3 轮，12/12 全部通过：
+
+```sh
+ip rule add from 172.27.85.164 table 5 prio 100   # wwan2
+ip rule add from 172.27.76.50  table 3 prio 100   # wwan5
+```
+
+MX8500 上的 `99-fix-same-subnet-routing` 做的就是这件事：按源地址把流量固定到对应上联的路由表。prio 100 排在 mwan3 的 fwmark 规则（2003、2005）之前，所以优先生效。
+
 ## 修改内容
 
 ### 1. 部署看门狗 `/usr/sbin/wwan-watchdog`
@@ -66,7 +103,7 @@ Linksys MX8500 上发现 Wi-Fi 上联（STA）会卡在“已关联但发不出
 | 不通，第 4 次 | `wifi up radio1` |
 | 之后仍不通 | 每 10 次检测重启一次射频 |
 
-wwan2 当前未启用，`ifstatus wwan2` 不是 up，看门狗会直接跳过它。以后启用 wwan2 不需要改脚本。
+接口未 up 时看门狗会跳过它，所以 wwan2 启用前后都不需要改脚本。但两条上联同时在线时，必须配合第 3 项的源地址规则，否则会误判（见上一节）。
 
 相关改动：
 
@@ -80,10 +117,37 @@ wwan2 当前未启用，`ifstatus wwan2` 不是 up，看门狗会直接跳过它
 
 `system.@system[0].log_size` 从 128 改为 1024（KB），出故障时能回溯更久的记录。
 
+### 3. 部署 `/etc/hotplug.d/iface/99-fix-same-subnet-routing`
+
+直接从 MX8500 复制，内容完全相同（md5 `79f134c39e38d67c1ab43cfe201236a7`）。wwan2 / wwan5 每次 ifup 时：
+
+- 从 mwan3 的 `iif <设备> lookup <表>` 规则里找到该接口的路由表（本机 wwan5 = 表 3，wwan2 = 表 5）
+- 删除指向同一张表、同一 IP、或源 IP 已不在本机的旧 prio 100 规则
+- 添加 `from <当前 IP> lookup <表> prio 100`
+
+已手动对两个接口各运行一次，当前规则：
+
+```
+100: from 172.27.76.50  lookup 3
+100: from 172.27.85.164 lookup 5
+```
+
+已加入 `/etc/sysupgrade.conf`。
+
+### 4. radio0（2.4G）HE40 → HE20
+
+2.4G 热点 HE40，wwan2 只有 20 MHz，和 MX8500 的 2.4G 改动前情况相同。改 radio0 只会让 wwan2 和 2.4G 热点短暂断开，wwan5 在 radio1 上不受影响，不会丢失远程连接，所以直接改了：
+
+```sh
+( trap '' HUP; uci set wireless.radio0.htmode='HE20'; uci commit wireless; wifi up radio0 ) </dev/null >/tmp/radio0-change.log 2>&1 &
+```
+
+改完后热点与 STA 都是 20 MHz。wwan2 漫游到了信道 6 的另一台 eduroam AP，IP 不变，源地址规则仍然有效。
+
 ### 未改动
 
-- **5G 频宽**：保持 HE80，没有和 STA 对齐。对齐只能降到 HE20，5G 热点带宽会降到约 1/4，而 TR3000 没有 6 GHz 可以补充；且目前没有任何故障证据。如果以后看门狗日志里出现 wwan5 卡死（判定故障时记录的 tx failed 暴涨、速率掉到 MCS0），再考虑改。
+- **5G 频宽**：保持 HE80，没有和 STA 对齐。对齐只能降到 HE20，5G 热点带宽会降到约 1/4，而 TR3000 没有 6 GHz 可以补充；且目前没有任何故障证据；改的时候还会远程断线。如果以后看门狗日志里出现 wwan5 卡死（判定故障时记录的 tx failed 暴涨、速率掉到 MCS0），再考虑改。
-- **`99-fix-same-subnet-routing`**：MX8500 用它给两条同时在线的 Wi-Fi 上联加源地址策略路由。这台目前只有 wwan5 一条上联，不需要。以后同时启用 wwan2 时再评估。
+- **radio0 `txpower='10'`**：wwan2 的 tx failed 约 10%，高于 wwan5 的约 3%，可能与 2.4G 只有 10 dBm 发射功率有关。速率仍是 HE-MCS 11，链路可用，没有改。
 - **HE overrides**：这台已经是完整版 `wpad-mbedtls`，但和 MX8500 一样不支持 `disable_he`（OpenWrt 25.12 没有打开 `CONFIG_HE_OVERRIDES`）。目前不需要。
 
 ## 验证
@@ -102,6 +166,30 @@ $ mwan3 interfaces | grep wwan5
 
 部署后观察期间 wwan5 未断线，看门狗未触发。
 
+### 启用 wwan2、加源地址规则、radio0 改 HE20 之后（00:14:48 – 00:35:29）
+
+每分钟用看门狗同样的方式（`ping -I <设备>`，1.1.1.1 或 8.8.8.8 任一通即可）检测两条上联：
+
+| 时间 | wwan5 tx failed / tx packets | wwan5 连接时长 | wwan2 tx failed / tx packets | wwan2 连接时长 |
+|---|---|---|---|---|
+| 00:14:50 | 67739 / 2343668 | 31951 s | 81 / 742 | 57 s |
+| 00:20:00 | 67821 / 2365324 | 32261 s | 380 / 3322 | 367 s |
+| 00:25:10 | 67939 / 2385476 | 32571 s | 725 / 6079 | 677 s |
+| 00:30:20 | 68021 / 2404660 | 32881 s | 1067 / 8696 | 987 s |
+
+- 20 分钟内两条上联 0 次检测失败。
+- 看门狗 0 次动作（无误触发）。
+- 结束时 mwan3：`wwan5 online 09h:13m:05s`，`wwan2 online 00h:21m:29s`。
+- 观察期间 wwan5 新增 tx failed 约 0.5%；wwan2 约 12%，偏高但稳定，速率保持 HE-MCS 11（见“未改动”中的 txpower）。
+
+hotplug 自动生效的证据：radio0 重启后 wwan2 重新 ifup，脚本自动重新添加了规则，无需手动干预：
+
+```
+00:13:32 fix-routing: Added rule: from 172.27.76.50 table 3 (dev phy1-sta0) for wwan5    # 手动运行
+00:13:32 fix-routing: Added rule: from 172.27.85.164 table 5 (dev phy0-sta0) for wwan2   # 手动运行
+00:14:00 fix-routing: Added rule: from 172.27.85.164 table 5 (dev phy0-sta0) for wwan2   # radio0 重启后自动
+```
+
 查看看门狗动作：
 
 ```sh
@@ -116,6 +204,14 @@ cp /root/mwan3.user.bak /etc/mwan3.user
 rm /usr/sbin/wwan-watchdog
 sed -i '\#^/usr/sbin/wwan-watchdog$#d; \#^/etc/mwan3.user$#d' /etc/sysupgrade.conf
 uci set system.@system[0].log_size='128' && uci commit system && /etc/init.d/log restart
+
+# 源地址规则（两条上联同时在线时不建议回滚这一项）
+rm /etc/hotplug.d/iface/99-fix-same-subnet-routing
+sed -i '\#^/etc/hotplug.d/iface/99-fix-same-subnet-routing$#d' /etc/sysupgrade.conf
+ip rule show prio 100 | awk '{print $3, $5}' | while read ip t; do ip rule del from $ip lookup $t prio 100; done
+
+# 2.4G 频宽（会短暂断开 wwan2）
+uci set wireless.radio0.htmode='HE40' && uci commit wireless && wifi up radio0
 ```
 
 不要用 `crontab -l | grep -v ... | crontab -`：在 BusyBox 上会清空整个 crontab。
@@ -214,3 +310,46 @@ check wwan5 phy1-sta0 radio1
 	wwan2|wwan5) /usr/sbin/wwan-watchdog & ;;
 esac
 ```
+
+### `/etc/hotplug.d/iface/99-fix-same-subnet-routing`
+
+```sh
+#!/bin/sh
+
+[ "$ACTION" = "ifup" ] || exit 0
+
+case "$INTERFACE" in
+    wwan2|wwan5)
+        ;;
+    *)
+        exit 0
+        ;;
+esac
+
+# Get the IP address of this interface
+IP=$(ifstatus "$INTERFACE" | jsonfilter -e '@["ipv4-address"][0].address' 2>/dev/null)
+[ -z "$IP" ] && exit 0
+
+# Get the L3 device name of this interface
+DEV=$(ifstatus "$INTERFACE" | jsonfilter -e '@.l3_device' 2>/dev/null)
+[ -z "$DEV" ] && exit 0
+
+# Find the routing table number assigned by MWAN3 for this device
+TABLE=$(ip rule show | grep "iif $DEV lookup" | grep -o 'lookup [0-9]*' | awk '{print $2}' | head -1)
+[ -z "$TABLE" ] && exit 0
+
+# Remove stale prio 100 rules: same IP, same table, or source IP no longer on this router
+ip rule show | awk '$1 == "100:" && $2 == "from" { print $3, $5 }' | while read -r OLD_IP OLD_TABLE; do
+    if [ "$OLD_IP" = "$IP" ] || [ "$OLD_TABLE" = "$TABLE" ] || \
+       ! ip -4 addr show | grep -q "inet $OLD_IP/"; then
+        ip rule del from "$OLD_IP" lookup "$OLD_TABLE" prio 100 2>/dev/null && \
+            [ "$OLD_IP" != "$IP" ] && \
+            logger -t fix-routing "Removed stale rule: from $OLD_IP table $OLD_TABLE"
+    fi
+done
+
+# Add source-based policy route
+ip rule add from "$IP" table $TABLE prio 100
+
+logger -t fix-routing "Added rule: from $IP table $TABLE (dev $DEV) for $INTERFACE"
+```

reports/2026-10-28-linksys-mx8500-wwan-recovery.md

@@ -137,6 +137,8 @@ wifi up radio0
 
 已手动运行一次，残留规则已清除。备份：`/root/99-fix-same-subnet-routing.bak`。
 
+这些规则也是看门狗能正确判断的前提。看门狗用 `ping -I <设备>` 检测，本机发出的流量会被 mwan3 按 `balanced` 策略打 mark，可能被分到另一条上联的路由表，绑定的设备与路由出口不一致时，包就发不出去，造成误判。prio 100 的源地址规则排在 mwan3 的 fwmark 规则之前，把流量固定到正确的表。这一点是在 Cudy TR3000 上启用第二条上联时实测确认的，见 [`2026-10-28-cudy-tr3000-wwan-watchdog.md`](2026-10-28-cudy-tr3000-wwan-watchdog.md)。
+
 ### 4. 日志缓冲调大
 
 `system.@system[0].log_size` 从 128 改为 1024（KB）。原来 mwan3track 的日志约 6 分钟就会把缓冲写满，无法回溯故障。