OpenWrt ACME 刷新证书提示 DNS 令牌失效
按 证书管理 的步骤去刷新 OpenWrt 的 ACME 证书一直提示 Cloudflare DNS 令牌无权限。记得最近是重新生成过过期令牌，但在 LuCI 图形界面上也替换过了。
一通排查发现光是修改 /etc/config/acme 是不够的，真正执行 renew 所需的参数已经记录在 /etc/acme/<domain>/<domain>.conf 文件中了，得手动改这里。
多接口在同一个 IPv6 网段下的冲突
一直困扰我的 容器响应 IPv6 前缀变动并更新 DDNS 中未刷新 NDP 记录的疑难杂症，即便加上 ping hack 后还是不稳定。
直到我注意到 PVE 上有这样的输出，同一个 IPv6 公网网段 2409:8a1e:6940:7c20::/64 同时出现在了三个不同的接口上。
root@pve:~# ip -6 route
2409:8a1e:6940:7c20::529 dev mgmt proto kernel metric 256 expires 85054sec pref medium
2409:8a1e:6940:7c20::920 dev vmbr0 proto kernel metric 256 expires 85081sec pref medium
2409:8a1e:6940:7c20::/64 dev vmbr0 proto kernel metric 256 expires 259192sec pref medium
2409:8a1e:6940:7c20::/64 dev mgmt proto kernel metric 256 expires 258976sec pref medium
2409:8a1e:6940:7c20::/64 dev vmbr1 proto kernel metric 256 expires 258622sec pref medium
fe80::/64 dev vmbr0 proto kernel metric 256 pref medium
fe80::/64 dev vmbr1 proto kernel metric 256 pref medium
fe80::/64 dev mgmt proto kernel metric 256 pref medium
default via fe80::a236:bcff:fe70:ce58 dev vmbr0 proto ra metric 1024 expires 1792sec mtu 1492 hoplimit 64 pref medium之前配置 给 Docker 配置完整的 IPv6 macvlan 网络环境 时应该也注意过，当时应该只是歪打正着没让多个网卡有 IPv6 地址。
metric 还都一样，这会导致本应转发往 vmbr1 的包又回到了 vmbr0。一个现象是使用 ping -I vmbr1 正常，但直接 ping 就失败。
解决方法也简单，同一个二层 IPv6 广播域的网卡只分配一个 IPv6 地址。
auto vmbr0
iface vmbr0 inet dhcp
iface vmbr0 inet static
address 192.168.9.17/24
gateway 192.168.9.1
bridge-ports enp5s0
bridge-stp off
bridge-fd 0
post-up sysctl net.ipv4.ip_forward=1
post-up ethtool -K $IFACE rx-udp-gro-forwarding on rx-gro-list off
# IPv6 is enabled on mgmt interface only
post-up sysctl net.ipv6.conf.$IFACE.accept_ra=0
post-up sysctl net.ipv6.conf.$IFACE.autoconf=0
auto mgmt
iface mgmt inet dhcp
pre-up ip link add link vmbr0 name mgmt address 1c:1b:0d:95:90:d2 type macvlan mode bridge
post-up sysctl net.ipv6.conf.$IFACE.accept_ra=2
post-down ip link del mgmt
iface mgmt inet6 auto
privext 2还没完，OpenWrt 上同样有问题，相反，它的路由表上没有 2409:8a1e:6940:7c20::/64 dev br-lan 的条目
root@openwrt:~# ip -6 r
fd7a:115c:a1e0::53 dev tailscale0 metric 1024
fd7a:115c:a1e0::/48 dev tailscale0 metric 1024
2409:8a1e:6940:7c20::1 dev eth0 metric 1024
2409:8a1e:6940:7c20::/64 dev eth0 metric 256
unreachable 2409:8a1e:6940:7c20::/64 dev lo metric 2147483647
fd7a:115c:a1e0::ea37:7005 dev tailscale0 metric 256
fe80::/64 dev br-lan metric 256
fe80::/64 dev tailscale0 metric 256
fe80::/64 dev eth0 metric 256
anycast 2409:8a1e:6940:7c20:: dev eth0 metric 0
anycast fe80:: dev br-lan metric 0
anycast fe80:: dev tailscale0 metric 0
anycast fe80:: dev eth0 metric 0
multicast ff00::/8 dev br-lan metric 256
multicast ff00::/8 dev tailscale0 metric 256
multicast ff00::/8 dev eth0 metric 256对比几个正常工作的路由器，我尝试把 WAN 也加入到 br-lan 网桥上，虽然感觉不好，但总之 OpenWrt 能正常工作了…
2026-02-05 其实核心是 PVE 下的网桥应该关闭 multicast snooping
Asuswrt-Merlin 重启会丢失 dnsmasq.d 目录文件的内容
- JFFS 分区文件丢失引发局域网 DHCP 分配混乱
今天才意识到可能是 DNSmasq 启动脚本在启动后创建的这个目录。被清空也是符合预期的，它要避免系统无法启动。
conf-dir=/jffs/configs/dnsmasq.d那解法也简单了，写个 /jffs/configs/dnsmasq.conf.add 文件，加个自己的 conf-dir
conf-dir=/jffs/configs/dnsmasq.conf.d,*.confRG-MA3063 内置 DHCP 会在桥接模式断网后激活
Tue Feb 3 21:42:09 2026 daemon.notice netifd: Network device 'eth0' link is down
Tue Feb 3 21:42:09 2026 kern.info kernel: [165825.059341] nss-dp 39c00000.dp1 eth0: PHY Link is down
Tue Feb 3 21:42:09 2026 kern.info kernel: [165825.059821] br-lan: port 5(eth0) entered disabled state
Tue Feb 3 21:42:10 2026 local0.info rjd[1137]: phy down: eth0
Tue Feb 3 21:42:11 2026 daemon.info hostapd: ath13: STA e0:03:6b:cf:4d:1e IEEE 802.11: authenticated
Tue Feb 3 21:42:11 2026 daemon.info hostapd: ath13: STA e0:03:6b:cf:4d:1e IEEE 802.11: associated (aid 5)
Tue Feb 3 21:42:11 2026 daemon.info hostapd: ath13: STA e0:03:6b:cf:4d:1e WPA: sending 1/4 msg of 4-Way Handshake
Tue Feb 3 21:42:11 2026 daemon.info hostapd: ath13: STA e0:03:6b:cf:4d:1e WPA: received EAPOL-Key frame (2/4 Pairwise)
Tue Feb 3 21:42:11 2026 daemon.info hostapd: ath13: STA e0:03:6b:cf:4d:1e WPA: sending 3/4 msg of 4-Way Handshake
Tue Feb 3 21:42:11 2026 daemon.info hostapd: ath13: STA e0:03:6b:cf:4d:1e WPA: received EAPOL-Key frame (4/4 Pairwise)
Tue Feb 3 21:42:11 2026 daemon.info hostapd: ath13: STA e0:03:6b:cf:4d:1e RADIUS: starting accounting session DA768A7B1D7B23EE
Tue Feb 3 21:42:11 2026 daemon.info hostapd: ath13: STA e0:03:6b:cf:4d:1e WPA: pairwise key handshake completed (RSN)
Tue Feb 3 21:42:12 2026 daemon.info hostapd: ath13: STA a0:d0:5b:9c:48:c5 IEEE 802.11: disassociated
Tue Feb 3 21:42:12 2026 daemon.info hostapd: ath13: IEEE 802.11 deauthenticated by sta(a0:d0:5b:9c:48:c5), reason_code=3
Tue Feb 3 21:42:14 2026 local0.info rjd[1137]: phy up: eth0
Tue Feb 3 21:42:14 2026 local0.info rjd[1137]: -- port eth0: up
Tue Feb 3 21:42:14 2026 kern.info kernel: [165829.859666] nss-dp 39c00000.dp1 eth0: PHY Link up speed: 1000
Tue Feb 3 21:42:14 2026 local0.info rjd[1137]: rjdal_get_active_ports: 0x1.
Tue Feb 3 21:42:14 2026 daemon.notice netifd: Network device 'eth0' link is up
Tue Feb 3 21:42:14 2026 kern.info kernel: [165829.978817] br-lan: port 5(eth0) entered forwarding state
Tue Feb 3 21:42:14 2026 kern.info kernel: [165829.978989] br-lan: port 5(eth0) entered forwarding state
Tue Feb 3 21:42:14 2026 local0.info rjd[1137]: workmode: [ bridge ], wantype: [ dhcp ], lastwan: [ eth0 ]
Tue Feb 3 21:42:14 2026 local0.info rjd[1137]: wan up, detect...
Tue Feb 3 21:42:14 2026 local0.info rjd[1137]: lan uping, but wan is up already, predetect dhcp at lastwan: eth0
Tue Feb 3 21:42:16 2026 kern.info kernel: [165831.969220] br-lan: port 5(eth0) entered forwarding state
Tue Feb 3 21:42:16 2026 daemon.notice netifd: lan4 (1053): udhcpc: Dhcp Probe 192.168.9.1 Failed, ready to renew.
Tue Feb 3 21:42:16 2026 daemon.notice netifd: lan4 (1053): udhcpc: received SIGUSR2
Tue Feb 3 21:42:16 2026 daemon.notice netifd: lan4 (1053): udhcpc: unicasting a release of 192.168.9.6 to 192.168.9.1
Tue Feb 3 21:42:16 2026 daemon.notice netifd: lan4 (1053): udhcpc: sending release
Tue Feb 3 21:42:16 2026 daemon.notice netifd: lan4 (1053): udhcpc: entering released state
Tue Feb 3 21:42:16 2026 daemon.notice netifd: Interface 'lan4' has lost the connection
Tue Feb 3 21:42:16 2026 local0.info rjd[1137]: rcv: { "network.interface": {"action":"ifdown","interface":"lan4"} }
Tue Feb 3 21:42:16 2026 daemon.info dnsmasq[483]: reading /tmp/resolv.conf.auto
Tue Feb 3 21:42:16 2026 daemon.info dnsmasq[483]: using only locally-known addresses for domain lan
Tue Feb 3 21:42:16 2026 daemon.info dnsmasq[483]: using nameserver 2409:8a1e:6940:7c20::1#53
Tue Feb 3 21:42:16 2026 daemon.info dnsmasq[483]: using nameserver fe80::a236:bcff:fe70:ce58%br-lan#53
Tue Feb 3 21:42:16 2026 daemon.notice netifd: lan4 (1053): udhcpc: performing DHCP renew, state = 6
Tue Feb 3 21:42:16 2026 local0.info rjd[1137]: ^lan4*$ if action msg received: lan4: ifdown, from 0
Tue Feb 3 21:42:16 2026 daemon.notice netifd: lan4 (1053): udhcpc: sending discover
Tue Feb 3 21:42:16 2026 local0.info rjd[1137]: == port eth0, detect dhcp at eth 0x1
Tue Feb 3 21:42:17 2026 daemon.info dnsmasq[483]: exiting on receipt of SIGTERM
Tue Feb 3 21:42:17 2026 user.notice upnp daemon: external interface not found, not starting
Tue Feb 3 21:42:18 2026 daemon.info dnsmasq[6564]: Connected to system UBus
Tue Feb 3 21:42:18 2026 daemon.info dnsmasq[6564]: start: firstwebpop_flag = 1
Tue Feb 3 21:42:18 2026 daemon.info dnsmasq[6564]: started, version 2.82 cachesize 150
Tue Feb 3 21:42:18 2026 daemon.info dnsmasq[6564]: DNS service limited to local subnets
Tue Feb 3 21:42:18 2026 daemon.info dnsmasq[6564]: compile time options: IPv6 GNU-getopt no-DBus UBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua no-TFTP no-conntrack no-ipset no-auth DNSSEC loop-detect inotify dumpfile
Tue Feb 3 21:42:18 2026 daemon.info dnsmasq[6564]: UBus support enabled: connected to system bus
Tue Feb 3 21:42:18 2026 daemon.info dnsmasq-dhcp[6564]: DHCP, IP range 192.168.10.100 -- 192.168.10.249, lease time 12h从日志和 strings /bin/rjd 来看，就是这个进程在 eth0 断开后，自说自话地把 DHCP 服务启动，给局域网内连上来的设备分配不属于原网段的 IP。它给的 lease 还是 12h，要好久才能自然恢复。
看上去是往 ubus 发消息来触发的，也不知道默认值从哪来的。目前是 grep 到在 /etc/config/repacd 中有相关的，先改了观察下