解决方案(2015 年 5 月 24 日)

解决方案(2015 年 5 月 24 日)

每隔 10-15 分钟,我的互联网连接就会出现以下失败情况:

  • 无法加载网站
  • 无法连接到 Dropbox
  • 无法连接到 IRC
  • Skype 仍然有效
  • Slack 仍然有效
  • 仍能连接到我的路由器调制解调器

经过大量搜索,我相信这是一个 DNS 问题。我尝试使用我的 ISP 的 DNS 服务器和 Google 的 DNS 服务器,但问题仍然存在。

当我断开 Wi-Fi 网络并重新连接时,问题消失并且一切可以正常工作 10-15 分钟。

ping以下是出现问题时的一些测试的输出:

# ping 8.8.8.8 (Google's DNS server, becomes unreachable)

64 bytes from 8.8.8.8: icmp_seq=11589 ttl=41 time=61.719 ms
64 bytes from 8.8.8.8: icmp_seq=11590 ttl=41 time=61.869 ms
64 bytes from 8.8.8.8: icmp_seq=11591 ttl=41 time=60.212 ms
64 bytes from 8.8.8.8: icmp_seq=11592 ttl=41 time=60.332 ms
64 bytes from 8.8.8.8: icmp_seq=11593 ttl=41 time=65.169 ms
64 bytes from 8.8.8.8: icmp_seq=11594 ttl=41 time=61.890 ms
64 bytes from 8.8.8.8: icmp_seq=11595 ttl=41 time=59.746 ms
64 bytes from 8.8.8.8: icmp_seq=11596 ttl=41 time=60.221 ms
Request timeout for icmp_seq 11602
Request timeout for icmp_seq 11603
Request timeout for icmp_seq 11604
Request timeout for icmp_seq 11605
Request timeout for icmp_seq 11606
Request timeout for icmp_seq 11607
Request timeout for icmp_seq 11608
Request timeout for icmp_seq 11609

# ping 203.144.206.49 (ISP's DNS server, automatically configured, becomes unreachable)

64 bytes from 203.144.206.49: icmp_seq=1418 ttl=249 time=27.160 ms
64 bytes from 203.144.206.49: icmp_seq=1419 ttl=249 time=23.846 ms
64 bytes from 203.144.206.49: icmp_seq=1420 ttl=249 time=25.674 ms
64 bytes from 203.144.206.49: icmp_seq=1421 ttl=249 time=25.712 ms
64 bytes from 203.144.206.49: icmp_seq=1422 ttl=249 time=25.169 ms
64 bytes from 203.144.206.49: icmp_seq=1423 ttl=249 time=24.310 ms
64 bytes from 203.144.206.49: icmp_seq=1424 ttl=249 time=26.983 ms
64 bytes from 203.144.206.49: icmp_seq=1425 ttl=249 time=26.477 ms
Request timeout for icmp_seq 1428
Request timeout for icmp_seq 1429
Request timeout for icmp_seq 1430
Request timeout for icmp_seq 1431
Request timeout for icmp_seq 1432
Request timeout for icmp_seq 1433
Request timeout for icmp_seq 1434
Request timeout for icmp_seq 1435

# ping 192.168.1.1 (modem, remains reachable)

64 bytes from 192.168.1.1: icmp_seq=1760 ttl=64 time=1.571 ms
64 bytes from 192.168.1.1: icmp_seq=1761 ttl=64 time=1.414 ms
64 bytes from 192.168.1.1: icmp_seq=1762 ttl=64 time=1.421 ms
64 bytes from 192.168.1.1: icmp_seq=1763 ttl=64 time=1.439 ms
64 bytes from 192.168.1.1: icmp_seq=1764 ttl=64 time=1.600 ms
64 bytes from 192.168.1.1: icmp_seq=1765 ttl=64 time=2.117 ms
64 bytes from 192.168.1.1: icmp_seq=1766 ttl=64 time=1.354 ms
64 bytes from 192.168.1.1: icmp_seq=1767 ttl=64 time=1.395 ms
64 bytes from 192.168.1.1: icmp_seq=1768 ttl=64 time=1.492 ms
64 bytes from 192.168.1.1: icmp_seq=1769 ttl=64 time=1.326 ms
64 bytes from 192.168.1.1: icmp_seq=1770 ttl=64 time=1.641 ms
64 bytes from 192.168.1.1: icmp_seq=1771 ttl=64 time=1.428 ms
64 bytes from 192.168.1.1: icmp_seq=1772 ttl=64 time=1.459 ms
64 bytes from 192.168.1.1: icmp_seq=1773 ttl=64 time=1.517 ms
64 bytes from 192.168.1.1: icmp_seq=1774 ttl=64 time=1.429 ms
64 bytes from 192.168.1.1: icmp_seq=1775 ttl=64 time=2.007 ms

以下是traceroute连接成功和失败时的情况:

# traceroute 8.8.8.8 (connection is working)

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  1.314 ms  3.256 ms  1.089 ms
 2  cm-134-196-10-1.revip18.asianet.co.th (134.196.10.1)  9.022 ms  9.922 ms  9.988 ms
 3  10.92.249.49 (10.92.249.49)  23.733 ms  16.544 ms  17.930 ms
 4  203-144-128-34.static.asianet.co.th (203.144.128.34)  23.399 ms  22.948 ms  23.950 ms
 5  203-144-128-33.static.asianet.co.th (203.144.128.33)  23.067 ms
    203-144-128-29.static.asianet.co.th (203.144.128.29)  25.810 ms
    203-144-128-33.static.asianet.co.th (203.144.128.33)  23.437 ms
 6  61-91-213-177.static.asianet.co.th (61.91.213.177)  25.623 ms  23.378 ms  24.319 ms
 7  61-91-213-35.static.asianet.co.th (61.91.213.35)  26.058 ms  26.429 ms  31.222 ms
 8  61-91-213-81.static.asianet.co.th (61.91.213.81)  25.335 ms  25.126 ms  23.935 ms
 9  tig-net25-61.trueintergateway.com (122.144.25.61)  24.232 ms
    tig-net25-105.trueintergateway.com (122.144.25.105)  27.276 ms
    tig-net25-209.trueintergateway.com (122.144.25.209)  28.039 ms
10  72.14.195.115 (72.14.195.115)  49.303 ms  49.605 ms  50.321 ms
11  209.85.242.240 (209.85.242.240)  49.322 ms  50.768 ms  49.716 ms
12  209.85.242.242 (209.85.242.242)  58.872 ms  60.480 ms
    209.85.242.232 (209.85.242.232)  67.498 ms
13  209.85.246.23 (209.85.246.23)  62.638 ms
    209.85.248.25 (209.85.248.25)  60.055 ms  60.914 ms
14  * * *
15  google-public-dns-a.google.com (8.8.8.8)  61.586 ms  60.368 ms  61.882 ms

# traceroute 8.8.8.8 (connection is NOT working)

traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 5  * * *
 (it goes on like this until the connection kicks in again)

有什么想法可以解决这个问题吗?

答案1

解决方案(2015 年 5 月 24 日)

不稳定的连接原来是 Mac OS X Yosemite 的一个问题,而且似乎是一个常见问题。互联网上发布了许多针对此问题的潜在解决方案,但对我有用的解决方案来自此 Apple 讨论主题

解决方案

/Library/Preferences/SystemConfiguration文件夹移至桌面(这样您就有了备份)并重新启动。OS X 将在重新启动时重新生成默认网络设置。

sudo mv /Library/Preferences/SystemConfiguration ~/Desktop
sudo shutdown -r now

编辑(2016年11月8日)

自从我发了这个问题之后,我已经搬家了,这个问题也跟着我到了新家(不同的国家,不同的 ISP)。我发现我可以在别人的 Wi-Fi 上使用我的笔记本电脑,没有任何问题,但我一回到家,问题又出现了。

不稳定的连接原来是一些 ISP 提供的廉价路由器的问题。

我以前的 ISP 提供的是评价很差的 Technicolor 设备,而我现在的 ISP 提供的是老款 Cisco 设备。我买了一个不错的路由器后,问题立即消失,而且自从 2 个月前换了新路由器后就再也没有出现过。

解决方案

购买一个合适的路由器并将其用于您的 Wi-Fi。

作为参考,我购买的路由器是华硕RT-AC68U:https://www.asus.com/us/Networking/RTAC68U/

答案2

我猜是路由器的问题。请确保安装了最新固件,或者尝试使用其他已知可以正常工作的路由器。

答案3

我遇到了断线、网速慢和调制解调器问题,所以我做了以下事情:

  • 2014 年 11 月之前,我有一个 SB6121 调制解调器和康卡斯特 Blast 50/10,不记得有断线或速度问题。

  • 2014 年 11 月(我想)我升级到了 extrem 105 并开始随机出现断开连接的问题(调制解调器坏了??)

  • 2015 年 1 月将调制解调器升级到 SB6141。仍然有随机断开连接的问题(比 SB6121 更糟糕),上传通道 3 上有很多 t4 超时以及其他错误

  • 四月或五月,我请康卡斯特的技术人员来检查。技术人员说他们这边没有发现任何问题,但无法让康卡斯特调制解调器正常工作,所以他重新安装了 SB6141 就离开了。(花了我 70 美元)仍然有随机断开连接的情况。也许是调制解调器坏了???

  • 2015 年 5 月 20 日安装了 Zoom 5341J 调制解调器。检查状态页面发现 8 个下行通道中只有 4 个已绑定,但互联网正常,但无法纠正的代码字非常多。

     Downstream Bonded Channels
    1   QAM256  621000000 Hz    -0.8 dBmV   39.8 dB 615 1643
    2   QAM256  615000000 Hz    -1.3 dBmV   39.4 dB 810 1634
    3   QAM256  627000000 Hz    -0.1 dBmV   39.9 dB 522 1520
    4   QAM256  633000000 Hz    -0.6 dBmV   39.9 dB 520 1916
    5   unknown         0 Hz    -0.0 dBmV    0.0 dB   0    0
    6   unknown         0 Hz    -0.0 dBmV    0.0 dB   0    0
    7   unknown         0 Hz     0.0 dBmV    0.0 dB   0    0
    8   unknown         0 Hz     0.0 dBmV    0.0 dB   0    0
    
    Upstream Bonded Channels
    
    1   ATDMA   5120 Ksym/sec   29500000 Hz 46.8 dBmV
    2   ATDMA   5120 Ksym/sec   36400000 Hz 37.5 dBmV
    3   ATDMA   5120 Ksym/sec   22600000 Hz 36.5 dBmV
    4   Unknown  0 Ksym/sec        0 Hz  0.0 dBmV
    Total Correctables  Total Uncorrectables
               2467           6713
    
    Current System Time: Wed May 20 08:15:48 201
    
  • 我与康卡斯特进行了一次聊天,以查明为什么只有 4 个通道绑定而不是 8 个,并被告知调制解调器可能设置为 5341 而不是 5341J,需要重新激活,所以我需要打电话给康卡斯特。我打了电话,最后在电话里聊了 30 分钟或更长时间后,技术人员说我应该在 24 小时内看到变化。一小时后,我查看了状态页面,发现所有 8 个通道都已绑定。没有互联网问题。

  • 用 RG6 电缆替换了从室外到调制解调器的所有电缆。发现旧电缆的线路中有 2 个接头连接器。只需确保电缆不会造成任何问题。

  • 2015 年 5 月 21 日上午,我感到很奇怪,但我注意到下行功率水平非常高,为 +12db 至 +16db,但在更换电缆之前,功率水平与上文相同。似乎这种变化可能是由于更换电缆造成的,因此我在下行链路上添加了一个 12db 衰减器,这样功率水平就下降到:

    Downstream Bonded Channels
    1   QAM256  591000000 Hz    -2.3 dBmV   39.4 dB 38  195
    2   QAM256  597000000 Hz    -2.1 dBmV   39.4 dB 0   0
    3   QAM256  603000000 Hz    -1.1 dBmV   39.9 dB 0   0
    4   QAM256  609000000 Hz    -0.1 dBmV   39.9 dB 0   0
    5   QAM256  615000000 Hz    -0.1 dBmV   39.8 dB 0   0
    6   QAM256  621000000 Hz    -0.1 dBmV   39.9 dB 0   0
    7   QAM256  627000000 Hz     0.4 dBmV   39.9 dB 0   0
    8   QAM256  633000000 Hz     0.2 dBmV   39.5 dB 0   0
    

    我觉得上行功率水平有点高(可能是因为衰减器),但在规格范围内

    Upstream Bonded Channels
    
    1   ATDMA   5120 Ksym/sec   22600000 Hz 44.5 dBmV
    2   ATDMA   5120 Ksym/sec   29500000 Hz 46.0 dBmV
    3   ATDMA   5120 Ksym/sec   36400000 Hz 46.0 dBmV
    4   Unknown  0 Ksym/sec        0 Hz  0.0 dBmV
    
  • 2015 年 5 月 21 日下午,除了无法纠正的代码字(195)外,到目前为止没有出现互联网问题,不确定这是否会是个问题。

    新状态页面结果:

    Downstream Bonded Channels
    1   QAM256  591000000 Hz    -2.3 dBmV   39.4 dB 38  195
    2   QAM256  597000000 Hz    -2.0 dBmV   39.5 dB 0   0
    3   QAM256  603000000 Hz    -1.1 dBmV   39.8 dB 0   0
    4   QAM256  609000000 Hz     0.0 dBmV   40.2 dB 0   0
    5   QAM256  615000000 Hz    -0.1 dBmV   39.9 dB 0   0
    6   QAM256  621000000 Hz    -0.2 dBmV   39.9 dB 0   0
    7   QAM256  627000000 Hz     0.3 dBmV   39.9 dB 0   0
    8   QAM256  633000000 Hz     0.2 dBmV   39.9 dB 0   0
    
    
    Upstream Bonded Channels
    
    1   ATDMA   5120 Ksym/sec   22600000 Hz 44.5 dBmV
    2   ATDMA   5120 Ksym/sec   29500000 Hz 46.0 dBmV
    3   ATDMA   5120 Ksym/sec   36400000 Hz 46.0 dBmV
    4   Unknown  0 Ksym/sec        0 Hz  0.0 dBmV
    

    使用距离 40 英尺的 R8000 路由器的无线连接,速度测试结果为下载 111,上传 23.41。到目前为止,我感到很满意,但目前我不太确定它是否会保持稳定。如果不是,我怀疑电线杆的线路或康卡斯特头端的线路存在问题。只是猜测,但时间会证明一切。

  • 2015 年 5 月 22 日事件日志为空(很好),速度测试结果为 118.4 下降 23.4 上升

    截至今天早上的连接状态,无法纠正的代码字较高,但我的儿子玩了 5 个多小时的坦克世界,而我的孙子玩了 6 个小时或更长时间的 Minecraft 和大量 YouTube 剪辑。与此同时,我和妻子都在上网,同时播放 Netflix 电影。到目前为止,没有人抱怨任何问题。

    Downstream Bonded Channels
    1   QAM256  591000000 Hz    -2.2 dBmV   39.6 dB 539 2770
    2   QAM256  597000000 Hz    -2.0 dBmV   39.8 dB 202 957
    3   QAM256  603000000 Hz    -1.1 dBmV   39.9 dB 0   0
    4   QAM256  609000000 Hz    -0.1 dBmV   40.3 dB 0   0
    5   QAM256  615000000 Hz    -0.1 dBmV   39.8 dB 0   0
    6   QAM256  621000000 Hz    -0.1 dBmV   39.9 dB 0   0
    7   QAM256  627000000 Hz     0.4 dBmV   40.0 dB 0   0
    8   QAM256  633000000 Hz     0.2 dBmV   39.9 dB 0   0
    
    
    Upstream Bonded Channels
    
    1   ATDMA   5120 Ksym/sec   22600000 Hz 44.5 dBmV
    2   ATDMA   5120 Ksym/sec   29500000 Hz 46.0 dBmV
    3   ATDMA   5120 Ksym/sec   36400000 Hz 46.0 dBmV
    4   Unknown    0 Ksym/sec          0 Hz  0.0 dBmV
    

答案4

以下是我遇到此问题时使用的一个小脚本:

#!/bin/sh

while [ true ]
do

    ping -W 500 -c 1 192.168.1.1

    if [ $? -eq 2 ]
    then
        arp-scan -l -I en0
    else
        sleep 1
    fi
done

我希望这可以为你们提供一些帮助。

相关内容