解決方案(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 的問題,而且顯然是常見問題。在互聯網上發布了許多針對此問題的潛在解決方案,但對我有用的解決方案是在這個蘋果討論線程

解決方案

將您的/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 設備。當我購買了一個像樣的路由器後,這個問題立即消失了,自從兩個月前換了新路由器後,問題就沒有再出現過。

解決方案

購買一個像樣的路由器並將其用於您的 Wi-Fi。

作為參考,我買的路由器是華碩 RT-AC68U:https://www.asus.com/us/Networking/RTAC68U/

答案2

猜測,我會說這是一個路由器問題。確保您安裝了最新的韌體或嘗試另一個已知可以工作的路由器。

答案3

我遇到了斷線、網路速度慢和調製解調器問題,所以我做了以下事情:

  • 2014 年 11 月之前,我有一個 SB6121 數據機和 comcast 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。到目前為止很高興,但目前我不太有信心它會保持穩定。如果沒有,我會懷疑到桿的線路或到康卡斯特頭端的線路有問題。只是猜測,但時間會證明一切。

  • 05/22/2015 事件日誌為空(很好),速度測試結果 118.4 下降 23.4 上升

    截至今天早上的連線狀態,無法糾正的代碼字較高,但我的兒子玩坦克世界超過 5 小時,而我的孫子玩 Minecraft 和大量 YouTube 剪輯超過 6 小時或更長時間。同時,我和我的妻子都上網並同時播放一部 netfilx 電影。沒有人抱怨任何問題,到目前為止一切都很好。

    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

我希望這可以幫助你們中的一些人。

相關內容