Baike.dev
Log in
Back to tool/Back to issues
#3038·istoreos

[25.12.5 x86_64] dhcpv6 动态子接口 wan_6 每秒重建循环：netifd 报 `ubus error: Invalid argument`（被拒请求体为畸形 JSON `{,}`）

Author: wang3150315Created Sep 16, 2026Updated Sep 16, 2026

环境

项目 值
固件 iStoreOS 25.12.5 / 2026091113（x86_64，GPT+EFI 安装）
内核 6.12.94
netifd 2026.02.26~cbb83a18-r1
odhcp6c 2026.06.20~07d324ee-r5
libubus / libubox 2026.06.28~24864e78-r2 / 2026.06.19~7dd12784-r1
IPv6 上游 电信 PPPoE(IPv4) + 原生 IPv6（DHCPv6-PD，无 DS-Lite / MAP / 464XLAT 需求）
升级方式 网页「系统 → 刷写固件」，走官方参数（save_partitions=1），overlay 与数据分区均保留，从 24.10.8 跨版本升级

现象

升级到 25.12.5 后，WAN6（DHCPv6）的动态子接口 wan_6 进入无限重建循环，开机即出现、持续不断（约 1–2 次/秒），logread 被刷屏：

Wed Sep 16 13:02:38 2026 daemon.notice netifd: wan_6 (25603): ubus error: Invalid argument
Wed Sep 16 13:02:38 2026 daemon.notice netifd: Interface 'wan_6' is now down
Wed Sep 16 13:02:38 2026 daemon.notice netifd: Interface 'wan_6' is setting up now
Wed Sep 16 13:02:38 2026 daemon.notice netifd: wan_6 (25472): ubus error: Invalid argument
（如此往复，15 分钟内 >500 行）

每次都重新 fork/exec 一个新的 odhcp6c 进程（日志里的 PID 持续增长：25204 → 25335 → 25472 → 25603…），即每秒一次进程创建/销毁。

注意：IPv6 功能本身是正常的 —— pppoe-wan 拿到 240e:xxxx:xxxx:xxxx::/64 与默认路由，DHCPv6-PD 已下发到 LAN（240e:xxxx:xxxx:xxxx::/64 dev br-lan），ping6 公网 IPv6 目标 0% 丢包。所以这是一个控制面/接口生命周期问题，不影响转发，但会刷爆日志并持续消耗 CPU。

抓到的证据（ubus monitor）

netifd 启动子进程的调用（已脱敏 DUID 与 ifaceid）：

invoke: {"objid":..., "method":"notify_proto", "data":{
  "action":1,
  "command":["odhcp6c","-s","/lib/netifd/dhcpv6.script","-P0:<ifaceid>","-c<DUID>","-r64","-r94","-r95","-r96","-t120","pppoe-wan"],
  "env":["ZONE=wan","FAKE_ROUTES=1","DYNAMIC=1","INTERFACE=wan_6"],
  "interface":"wan_6"}}

紧接着出现被 netifd 拒绝的调用，注意 data 是非法 JSON（{,}）：

<- invoke: {"objid":3, "method":"remove", "data":{,}}
   → netifd: wan_6 (PID): ubus error: Invalid argument
   → Interface 'wan_6' is now down → setting up now → （循环）

objid:3 上确实注册了 remove 方法（同一份 monitor 里可见 "remove":{} 的签名），但这个请求体是畸形的，netifd 直接以 EINVAL 拒绝，随后该动态接口被判为失败、拆除、重建。

已尝试且无效的规避（均为问题出现之后添加，默认配置下同样复现）

  1. 重启接口：ubus call network.interface.wan6 down/up、ifup wan6
  2. 显式关闭过渡机制：uci set network.wan6.iface_dslite=0 / iface_map=0 / iface_464xlat=0（并 ifup wan6）
  3. 关闭动态子接口：uci set network.wan6.dynamic=0（已回滚）

均无改善；/lib/netifd/dhcpv6.script 未被 overlay 覆盖（与固件自带一致），overlay 中也不存在陈旧的基础包二进制（netifd/odhcp6c/libubus 均来自新 rootfs）。

相关配置（脱敏）

config interface 'wan'
        option device 'eth0'
        option proto 'pppoe'
        option ipv6 'auto'

config interface 'wan6'
        option device '@wan'
        option proto 'dhcpv6'
        option auto '1'
        option reqaddress 'try'
        option reqprefix 'auto'

请求

  1. 确认 {"objid":3,"method":"remove","data":{,}} 这个畸形请求体是由 netifd 自身（动态接口回收路径）还是 odhcp6c 生成的；从 monitor 的序列看更像是 netifd 内部对动态接口的回收动作。
  2. 判断是否与 DHCPv6 的 AFTR-Name（option 64） 有关 —— netifd 启动 odhcp6c 时带了 -r64，而本 ISP 会返回 AFTR 信息（我们不需要 DS-Lite，相关 iface_* 已显式设为 0，但循环依旧）。
  3. 若判定为上游问题（netifd 2026.02.26 / odhcp6c 2026.06.20），烦请转上游；在此之前能否给个临时规避办法（例如抑制动态子接口的回收重试）？

如果需要，我可以提供更完整的 ubus monitor 原始记录、完整 logread 片段以及设备端 ip -6 addr/route 输出。

Source: istoreos/istoreos

View original on GitHubView discussion on GitHub