TR3000 report: DHCP missing DNS option, Wi-Fi firmware reset during debugging, MX8500 check

reports/2026-10-30-cudy-tr3000-adguardhome-memory.md

@@ -1,11 +1,21 @@
-# Cudy TR3000：AdGuard Home 查询日志占满内存、限流过严
+# Cudy TR3000：AdGuard Home 内存与限流问题、DHCP 不下发 DNS 导致 iPad 无网络
 
 - 日期：2026-10-30
-- 设备：Cudy TR3000 256MB v1（`cudy-tr3000.tail694d4.ts.net`，远程）
+- 设备：Cudy TR3000 256MB v1（`cudy-tr3000.tail694d4.ts.net`，远程）；另检查了 Linksys MX8500（`linksys-mx8500.tail694d4.ts.net`）
 - 系统：OpenWrt 25.12.6 r33311-981c978eff，mediatek/filogic
 - AdGuard Home：0.107.79
 - 相关报告：[`2026-10-28-cudy-tr3000-wwan-watchdog.md`](2026-10-28-cudy-tr3000-wwan-watchdog.md)
 
+## 摘要
+
+| # | 问题 | 处理 |
+|---|---|---|
+| 1 | AdGuard Home 查询日志写在 tmpfs，6.5 小时涨到 122 MB，可用内存只剩 20 MB | 改为 6 小时轮转，并忽略 EasyTier 对端域名（MX8500 同样处理） |
+| 2 | `ratelimit: 20` 按网段计算，整个局域网共用一个额度 | 改为 `ratelimit: 0`（MX8500 同样处理） |
+| 3 | dnsmasq 改到 54 端口后，DHCP 不再下发 DNS 服务器，iPad 显示无网络 | 增加 `dhcp_option '6,192.168.156.65'` |
+| 4 | 排查时逐包写内核日志，导致 Wi-Fi 固件超时重置，两条上联和两个热点断开约 80 秒；之后 5G 热点没有恢复 | 执行 `wifi` 后恢复 |
+| 5 | Wi-Fi 重启后 iPad 的无线链路仍收发不通 | 未解决，待重启 iPad 后确认 |
+
 ## 背景
 
 反馈“AdGuard DNS 好像崩溃了”。排查时 AdGuard Home 进程正常运行，路由器上解析也正常，但发现两个会导致 DNS 不稳定甚至整机卡死的问题：
@@ -13,6 +23,8 @@
 1. 查询日志写在内存里（tmpfs），6.5 小时涨到 112 MB，可用内存只剩约 20 MB。
 2. 限流 `ratelimit: 20` 按网段计算，所有局域网设备共用一个额度，高峰期已超过上限。
 
+同时 iPad 连上 Wi-Fi 后一直显示“无互联网连接”，后来查明是另一个问题（第 3 项）。
+
 ## 现象
 
 | 时间 | 可用内存 | `querylog.json` | 说明 |
@@ -114,15 +126,133 @@ Mem:  total 497044  used 207988  free 216488  shared 5568  available 233988
 
 AdGuard Home 重启后约 15 秒才开始监听 53 端口（当时负载较高），这期间 DNS 不可用。
 
-## 未处理
+## 问题 3：DHCP 不下发 DNS，iPad 显示“无互联网连接”
 
-- **EasyTier 连接器反复重连**：路由器和 NUC 上的 EasyTier 一直在重试连接 `wss://*.zhe-yuan.top:0/easytier/` 等对端，持续占用 CPU（`easytier-core` 约 30%）。组网本身可用（各对端都已 p2p 直连），所以这次只是不记日志，没有改 EasyTier。后续可以查一下这几个对端为什么连不上。
+### 现象
-- **iPad 显示“无互联网连接”**：iPad 能正常关联（-44 dBm，HE-MCS 11）、拿到 DHCP（换了私有地址后是 `192.168.156.123`），路由器也能 ping 通它。但在观察的时间里，conntrack 里没有它发起的任何连接，也没有 DNS 查询，nft 计数 20 秒内只有 7 个包。也就是说 iPad 没有在尝试上网，原因还没查清，不确定和本次问题有关。需要在 iPad 上实际打开网页时同步抓包，并检查是否有 VPN、DNS 描述文件或 iCloud 专用代理。
+
+两台 iPad（`iPad` 7a:ca:e0:6d:f3:3f、`iPad-Pro` 80:a9:97:a6:b8:61）连上 Wi-Fi 后显示“无互联网连接”，浏览器报 `ERR_INTERNET_DISCONNECTED`。切换私有 Wi-Fi 地址也不管用。iPad 上的地址、子网掩码、路由器都正常：`192.168.156.123` / `255.255.255.192` / `192.168.156.65`。
+
+### 排查过程
+
+| 检查 | 结果 |
+|---|---|
+| 无线 | 关联正常，-44 dBm，HE-MCS 11 |
+| DHCP | 正常拿到 `192.168.156.123` |
+| 路由器 ping iPad | 通 |
+| conntrack | 没有任何从 iPad 发起的连接 |
+| AdGuard 查询日志 | 开机以来没有这台 iPad 的记录 |
+| nft 计数（只计数，不写日志），3 分钟 | 只有 mDNS、IGMP/MLD 和 1 个查询网关的 ARP，没有 DNS，没有 TCP |
+| 重新入网时双向抓包 | DHCP、ARP、RS/RA 都正常；之后 iPad 不发 DHCPv6、不发 DNS，完全静默 |
+| 临时关闭局域网 RA 和 DHCPv6 | 没有变化，已恢复 |
+| 打开 dnsmasq `logdhcp` | **DHCPACK 里没有 option 6（DNS 服务器）** |
+
+`logdhcp` 记录的 DHCPACK 内容（iPad 请求了 option 6，但没有收到）：
+
+```
+requested options: 1:netmask, 121:classless-static-route, 3:router,
+requested options: 6:dns-server, 15:domain-name, 108:ipv6-only,
+requested options: 114:captive-portal, 119:domain-search, 162, 252
+sent option: 53 message-type 5
+sent option: 54 server-identifier 192.168.156.65
+sent option: 51 lease-time 12h
+sent option:  1 netmask 255.255.255.192
+sent option: 28 broadcast 192.168.156.127
+sent option:  3 router 192.168.156.65
+sent option: 15 domain-name lan
+```
+
+### 原因
+
+为了让 AdGuard Home 使用 53 端口，dnsmasq 被改到了 `port=54`。dnsmasq 不在 53 端口提供 DNS 时，不会自动把自己作为 DNS 服务器（option 6）写进 DHCP 应答。
+
+其他设备没受影响，是因为它们走 IPv6：odhcpd 的 RA 里带了 DNS（`fd84:1963:e466::1`），它们也有 ULA 地址。AdGuard 查询日志里的局域网客户端全是 `fd84:` 地址，正好印证了这一点。iPad 没有拿到 ULA 地址（原因见“附带发现”），用不了这个 IPv6 DNS，IPv4 又没有 DNS，iOS 就判定这个网络不能上网，连 DNS 查询和联网检测都不发。
+
+MX8500 上本来就配了 `dhcp_option '3,192.168.156.1' '6,192.168.156.1' '15,lan'`，所以没有这个问题。TR3000 是漏配了。
+
+### 修改
+
+```sh
+uci add_list dhcp.lan.dhcp_option='6,192.168.156.65'
+uci commit dhcp
+/etc/init.d/dnsmasq restart
+```
+
+修改后 iPad 重新入网，立刻开始正常解析，并发起大量连接（iCloud、Google 等）。conntrack 里能看到它到 `192.168.156.65:53` 的查询都有应答，一度建立了 112 条连接。
+
+## 问题 4：排查导致 Wi-Fi 固件重置（我的操作引起）
+
+### 经过
+
+排查 iPad 时，在 `phy1-ap0` 入方向（netdev ingress）和 bridge output/forward 上加了 nft 规则，把进出 iPad 的**每个包都写进内核日志**。iPad 拿到 DNS 后流量突增，每个包要记录好几次（bridge 泛洪时 eth0、eth1、phy*-ap0 各记一次），CPU 被打满（负载 11.6）：
+
+| 时间 | 事件 |
+|---|---|
+| 18:14:28 | iPad 开始大量收发；`phy1-sta0`（wwan5）因不活动断开 |
+| 18:14:30 | `eth0: NETDEV WATCHDOG: transmit queue 0 timed out 5020 ms` |
+| 18:14:32 | `phy1-ap0` link down |
+| 18:14:34 – 18:15:24 | `mt798x-wmac: Retry message ...`（Wi-Fi 固件 MCU 消息超时） |
+| 18:14:43 | `phy0-sta0`（wwan2）断开 |
+| 18:15:35、18:15:42 | `ieee80211 phy0/phy1: Hardware restart was requested`，固件重新加载 |
+| 18:15:50 | wwan5、wwan2 重新上线 |
+| 18:16:23 | 调试规则按计划自动删除 |
+
+两条上联和两个热点断开约 80 秒，这期间 iPad 报 `ERR_NAME_NOT_RESOLVED`。
+
+**教训**：在这台 MT7981 上不要用 nft `log` 逐包记录，哪怕只针对一台设备。只用 `counter` 计数（开销可以忽略），或者限速记录（`limit rate 10/second`）。
+
+### 后遗症与恢复
+
+- **5G 热点没有恢复**：固件重置期间，wwan5 从信道 52 漫游到了信道 165。`phy1-ap0` 一直处于 down 状态，hostapd 也没有再启用它。推测是 165 只支持 20 MHz，而热点设的是 HE80，但没有确证。
+- **iPad 在 2.4G 上收发不通**：见问题 5。
+
+18:20:17 执行 `wifi`（后台运行，避免 SSH 断开时被中断），两个射频都重新配置。5G 热点在 18:21:32 恢复（wwan5 此时在信道 112，热点 HE80，中心 5530 MHz，等 DFS 检测约 60 秒），两条上联在约 10 秒内恢复。
+
+## 问题 5（未解决）：iPad 无线链路不通
+
+执行 `wifi` 后，Galaxy 重新连上并正常工作，但 iPad（7a:ca:e0:6d:f3:3f）在两个频段都连不通。iPad 自分配了 `169.254.237.114`。
+
+| 项目 | iPad | Galaxy（同一个 `phy0-ap0`） |
+|---|---|---|
+| authorized / MFP | yes / yes | yes / yes |
+| 信号 | -40 dBm | -39 dBm |
+| rx packets | 239 | 14695 |
+| tx packets / tx failed | 6 / **30** | 32392 / — |
+| rx 速率 | **1.0 Mbit/s**（只有最低速率的管理帧） | 正常 |
+| `phy0-ap0` netdev ingress 计数（25 秒） | **0** | — |
+
+驱动收到了 iPad 的帧，但没有一个送到网络接口。路由器发给 iPad 的帧大多也没有得到确认。信号很强，不是距离问题。Galaxy 在同样的重置之后工作正常，所以推测是 iPad 的 Wi-Fi 状态在多次重连和路由器固件重置之后卡住了。
+
+下一步：先重启 iPad；不行就“忽略此网络”后重新加入；还不行就重启路由器，彻底重新加载 Wi-Fi 固件。
+
+## 附带发现
+
+- **odhcpd 通告 /60 前缀，RA 生存期为 0**：局域网是 `ip6assign='60'`，`ubus call dhcp ipv6ra` 显示通告的前缀是 `fd84:1963:e466::1/60`。SLAAC 需要 /64，这很可能就是 iPad 没有 ULA 地址的原因。odhcpd 还在反复报 `no public prefix on lan thus we announce no default route by setting ra_lifetime to 0`。局域网没有 NAT66，IPv6 本来就上不了外网，所以没有改。如果以后要让局域网的 ULA 更可靠，可以改成 `ip6assign='64'`。
+- **DHCP 地址池只有 27 个**：局域网是 /26，`start=100 limit=150` 实际只能用 `.100`–`.126`。iPad 使用私有 Wi-Fi 地址时，每次换地址都会多占一个租约，iPad-Pro 已经拿到了最后一个地址 `.126`。
+- **EasyTier**：用户删掉了无效的对端。TR3000 重启 EasyTier 后，现在是 `tcp://cloud…:11010` 和 `tcp://backup…:11010`。之前的 `wss://…:0/easytier/` 一直处于 Connecting，用 curl 测试服务器可达（返回 HTTP 400），推测问题出在端口写成了 `:0`。`easytier-core` 约 30% 的 CPU 主要用于给 `intel-nuc8i5beh` 转发流量（112 MB）。
+
+## Linksys MX8500 检查
+
+| 项目 | MX8500 | 处理 |
+|---|---|---|
+| DHCP option 6 | 已配置 `6,192.168.156.1`，生成的 dnsmasq 配置里也有 `dhcp-option=lan,6,192.168.156.1`；iPhone（`.43`、`.46`）在 AdGuard 里有 IPv4 查询记录；日志中没有 DHCPNAK 或地址耗尽 | 无需修改 |
+| DHCP 地址池 | 同样只有 27 个（`.36`–`.62`） | 未改 |
+| RA 前缀 | 同样是 `/60`（`fd22:5891:d9c2::1/60`） | 未改 |
+| `ratelimit` | 20 | 改为 0（`wan` 区入站同样是 `REJECT`） |
+| 查询日志 | 90 天，11.5 小时 59 MB（`/tmp/lib/adguardhome/data`），绝大部分是本机 EasyTier 的解析 | 改为 6 小时轮转，并忽略三个 EasyTier 对端域名 |
+| 内存 | 887 MB 总量，修改前可用 243 MB；`/tmp` 61 MB → 5 MB | — |
+| EasyTier | 配置 17:48 改过，但进程没有重启，仍在重试 `wss://home…`、`wss://cloud…`、`wss://backup…`；配置里还保留着两条 `wss://…:0` | 未改，需要用户确认后重启 |
+
+MX8500 备份：`/root/adguardhome.yaml.bak`。修改后 DNS 正常，53 端口在 20 秒内恢复监听。
 
 ## 回滚
 
 ```sh
+# AdGuard Home（两台路由器相同）
 /etc/init.d/adguardhome stop
 cp /root/adguardhome.yaml.bak /etc/adguardhome/adguardhome.yaml
 /etc/init.d/adguardhome start
+
+# TR3000 DHCP DNS（不建议回滚，否则只有 IPv6 DNS 可用）
+uci del_list dhcp.lan.dhcp_option='6,192.168.156.65'
+uci commit dhcp && /etc/init.d/dnsmasq restart
 ```