大多数老年人对网络要求低，贪便宜很正常。我之前在给老人换宽带都是提前很久就说过，然后趁过年直接拉了条新的，旧的还剩几个月。

想知道是不是 bras 的问题得抓包才能确定。一般来说 isp 会在 pppoe 虚拟接口上通过 dhcpv6 给 wan 口分配前缀，然后额外配置 pd 给 lan 口分配另一个前缀。

期待 systemd“一统”Windows 的那一天（手动狗头）

光猫拨号？
理论上光猫自身 WAN 口没有公网 IPv6 地址也无所谓，只要能获取到 PD 前缀，WAN 口使用 link-local 地址就可以正常路由。

@Zerek 按规定确实正面是国徽，背面是人像，算是冷门知识了

应该是为了避免用户以为自己只监听了 IPv6 端口，所以只配置了 IPv6 防火墙，而实际 IPv6 端口和 IPv4 端口全部都监听了这种情况。

drain 一般指排空、清空，一个例子是 kubernetes 有一个`kubectl drain`命令可以清空 node 上的所有 pod 。

SSH 既不基于 TLS+SNI ，数据包里面也不包含域名信息，不可能会出现 IP 能连但是用 DDNS 不能连的情况。

@acbot 推荐最新版是因为 22.03 多了很多细化的设置，当然老版本对多数人也够用了

@gearfox 1.3

感谢，我加了一条回复，看有没有人修吧。
我已不用 OPNsense 多年，自己是懒得修了（实在不想去写和调试 PHP 代码）。

哦，还有去掉这两行，防止把“范围”扩展为两位数：

$pd_prefix_from_array[2] = sprintf("%02s", $pd_prefix_from_array[2]);
$pd_prefix_to_array[2] = sprintf("%02s", $pd_prefix_to_array[2]);

pfSense 好像好多年不怎么维护了，netgate 把重点转向 TNSR 了，别抱太大指望。
我找到当时 patch 的位置了，下面两行： https://github.com/opnsense/core/blob/98fe7a38813a78ab818d215bde530711d5676818/src/etc/inc/plugins.inc.d/dhcpd.inc#L1371
https://github.com/opnsense/core/blob/98fe7a38813a78ab818d215bde530711d5676818/src/etc/inc/plugins.inc.d/dhcpd.inc#L1373

可以看到对于前缀长度 60-64 的情况下，比如你举例的 2001:aaaa:bbbb:7890::/60 ，它直接截取了 7890 中的 78 ，然后拼接你指定的 08 (一直到 0C)，得到 7808 至 780C 。

一个简单的 hack 是把 substr($pd_prefix_from_array_out[3], 0, 2)改为 substr($pd_prefix_from_array_out[3], 0, 3)，把 substr($pd_prefix_to_array_out[3], 0, 2)改为 substr($pd_prefix_to_array_out[3], 0, 3)。当然这只针对你的使用情况，换成其他长度的前缀或者两位数的范围会出错。

@87728854 有两三年了吧，不知道你用的什么版本，如果不是最新版可以尝试一下最新版本看看修了没。我不确定能否找到当时的 patch 。

我印象中它的 IPv6 前缀运算那部分用的是字符串截取和拼接，而不是转为 long int 形式做数学运算。在从 WAN 口拿到 PD 前缀后截取一部分字符串，再拼上后缀。然后我记得它只处理了 /48 ，/56 等几种情况，对 /60 或者其他长度的前缀处理会出错。

巧了，我以前折腾过 OPNSense 的 DHCPv6-PD 功能，也遇到过类似的问题，读过那部分代码，结论是代码里有 bug ，它直接硬编码了几个 prefix 的长度作的掩码运算，没有 honor 你的 /62.
我当时手动 hack 了那部分代码解决的问题。
时间太久了，我无法直接找到当时的修改了。修那个 bug 时让我觉得代码质量太差，后来直接换 VyOS 了。
其实最新的 OpenWRT 也不错，特别是最新的 22.03 RC ，对 IPv6 的支持我觉得是普通用户能接触到的固件里面最好的了。

外企工作的表示，只能在国内公司设在国内的 VPN 节点，国外的节点全都被墙了，可能是因为没和有关部门备案吧。

此外要注意一下防火墙规则，允许从 eth1.85 input 方向和 forward 到 lan 的组播流量。

建议直接去掉 iptv 这个 bridge,直接用 eth1.85 作 UDPXY 的上行端口，排除 bridge 的问题。