光猫拿到/60但不给二级路由委派IPv6前缀的解决方法

2026-06-21

背景

家里用的是中国移动宽带，光猫是吉比特 GS3101（中国移动定制），下挂一台 ImmortalWrt 路由器（MT7981 芯片）做二级路由。最开始遇到的问题是：ImmortalWrt 的 wan6 经常拿不到 DHCPv6-PD 前缀，日志里反复出现：

1
2


daemon.warn odhcp6c: Server returned IA_PD status 'No Prefix Available'
daemon.warn odhcp6c: Server returned IA_PD status 'No Binding'

一开始我以为是 ISP 不下发 PD，所以尝试过 NDP Relay。后面拿到光猫超管和 Telnet 后确认，真实原因不是“中国移动完全不给前缀”，而是：

ISP 已经给光猫下发了 /60，但光猫默认没有把可用前缀正确委派给下挂的 ImmortalWrt。

当前已经跑通的链路是：

1
2
3
4


ISP -> 光猫 ppp1 获取 2409:8a28:6e2:1c20::/60
光猫 br0 自用 2409:8a28:6e2:1c20::/64
光猫 dhcp6s -> ImmortalWrt 委派 2409:8a28:6e2:1c28::/61
ImmortalWrt br-lan -> LAN 设备下发 2409:8a28:6e2:1c28::/64

国内 IPv6 连通性正常；海外 IPv6 的 TCP/443 仍然不稳定或不可达，这是运营商出口策略问题，不是本地 DHCPv6-PD 配置问题。

当前状态核对

光猫侧

光猫固件：

1
2


cat /etc/fwver.conf
# V1B0.C02.01

ISP 给光猫的前缀：

1
2
3
4
5


cat /var/run/ppp1/orgpd6
# 2409:8a28:6e2:1c20::/60

cat /var/run/ppp1/pd6
# 2409:8a28:6e2:1c20::/64

orgpd6 是 ISP 原始委派给光猫的 /60；pd6 是光猫自己拿来给 br0/LAN 使用的 /64。

光猫 LAN 地址：

1

br0 inet6 addr: 2409:8a28:6e2:1c20:b654:59ff:fe2a:59a8/64

光猫当前 DHCPv6 Server 配置：

option domain-name-servers fe80::1;
interface br0 {
        address-pool pool1 172800 259200;
};
pool pool1 {
        range 2409:8a28:6e2:1c20::1 to 2409:8a28:6e2:1c20::1000;
};
host immortalwrt {
        duid 00:03:00:01:70:2a:d7:60:77:20;
        prefix 2409:8a28:6e2:1c28::/61 172800 259200;
};

这组配置是合理的：

2409:8a28:6e2:1c20::/60 覆盖 1c20 到 1c2f 这 16 个 /64。
光猫自己使用 1c20::/64。
委派给 ImmortalWrt 的 1c28::/61 覆盖 1c28 到 1c2f，没有和光猫自用的 1c20::/64 重叠。
光猫路由表中已有到 ImmortalWrt 的路由：

1

2409:8a28:6e2:1c28::/61 via fe80::722a:d7ff:fe60:7720 dev br0

ImmortalWrt 侧

wan6 当前已拿到 IA_NA 和 IA_PD：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


"ipv6-address": [
  {
    "address": "2409:8a28:6e2:1c20:722a:d7ff:fe60:7720",
    "mask": 64
  }
],
"ipv6-prefix": [
  {
    "address": "2409:8a28:6e2:1c28::",
    "mask": 61,
    "assigned": {
      "lan": {
        "address": "2409:8a28:6e2:1c28::",
        "mask": 64
      }
    }
  }
]

br-lan 当前地址：

1

2409:8a28:6e2:1c28::1/64

关键 UCI 配置：

1

uci show network.wan6

1
2
3
4
5
6


network.wan6=interface
network.wan6.device='eth1'
network.wan6.proto='dhcpv6'
network.wan6.reqaddress='try'
network.wan6.reqprefix='60'
network.wan6.releaseprefix='1'

1

uci show network.lan

1
2
3
4
5


network.lan=interface
network.lan.device='br-lan'
network.lan.proto='static'
network.lan.ipaddr='192.168.7.1'
network.lan.ip6assign='64'

1

uci show dhcp.lan

1
2
3
4


dhcp.lan.ra='server'
dhcp.lan.dhcpv6='server'
dhcp.lan.ndp='disabled'
dhcp.lan.ra_flags='managed-config' 'other-config'

这个状态也是合理的：既然已经拿到正规 PD，LAN 侧就应该用 RA/DHCPv6 Server，下游不需要再开 NDP Relay。

实测连通性：

1
2
3
4
5
6


ping6 -c 3 2400:3200::1
# 0% packet loss

wget -6 -q -O /dev/null --timeout=8 https://www.baidu.com && echo OK
wget -6 -q -O /dev/null --timeout=8 https://www.qq.com && echo OK
wget -6 -q -O /dev/null --timeout=8 https://www.aliyun.com && echo OK

国内 IPv6 和 HTTPS 都是通的。

超管密码和 Telnet 获取过程

这台 GS3101 的默认超管密码已经失效，原因大概率是运营商通过 TR-069/网管系统把超管密码随机化了。所以网上常见的默认组合不可靠：

1
2
3
4


CMCCAdmin / 默认密码
telecomadmin / 默认密码
SN 推算密码
MAC 推算密码

实际可行的路径是：把光猫 SN 发给装维师傅，师傅通过移动装维/网管系统查询当前设备绑定的动态超管密码。这个密码不是本地用 SN 简单 hash 算出来的，更像是后台系统按设备 SN、地区、工单或设备注册信息查表/下发的结果。

常见获取路径对比：

方法	是否推荐	说明
找装维师傅用 SN 查询	推荐	本次就是这条路，最快，也最少折腾设备
闲鱼/代查超管	可用但不推荐	本质也是用 SN 查后台，存在隐私和账号风险
UPnP `X_GetAccess`	看固件状态	部分 GS2101/GS3101 的 5555 端口会暴露厂商自定义 action，可返回超管信息；前提是 UPnP 已开启且 action 未被封
配置导出后解密/解析	适合研究	需要能导出 romfile，且不同固件格式不完全一致
恢复出厂并阻断 TR-069	有风险	需要提前记录 LOID/宽带账号，操作不当会断网
TTL 串口	最可靠但要拆机	适合硬件调试，直接进 shell 查配置

UPnP 那条路要特别注意：网上文章常把“开启 UPnP 后 Telnet 自动开放”写成因果关系，但实测过程里往往还混有 X_SetAccess、Reboot 等 action。更准确地说，Telnet 开放可能来自“开启远程/本地管理权限并重启后生效”，不一定只是 UPnP 开关本身导致。

拿到 Web 超管后，可以进入隐藏配置页面：

1

http://192.168.1.1/cgi-bin/upgrade.asp

其中：

romfile：配置导入。
tclinux.bin：固件导入。

如果要改 romfile，务必先备份原配置。配置导入比直接在 shell 里改 /etc 更有机会持久化，但也更容易因为 XML/校验错误导致配置异常。

Telnet 登录踩坑

这台设备的 Telnet 和 Web 超管不是同一套账号。Web 用的是超管账号，Telnet 用的是 Account_TelnetEntry 里的账号。

Telnet 登录方式：

1

telnet -K -8 -E 192.168.1.1 23

参数说明：

-K：不自动登录。
-8：8-bit 传输，避免部分字符被处理。
-E：禁用 escape 字符，避免特殊字符干扰交互。

正确现象：

1
2
3
4
5


Trying 192.168.1.1...
Connected to 192.168.1.1.
tc login:
Password:
#

常见错误：

现象	原因	处理
`Connection refused`	Telnet 服务没开或被防火墙挡住	先确认 Web 超管里 Telnet 是否开启，或看 `utelnetd` 是否运行
`Login incorrect`	把 Web 超管账号拿去登录 Telnet	Telnet 用户通常是 `admin`，密码看 `Account_TelnetEntry`
能连但输入异常	Telnet 客户端转义/编码影响特殊字符	使用 `telnet -K -8 -E`
登录后不是 `#`	权限或 shell 不对	确认登录的是 TelnetEntry 账号，不是普通 Web 用户

登录后可以核对：

1
2
3


tcapi show Account_TelnetEntry
ps | grep utelnetd
netstat -lntup | grep ':23'

这台设备上 utelnetd 的启动形式是：

1

/usr/bin/utelnetd -p 23 -l /bin/login -d

utelnetd 只支持 -p、-l、-d，没有绑定指定监听地址的参数，所以不能直接让它只监听 192.168.1.1。如果要保留 Telnet，又不想暴露到 WAN，只能靠防火墙规则限制 WAN 侧访问。

当前策略是：Telnet/Web 保留 LAN 侧可用，WAN 侧通过 iptables/ip6tables DROP 管理端口。

推荐方案：让光猫向 ImmortalWrt 委派前缀

如果你的光猫也已经从 ISP 拿到了 /60 或 /56，优先使用 DHCPv6-PD，不要先上 NDP Relay。

1. 确认光猫拿到的原始 PD

Telnet 登录光猫后查看：

1
2


cat /var/run/ppp1/orgpd6
cat /var/run/ppp1/pd6

如果 orgpd6 有 /60、/56 之类的前缀，而二级路由拿不到 PD，问题通常在光猫的 dhcp6s 下发逻辑。

2. 找到 ImmortalWrt 的 DUID

在 ImmortalWrt 上看 wan6 客户端 DUID。常见方式是看 odhcpd lease 或用 WAN 口 MAC 推导：

1
2


cat /tmp/hosts/odhcpd 2>/dev/null
ip link show dev eth1

本文这台 ImmortalWrt 的 WAN 口 MAC 是：

1

70:2a:d7:60:77:20

对应 DUID-LL：

1

00:03:00:01:70:2a:d7:60:77:20

格式说明：

00:03：DUID-LL
00:01：以太网
后面 6 字节：WAN 口 MAC

3. 修改光猫 dhcp6s.conf

光猫运行期配置文件：

1

/etc/dhcp6s.conf

示例配置：

option domain-name-servers fe80::1;
interface br0 {
        address-pool pool1 172800 259200;
};
pool pool1 {
        range 2409:8a28:6e2:1c20::1 to 2409:8a28:6e2:1c20::1000;
};
host immortalwrt {
        duid 00:03:00:01:70:2a:d7:60:77:20;
        prefix 2409:8a28:6e2:1c28::/61 172800 259200;
};

注意前缀不要和光猫 br0 自用的 /64 重叠。比如光猫自用 1c20::/64 时，不要再把 1c20::/64 委派给二级路由。

重启 DHCPv6 Server：

1
2
3


killall dhcp6s 2>/dev/null
sleep 1
/userfs/bin/dhcp6s -c /etc/dhcp6s.conf br0 -p /var/run/dhcp6s.pid &

4. 配置 ImmortalWrt 请求 PD

1
2
3
4
5
6


uci set network.wan6.proto='dhcpv6'
uci set network.wan6.device='eth1'
uci set network.wan6.reqaddress='try'
uci set network.wan6.reqprefix='60'
uci set network.lan.ip6assign='64'
uci commit network

LAN 侧用 RA/DHCPv6 Server：

1
2
3
4
5
6
7


uci set dhcp.lan.ra='server'
uci set dhcp.lan.dhcpv6='server'
uci set dhcp.lan.ndp='disabled'
uci delete dhcp.lan.ra_flags 2>/dev/null
uci add_list dhcp.lan.ra_flags='managed-config'
uci add_list dhcp.lan.ra_flags='other-config'
uci commit dhcp

如果之前做过 NDP Relay，建议清理 wan6 上的 relay 残留，避免以后排障混乱：

1
2
3
4
5
6


uci delete dhcp.wan6.ra 2>/dev/null
uci delete dhcp.wan6.dhcpv6 2>/dev/null
uci delete dhcp.wan6.ndp 2>/dev/null
uci delete dhcp.wan6.master 2>/dev/null
uci set dhcp.wan6.ignore='1'
uci commit dhcp

重启服务：

1
2
3
4
5


ifdown wan6
sleep 3
ifup wan6
/etc/init.d/odhcpd restart
/etc/init.d/dnsmasq restart

验证：

1
2
3


ifstatus wan6 | grep -A20 '"ipv6-prefix"'
ip -6 addr show dev br-lan
ip -6 route show

正常应该能看到：

1
2
3


wan6 获得 2409:8a28:6e2:1c28::/61
br-lan 获得 2409:8a28:6e2:1c28::1/64
LAN 客户端获得 2409:8a28:6e2:1c28::/64 内的地址

一个容易踩的坑：不要把动态 GUA 写死到 ra_dns

当前这台 ImmortalWrt 里有一项：

1

dhcp.lan.ra_dns='2409:8a28:6e2:1c28::1'

这在当前前缀不变时能工作，但它绑定了动态公网前缀。如果以后光猫重新拨号后前缀变化，客户端可能继续收到过期 DNS 地址。

更稳的做法是：

不手动写死 ra_dns，让 odhcpd 按当前接口状态发布 DNS；
或者发布稳定的公网 IPv6 DNS；
或者使用稳定 ULA 地址作为路由器 LAN 侧 DNS 地址。

如果只是为了快速验证，写死当前 br-lan 地址没问题；要长期运行，建议避免这种配置。

临时方案：NDP Relay

只有在下面这种情况下才考虑 NDP Relay：

光猫没有给二级路由委派 PD；
暂时拿不到光猫超管；
只是想临时让 LAN 设备获得 IPv6。

NDP Relay 的本质是把上游 /64 共享给下游 LAN，能用但不如 DHCPv6-PD 标准。它依赖运营商没有做严格的 ND/SAVI 检查，也容易在前缀变化时出问题。

如果已经能让光猫给 ImmortalWrt 下发 PD，就不要再把 LAN 配成 NDP Relay。

光猫配置持久化问题

这类光猫的文件系统比较特殊：

根文件系统是 squashfs，只读。
/etc 通常是启动后生成到 tmpfs 的运行期目录。
/etc/dhcp6s.conf 很可能重启后恢复。
我这台固件上 /userfs 看起来在根文件系统内，不是可靠可写分区；之前尝试写入会报 Read-only file system。
/usr/osgi 是 jffs2 可写区，但它属于 OSGi/插件运行区，不建议随便塞启动脚本。

所以不要简单照抄“把脚本追加到 /etc/init.d/rcS”这种做法。这个固件的 /etc/init.d/rcS 来自只读系统，直接修改不可持久；如果某些机型上能改，也要先确认重启后是否保留。

更稳的持久化路线：

通过配置导出/导入修改 romfile 中的 DHCPv6 配置；
找装维把光猫改桥接，让 ImmortalWrt 直接拨号；
如果确认有可靠可写启动钩子，再做自动替换 dhcp6s.conf 的脚本。

Web 超管页面里隐藏的配置导入页面是：

1

http://192.168.1.1/cgi-bin/upgrade.asp

其中 romfile 是配置导入，tclinux.bin 是固件导入。改配置前务必先备份原配置。

TR-069、UPnP 和远程管理

拿到超管和 Telnet 后，我做了这些安全收敛：

1
2
3
4
5
6
7
8


tcapi set Cwmp_Entry Active No
tcapi set Cwmp_Entry Tr069Enable 0
tcapi set Cwmp_Entry periodActive No
tcapi set Cwmp_Entry tr069Commit 1
tcapi commit Cwmp_Entry
tcapi save
killall tr69_monitor 2>/dev/null
killall tr69 2>/dev/null

当前确认：

1
2
3


Cwmp_Entry Active=No
Cwmp_Entry Tr069Enable=0
Cwmp_Entry periodActive=No

UPnP 保持开启，因为内网仍然需要；但不要把 UPnP、Web、Telnet 暴露到 WAN。当前运行期防火墙已经对 ppp+ 和 nas+ 的管理端口做了 DROP，Web 80 还有系统自带的 !br+ DROP 规则。Telnet 23 的 WAN DROP 规则目前是运行期规则，重启后仍需复核。

一句话：Telnet/Web 可以开，但只应该对内网开。TR-069 建议关闭。UPnP 如果要保留，也只保留 LAN 侧可用。

海外 IPv6 不通的问题

本地前缀和 DHCPv6-PD 配好后，国内 IPv6 站点正常：

1
2
3
4


ping6 -c 3 2400:3200::1
wget -6 -q -O /dev/null --timeout=8 https://www.baidu.com
wget -6 -q -O /dev/null --timeout=8 https://www.qq.com
wget -6 -q -O /dev/null --timeout=8 https://www.aliyun.com

但海外 IPv6 常见现象是：ICMPv6 能 ping，TCP/443 不通或超时。之前抓包能看到本地 SYN 发出，但收不到 SYN-ACK。

这更像中国移动 IPv6 国际出口策略或链路质量问题，不是本地 RA/DHCPv6 配错。判断方法：

国内 IPv6 HTTPS 正常；
本地路由器有默认 IPv6 路由；
LAN 设备拿到正确公网 IPv6；
海外 TCP 单独失败。

解决办法通常不是改 DHCPv6，而是走 IPv4 代理，或换 IPv6 国际出口更好的运营商。

总结

项目	当前结论
ISP 是否给前缀	给了光猫 `/60`
光猫自用前缀	`2409:8a28:6e2:1c20::/64`
委派给 ImmortalWrt	`2409:8a28:6e2:1c28::/61`
ImmortalWrt LAN	`2409:8a28:6e2:1c28::/64`
LAN DHCP/RA	RA Server + DHCPv6 Server，NDP Relay 关闭
国内 IPv6	正常
海外 IPv6 TCP	运营商出口问题概率高
TR-069	已关闭
UPnP	保留 LAN 侧使用，不暴露 WAN

最关键的修正是：不要把这个问题简单归因成“ISP 不下发前缀”。现场证据表明，ISP 给了光猫 /60；真正要做的是让光猫的 DHCPv6 Server 把合适的子前缀委派给 ImmortalWrt。

背景