深圳电信也有了。一条在南山的宽带已经割接到了 vbras 上，按照返回的名称来看，应该是华为的 VNE9000 。发送一个 PPPoE Discovery 包，会有四个 MAC 地址响应。一个快一点三个慢一点，顺序不确定。在罗湖和宝安的两条宽带看起来还没有变，依旧是 M6000 和 NE40E 。

看来大家都学会了低价中标，后续高价卖 License 和维护的套路了蛤蛤

@yulihao 同意。PON 上线前会测距的，根据距离调整发送延迟。而且上行时间片的精度很高，远不是 NTP 能达到的精度。因为 NTP 没同步导致 PON 上行时间片没对齐绝对是 SoC 的严重 bug ，根本不可能上市。感觉还是光猫里什么奇奇怪怪的应用程序影响了数据平面的转发，而不是时间片没对齐。

「坛友是运营商是什么体验」

@oblivion 在 TCP 里发大包还是有点麻烦的，要旁路掉内核的 MSS 控制和网卡的 TSO ，得魔改内核和应用层，没法过 CDN 。估计只能用在 IoT 或者推送之类的应用上。不过检测 MTU 只能检测出 L2/L3 的 VPN ，遇到 Shadowsocks 这样的 L4 代理就没办法了。

对于 ICMP 响应，看来他们的逻辑是越符合 RFC 越有问题。这倒是也有道理。运营商 CGN 、一般的 NAT 网关很可能不会响应 ICMP ，而很多 Linux 服务器不太会屏蔽掉 ICMP 。我感觉以后默认的 iptables 得屏蔽掉太大的 ICMP Echo Request 。

@bibiisme 这不就是我说的在自己的盒子里做非标行为嘛。没看到具体的协议细节，但是看之前的描述，这个绝无进 RFC 的可能。也就 CTC 之类的大运营商能在设备商和客户两边强推。

现在的 IPoE 没有用户名 /密码之类的信息，仅靠物理设备的位置进行认证。这要求整个接入网络的管理要求非常严格准确，风险很大的。哪怕是 PON ，也会出现安装的时候实际可用的资源和系统记录的资源对不上这种情况，更别说以太网入户那种了。PPPoE 在接入时有用户名密码校验，位置和系统记录不匹配会被发现，IPoE 可能就没机会了。在中国这个对“落地查人”要求很高的场合，大量出现此类问题是不可接受的。这种情况下，运营商只能在自己的盒子里做非标行为来加强控制，不仅给后期维护带来了麻烦，用户的选择权也自然受到限制。
回过头看看历史，PON 上运营商很多都选择了与物理设备无关的 LOID 认证，机卡和一的手机最终还是被淘汰了。早期的小区宽带都是 IPoE 的，最后也转向了 PPPoE 。
所以我认为，IPoE 需要提供一种标准化的，与物理设备和位置无关的，包含用户标识和保密认证信息的认证方式，要不迟早被运营商玩坏。

@Siril 我倒是觉得基于延迟判断非常靠谱。延迟最低极限的，而旁路劫持的 RTT 一般很低，通过不断采样 RTT，发现 RTT 急剧减小基本就可以判定是出现劫持了。不过这样要写程序追踪每一个 tcp 流了……

曾经遇到过 ISP 劫持无响应的 http 链接（ nb 吧），后来抓包看，本机向一个不在线的 IP 连发 5 个 SYN 之后，居然有 ACK 回过来！！然后就被劫持了……

@fromdaytonight 教育网重大节点终于不是摆设了(ง •̀_•́)ง

劫持的问题，我抓包找到了证据，写了个文档发给电信，扯了几天皮之后就再也没出现了。
当然，深圳电信一直没有正面回应过这个问题。

单IP限上行即可。下行没必要限，基本跑不满的。

@yksoft1 Host是IP。没找到curl里面怎么改host……

@i8s301a 没做过CDN。我猜测CDN回国链接的http头可能与一般用户连接有明显的不同。

@yksoft1 我抓了下包，从国内请求百度国外CDN似乎没有被干扰的迹象。TTL、IPID、TCP窗口之类的都处于正常模式，无论返回是否是污染过的内容，上面说到的特征字段也无明显区别，RTT都在220ms左右。加上GFW管不到国外，所以我觉得，劫持海外CDN回国链接的概率还是很大的。
从之间的抓包来看，确实GFW有伪造返回。估计这次GFW变换了劫持方式，以免落下口实。

@yksoft1 根据上面现象判断，GFW劫持百度海外CDN镜像与国内通信这种可能性最大，也是解释上面现象最简单的方法。

holy shit, 我的智齿简直和上面的牙片一模一样……
之前医生就说很麻烦，没想到这么麻烦（