Table of Contents
宽带升级
最近移动给我发短信说宽带可以免费升级到 1000M，从没想过自己还能享受到千兆接入的我就开开心心地去申请了。既然是从 GPON 线路升级到 XGPON，光猫自然是不兼容的，本以为换光猫不是什么大问题，直到和师傅沟通下来才知道新装的光猫在师傅那边已经查不到超管密码了，失去了改桥接自己拨号的唯一官方途径。
当然这也不是什么很大的问题，广大网友早就有了完美的解决方法，只要在网络黑市闲鱼上购买一个卖家破解好的光猫，拷贝上原有光猫里的参数，就可以完美家猫换野猫，改桥接自然也就不在话下了
顺着前人探索过的道路，在闲鱼上淘了一个中兴的 F7005MV3。这是移动自己的定制型号，功耗很低，没有累赘的 Wi-Fi 和固定电话功能，属于物美价廉的弱电箱神器。不过发现闲鱼上的破解服务竟然是按次收费的，估计是利用了中兴固件里没有公开的后门。作为折腾星人自然是不能接受这样的垄断，遂选择自己给野猫开天灵盖，连上 TTL 线，通过擦除 usercfg 分区来重置光猫到初始模式。折腾光猫固件也是一件很好玩的事情，挖个坑以后单独写一篇来讲这个，此处就先按下不表。
诡异问题
克隆完参数以后光路鉴权都很正常，保险起见，就想先用电脑连网线拨号测试一下看看是否能正常工作。结果问题就来了，macOS 的拨号界面就一直卡在那里，没有一丝成功的样子。本以为是光猫的参数还有问题，可惜折腾了一大圈还是毫无进展。这时突然想到，诶，是不是可以用光猫自带的拨号先试一下？
令人大跌眼镜的事情发生了，光猫自带的拨号轻轻松松就连上了网络，证明光猫端的配置都是正确的，只是从电脑端发起拨号时才出现了问题。可是这都 2026 年了，PPPoE 这种用了几十年成熟到不能再成熟的协议怎么还能出问题？毕竟又不是二十年前暴露年龄的星空极速，一个还算主流的操作系统在知名运营商的标准拨号线路上无法使用这件事情勾起了我极大的好奇心。
抓包检查
要分析这个问题，必须要能查看光猫在光链路上传递给 OLT 的数据包。中兴的原厂固件非常贴心地提供了 tcpdump 工具，这使得我们在光猫上对光口的 PPPoE 流量进行抓包分析成为了可能。经过一番折腾，成功抓到了成功和失败场景下的 PPPoE 相关流量：
问题分析
在读懂上面两张图之前，先要了解 PPPoE 是怎么工作的。一个典型的拨号流程大概是这样的：
- PPPoE Discovery 阶段
- 客户端通过广播 PADI 在二层上找 BRAS
- BRAS 回应 PADO，让客户端知道自己的 MAC 地址
- 客户端向 BRAS 发送 PADR，请求建立会话
- BRAS 回应 PADS，告诉客户端 Session ID，双方进入 PPP 会话协商阶段
- PPP Session 协商阶段
- 双方通过 LCP 协商链路参数
- 双方通过 PAP/CHAP 进行认证
- 双方协商网络层参数（IP 地址等）
- 链路建立成功，传输用户层数据包
知道了大概流程以后，对比来看，出问题的拨号流程显然没有走到 PAP 认证阶段。客户端在主动发出 PADR 后到 BRAS 回应 PADS 前突然又主动发出了一个 PADT 报文，告诉 BRAS 终止会话。由于这个报文是 macOS 主动发出的，说明系统认为拨号失败了，所以才主动中止会话。
那 macOS 是看到了什么才会发出 PADT 呢？我们发现，BRAS 在回应 PADS 前就发送了一个 Configuration Request 报文，猜测是想要尽早协商链路参数，但这是一个非标行为，按照 PPPoE 的标准流程，BRAS 应该在回应 PADS 后才开始发送 Configuration Request 报文。由于 macOS 没有收到 PADS 就收到了 Configuration Request，认为 BRAS 的回应不合法，所以就发出了 PADT 来中止会话。
可是为什么 macOS 的界面会 freeze 在拨号状态很长时间呢？通过抓包可以看到，即使在发出 PADT 之后，macOS 却仍然在不停发送 Configuration Request 报文，试图和 BRAS 继续协商链路参数。由于 BRAS 收到了 PADT 不再回应 Configuration Request，macOS 就卡在那边死等直到兜底超时事件发生以后才真正放弃拨号，导致界面 freeze 了很长时间。
根据标准流程，发出 PADT 后 PPPoE 栈应该意识到自己不再处于 Session 协商状态了，不应该再发送 Configuration Request 报文。这说明 macOS 的 PPPoE 实现本身也存在缺陷，没有正确管理会话状态，导致在发出 PADT 后没有回到 PPPoE Discovery 阶段，仍然继续发送 Configuration Request 报文。
一些结论
- 这个问题是由 BRAS 的非标行为引起的，BRAS 在回应 PADS 前就抢着发送了 Configuration Request 报文，违反了 PPPoE 的标准流程。
- macOS 的 PPPoE 实现过于严格遵守标准流程，在遇到非标行为时没有容错能力，直接发出 PADT 来中止会话，导致拨号失败。
- macOS 自身的 PPPoE 实现也存在缺陷，即使在发出 PADT 之后仍然继续发送 Configuration Request 报文，缺乏对会话状态的正确管理，导致界面 freeze。
后记
意识到这个问题以后，我和移动的装维小哥沟通了这个问题。装维小哥表示移动宽带已经不再接受用户通过自己的设备进行拨号，任何非光猫拨号的行为都无法获得技术支持。
一番搜索以后，发现有人在 2019 年就已经发现了这个问题，看来这个问题已经存在了至少七八年了。遥想二十多年前，在 Windows XP 之前的时代，系统是不自带 PPPoE 拨号功能的，用户需要安装第三方拨号软件来进行拨号，兼容性问题自然是层出不穷。只是没想到到了 2026 年，PPPoE 这种已经存在了几十年的协议在主流的运营商网络上仍然存在兼容性问题，真是让人哭笑不得。