V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  siyanmao  ›  全部回复第 1 页 / 共 2 页
回复总数  32
1  2  
贵司 IT 老大和管 IT 的 VP 估计已经收拾好东西准备被开了…
172 天前
回复了 MrLonely 创建的主题 宽带症候群 前海通信管理局是干嘛的?
难道前海的接入网不是运营商建的?三大需要租前海的接入网才能开宽带,类似日本运营商租 NTT 线路或者台湾运营商租中华电信线路那样?
@SparkQiu 我为这个事情投诉了电信 n 次,路由器上还有几条 iptables 规则专门检测是否有劫持…
2023-09-18 01:26:55 +08:00
回复了 Benson1212 创建的主题 宽带症候群 震惊!广州电信家宽被割接到 vBRAS 了!
深圳电信也有了。一条在南山的宽带已经割接到了 vbras 上,按照返回的名称来看,应该是华为的 VNE9000 。发送一个 PPPoE Discovery 包,会有四个 MAC 地址响应。一个快一点三个慢一点,顺序不确定。在罗湖和宝安的两条宽带看起来还没有变,依旧是 M6000 和 NE40E 。
2023-08-17 00:53:17 +08:00
回复了 oblivion 创建的主题 宽带症候群 运营商不愿意提上行的几大原因
看来大家都学会了低价中标,后续高价卖 License 和维护的套路了蛤蛤
2023-07-25 18:53:25 +08:00
回复了 oblivion 创建的主题 宽带症候群 光猫改桥接后速度降低的问题与运营商和厂商的探讨
@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 。
2022-08-28 15:31:35 +08:00
回复了 oblivion 创建的主题 宽带症候群 运营商改造为 IPoE 的优势与劣势以及 IPv6 的安全性问题
@bibiisme 这不就是我说的在自己的盒子里做非标行为嘛。没看到具体的协议细节,但是看之前的描述,这个绝无进 RFC 的可能。也就 CTC 之类的大运营商能在设备商和客户两边强推。
2022-08-28 14:47:16 +08:00
回复了 oblivion 创建的主题 宽带症候群 运营商改造为 IPoE 的优势与劣势以及 IPv6 的安全性问题
现在的 IPoE 没有用户名 /密码之类的信息,仅靠物理设备的位置进行认证。这要求整个接入网络的管理要求非常严格准确,风险很大的。哪怕是 PON ,也会出现安装的时候实际可用的资源和系统记录的资源对不上这种情况,更别说以太网入户那种了。PPPoE 在接入时有用户名密码校验,位置和系统记录不匹配会被发现,IPoE 可能就没机会了。在中国这个对“落地查人”要求很高的场合,大量出现此类问题是不可接受的。这种情况下,运营商只能在自己的盒子里做非标行为来加强控制,不仅给后期维护带来了麻烦,用户的选择权也自然受到限制。
回过头看看历史,PON 上运营商很多都选择了与物理设备无关的 LOID 认证,机卡和一的手机最终还是被淘汰了。早期的小区宽带都是 IPoE 的,最后也转向了 PPPoE 。
所以我认为,IPoE 需要提供一种标准化的,与物理设备和位置无关的,包含用户标识和保密认证信息的认证方式,要不迟早被运营商玩坏。
@Siril 我倒是觉得基于延迟判断非常靠谱。延迟最低极限的,而旁路劫持的 RTT 一般很低,通过不断采样 RTT,发现 RTT 急剧减小基本就可以判定是出现劫持了。不过这样要写程序追踪每一个 tcp 流了……
2016-11-04 19:33:15 +08:00
回复了 worldtongfb 创建的主题 宽带症候群 有用斐讯 K2 的么 被劫持了自动下载
曾经遇到过 ISP 劫持无响应的 http 链接( nb 吧),后来抓包看,本机向一个不在线的 IP 连发 5 个 SYN 之后,居然有 ACK 回过来!!然后就被劫持了……
2016-08-24 14:04:44 +08:00
回复了 bclerdx 创建的主题 宽带症候群 工程院院士:我国超 80%网络延迟严重 超 90 毫秒
@fromdaytonight 教育网重大节点终于不是摆设了(ง •̀_•́)ง
2016-03-20 21:04:50 +08:00
回复了 zkd8907 创建的主题 宽带症候群 实在是服了中国的运营商了,服务烂收费高。。。
劫持的问题,我抓包找到了证据,写了个文档发给电信,扯了几天皮之后就再也没出现了。
当然,深圳电信一直没有正面回应过这个问题。
2015-05-02 00:31:55 +08:00
回复了 zerh925 创建的主题 问与答 如何对待疯狂下载的室友?
单IP限上行即可。下行没必要限,基本跑不满的。
2015-04-04 14:45:26 +08:00
回复了 siyanmao 创建的主题 分享发现 本次 GFW 劫持百度脚本方式猜测
@yksoft1 Host是IP。没找到curl里面怎么改host……
2015-04-04 14:34:52 +08:00
回复了 siyanmao 创建的主题 分享发现 本次 GFW 劫持百度脚本方式猜测
@i8s301a 没做过CDN。我猜测CDN回国链接的http头可能与一般用户连接有明显的不同。
2015-04-04 14:32:16 +08:00
回复了 siyanmao 创建的主题 分享发现 本次 GFW 劫持百度脚本方式猜测
@yksoft1 我抓了下包,从国内请求百度国外CDN似乎没有被干扰的迹象。TTL、IPID、TCP窗口之类的都处于正常模式,无论返回是否是污染过的内容,上面说到的特征字段也无明显区别,RTT都在220ms左右。加上GFW管不到国外,所以我觉得,劫持海外CDN回国链接的概率还是很大的。
从之间的抓包来看,确实GFW有伪造返回。估计这次GFW变换了劫持方式,以免落下口实。
1  2  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3002 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 32ms · UTC 14:27 · PVG 22:27 · LAX 06:27 · JFK 09:27
Developed with CodeLauncher
♥ Do have faith in what you're doing.