V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
ntedshen
V2EX  ›  宽带症候群

江苏常州电信 TCP 间歇性断流

  •  
  •   ntedshen · 2023-09-09 23:50:18 +08:00 · 2675 次点击
    这是一个创建于 447 天前的主题,其中的信息可能已经有所发展或是发生改变。

    额。。。萌新建号以来第一次发帖,主要也不知道能在哪问了。。。

    现在是这个情况,我在两个区都有租房,目前两边都会出现不定时的 tcp 断流,不限于国内外而且不限于设备,手机电脑都会断,每次断三五秒到两分钟不等。。。

    这情况其实持续大概有三个月了,基本每天都是这样。。。

    个人手里的路由有三个,华硕灵耀 AX6600M ,华硕灵耀 XD4 ,锐捷星耀 X32 PRO ,房东的路由两个,tplink 的 WDR5620 ,中国移动 RAX3000Q ,无论开关 ax 的无线还是有线均可复现。。。

    都是光猫直连路由,isp 也都是电信。。。

    光猫一边是烽火 HG6540A ,另一边不详,不过看界面应该也是同款(定制的 op )。。。

    很诡异的就是似乎只断 tcp ,在 tcp 完全无法通信的时候游戏的 kcp ( udp ) 和 icmp 都可以正常使用, 至少 dns 和 ping 甚至后台挂着的 bt 都工作正常。。。

    测试使用的是 deajan 的 tcpping 和普通的 curl

    ping 测试

    八月份的:

     curl -v https://www.bilibili.com/
    * Uses proxy env variable no_proxy == '172.22.112.1,localhost'
    * Uses proxy env variable https_proxy == 'http://172.22.112.1:7890/'
    *   Trying 172.22.112.1:7890...
    * Connected to (nil) (172.22.112.1) port 7890 (#0)
    * allocate connect buffer!
    * Establish HTTP proxy tunnel to www.bilibili.com:443
    > CONNECT www.bilibili.com:443 HTTP/1.1
    > Host: www.bilibili.com:443
    > User-Agent: curl/7.81.0
    > Proxy-Connection: Keep-Alive
    >
    < HTTP/1.1 200 Connection established
    <
    * Proxy replied 200 to CONNECT request
    * CONNECT phase completed!
    * ALPN, offering h2
    * ALPN, offering http/1.1
    *  CAfile: /etc/ssl/certs/ca-certificates.crt
    *  CApath: /etc/ssl/certs
    * TLSv1.0 (OUT), TLS header, Certificate Status (22):
    * TLSv1.3 (OUT), TLS handshake, Client hello (1):
    ↑就停在这不继续了
    

    九月的:

    * Connection #0 to host www.baidu.com left intact
    PS C:\Program Files\Git\mingw64\bin> .\curl.exe "https://www.baidu.com" --verbose
    *   Trying 180.101.50.242:443...
    * connect to 180.101.50.242 port 443 failed: Timed out
    *   Trying 180.101.50.188:443...
    * connect to 180.101.50.188 port 443 failed: Timed out
    * Failed to connect to www.baidu.com port 443 after 43100 ms: Couldn't connect to server
    * Closing connection 0
    curl: (28) Failed to connect to www.baidu.com port 443 after 43100 ms: Couldn't connect to server
    与此同时 ping 这个地址
    PS E:\wwwroot\dev\lib> ping 180.101.50.242
    正在 Ping 180.101.50.242 具有 32 字节的数据:
    来自 180.101.50.242 的回复: 字节=32 时间=7ms TTL=53
    来自 180.101.50.242 的回复: 字节=32 时间=6ms TTL=53
    来自 180.101.50.242 的回复: 字节=32 时间=7ms TTL=53
    来自 180.101.50.242 的回复: 字节=32 时间=6ms TTL=53
    
    180.101.50.242 的 Ping 统计信息:
        数据包: 已发送 = 4 ,已接收 = 4 ,丢失 = 0 (0% 丢失),
    往返行程的估计时间(以毫秒为单位):
    

    curl 的测试结果如上,之前断流时发送 curl 基本就卡在 Client hello (1) 阶段,wireshark 上看感觉就是只有发送但是完全收不到下文。。。

    最近彻底变成 timeout 了。。。

    测试的时候梯子不是没开就是在 direct ,应该没有关系。。。

    家中路由均没有任何插件,都是原版固件加正常的麻瓜配置,拨号都是光猫拨的

    以断流的频次来看似乎和当前的使用量有关,但是。。。想不明白发生了什么。。。

    移动开热点也没有问题,感觉应该是本地电信的问题了吧?

    都不知道该怎么和电信小哥讲这个情况。。。

    求支个招。。。

    11 条回复    2023-09-12 11:15:42 +08:00
    ntedshen
        1
    ntedshen  
    OP
       2023-09-10 00:08:13 +08:00
    想起八月是 wsl 下跑的(这事八月就想问了)。。。
    补一下九月 wsl 下 curl 的结果(之前为了开发方便才开的全局代理,最近已经把全局代理取消了)。。。
    ```
    root@AN515-58:/home/wwwroot# curl https://www.baidu.com --verbose
    * Trying 180.101.50.188:443...
    ```
    linux 的 curl 就停在这了。。。
    1423
        2
    1423  
       2023-09-10 01:14:54 +08:00
    mtu 问题?最好抓包看看
    ntedshen
        3
    ntedshen  
    OP
       2023-09-10 01:34:12 +08:00
    @1423 唔。。。目前的上级就是光猫,拨号也是猫拨的,看来总之得先要到超管密码==。。。
    明天我先就只说老掉线看看能不能直接召唤到小哥,换个猫或者把超管密码套出来先。。。
    toneal
        4
    toneal  
       2023-09-10 03:35:33 +08:00
    电信的 qos 玄学啊
    oblivion
        5
    oblivion  
       2023-09-10 03:40:18 +08:00   ❤️ 1
    扫下 BRAS 看是否割接为了 vBRAS ,
    之前江苏电信割接华为的 VNE9000 的 vBRAS 后同样出现了这个问题,
    排查了两个月没解决,最后投诉给账号单独回退传统 BRAS 了,就正常了。

    长三角的三家运营商去年开始都在强推 vBRAS ,实际体验烂的一塌糊涂,
    首先是遇到了 MTU 的问题,拨号协商 MTU1480 , 但是偶发大于 1460 的包双向丢包,
    再就是遇到了频繁上下线的问题,vBRAS 使用了 12 组 VRRP MAC 地址,电信后端做热升级就只能被迫下线重拨,稳定性远不如传统 BRAS 。
    再后来遇到了丢包率一塌糊涂的情况,间歇性的出城域网丢包 34%以上,
    再后来又遇到了随机高延迟的问题,突然 1~2 分钟出城域网 600+ms ,
    再后来就遇到了 OP 同款问题,TCP 随机不通,

    这些问题都是偶发不能必现,装维联系了一线二线支撑也没查到原因,最后实在没办法给回退华为 ME60 了,一切正常。

    实在是想不通运营商为什么要大面积的改 vBRAS ,基础设施上云+虚拟化+X86 转发搞出来的半成品,问题那么多还在强推。
    des
        6
    des  
       2023-09-10 08:54:33 +08:00
    怎么感觉撞到 SNI 防火墙了,感觉可以测试一下
    erfesq
        7
    erfesq  
       2023-09-10 08:55:54 +08:00 via Android
    一个是硬件,一个是软件。跟光猫的硬桥接软桥接一样。肯定是专门的硬件系统比较稳定
    kdzhq443
        8
    kdzhq443  
       2023-09-10 22:24:40 +08:00
    @oblivion vBRAS 可以理解为电子产品新版本的降本缩水版?
    mewsf
        9
    mewsf  
       2023-09-11 11:11:24 +08:00 via Android
    有没有分别尝试过 http 和 https 协议? 如果 https 经常握手超时,其实可能是 mss 的问题,有些路由器的防火墙没有双向钳制 mss 或者仅仅单向钳制会有这个问题
    ntedshen
        10
    ntedshen  
    OP
       2023-09-11 14:12:00 +08:00   ❤️ 1
    @mewsf http 基本就是直接卡到超时,我在 wireshark 上找往本机的 tcp ,列表直接是空的。。。
    昨天家中老母被掉线到受不了了就打了个 10000 号报修,估计这几日会上门换个猫什么的先试试。。。
    主要工作日我都不住家。。。情况就比较尴尬
    看看家中老母能和电信小哥折腾出什么结果先。。。
    zmcity
        11
    zmcity  
       2023-09-12 11:15:42 +08:00
    @kdzhq443 vBras 是升级版,不成熟 bug 多而已。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2534 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 37ms · UTC 01:24 · PVG 09:24 · LAX 17:24 · JFK 20:24
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.