web-dev-qa-db-ja.com

LinksysAPがLinksysメインルーターへの接続を失う

地下にメインルーターとしてWRT1900があり、次の階にAPとしてWRT1200があります。それらはイーサネットケーブルで接続されています。私の問題は、WRT1200 APに接続しているときに、このAPがメインルーターへの接続を失うように見えることです。私はラップトップに1日を通してランダムに何百回もpingを実行させることでテストしますが、それ自体を修正する前に30〜60秒間接続が切断されることがよくあります。ただし、問題が常に解決するとは限りません。接続が正常になるようにルーターをリセットしなければならない場合があります...再び切断されるまで。まったく新しいケーブルを交換する以外に、これら2つのユニット間のエラーをチェックする方法は他にありますか？編集：以下の結果をpingします。 pingは667回正常に実行され、次にパケットを27回ドロップし、その後再び正常になりました。

64 bytes from 192.168.1.1: icmp_seq=664 ttl=63 time=4.075 ms
64 bytes from 192.168.1.1: icmp_seq=665 ttl=63 time=4.724 ms
64 bytes from 192.168.1.1: icmp_seq=666 ttl=63 time=5.353 ms
64 bytes from 192.168.1.1: icmp_seq=667 ttl=63 time=4.035 ms
Request timeout for icmp_seq 668
92 bytes from testwifi.here (192.168.86.1): Destination Net Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
 4  5  00 5400 2888   0 0000  40  01 79a6 192.168.86.41  192.168.1.1 

Request timeout for icmp_seq 669
Request timeout for icmp_seq 670
Request timeout for icmp_seq 671
Request timeout for icmp_seq 672
Request timeout for icmp_seq 673
Request timeout for icmp_seq 674
Request timeout for icmp_seq 675
Request timeout for icmp_seq 676
Request timeout for icmp_seq 677
Request timeout for icmp_seq 678
Request timeout for icmp_seq 679
Request timeout for icmp_seq 680
Request timeout for icmp_seq 681
Request timeout for icmp_seq 682
Request timeout for icmp_seq 683
Request timeout for icmp_seq 684
Request timeout for icmp_seq 685
Request timeout for icmp_seq 686
Request timeout for icmp_seq 687
Request timeout for icmp_seq 688
Request timeout for icmp_seq 689
Request timeout for icmp_seq 690
Request timeout for icmp_seq 691
Request timeout for icmp_seq 692
Request timeout for icmp_seq 693
Request timeout for icmp_seq 694
64 bytes from 192.168.1.1: icmp_seq=695 ttl=63 time=4.230 ms
64 bytes from 192.168.1.1: icmp_seq=696 ttl=63 time=6.853 ms
64 bytes from 192.168.1.1: icmp_seq=697 ttl=63 time=4.068 ms
64 bytes from 192.168.1.1: icmp_seq=698 ttl=63 time=2.843 ms
64 bytes from 192.168.1.1: icmp_seq=699 ttl=63 time=3.746 ms

Pingは695から1118まで再び正常に動作し、その後1パケットをドロップし、再びアップしました。

64 bytes from 192.168.1.1: icmp_seq=1117 ttl=63 time=4.442 ms
64 bytes from 192.168.1.1: icmp_seq=1118 ttl=63 time=4.044 ms
Request timeout for icmp_seq 1119
64 bytes from 192.168.1.1: icmp_seq=1120 ttl=63 time=10.043 ms
64 bytes from 192.168.1.1: icmp_seq=1121 ttl=63 time=3.660 ms
64 bytes from 192.168.1.1: icmp_seq=1122 ttl=63 time=4.898 ms

ありがとうございました

更新：Goldtool LAN Tester TCT-2690を使用してケーブルをテストし、すべてのケーブルがテストに合格したので、それは良いことだと思います。少なくともケーブルは物理的に問題ありません。でも、正方形に戻りました。

networkingwireless-networkingrouterwireless-routerwireless-access-point
1
rabbid

多くのパケット損失が発生しているため、ケーブルの問題である可能性があります。取り付けが不十分なケーブルは、単純なテストツールからのテストに合格しても、障害が発生する可能性があります。 ip -s link show dev eth0でイーサネットエラーを表示できます

ケーブルのペアピン配列の正しい規格に準拠していることを確認してください。つまり、両端で同じT568AまたはT568Bピン配列を使用する必要があります。これにより、外部干渉が各ツイストペアによって正しく処理されるようになります。すでにRJ45圧着工具をお持ちの場合、両端のコネクタの交換は非常に安価で簡単です。

他の明らかなケーブルの問題は、ケーブルの物理的な損傷です。鋭いねじれ/曲がり、熱による損傷、またはその他の明らかな問題がないことを確認します。湿気や伸び、RJ45コネクタピンの緩みや腐食など、一部の問題はそれほど明白ではありません。

それができない場合は、各ルーターを開いて、コンデンサーのいずれかに膨張があるかどうかを確認します。「膨潤したコンデンサー」を画像検索して、良いコンデンサーと悪いコンデンサーの違いが目立つ場合でも微妙であることを確認します。 Linksysがその製品ラインのいくつかに安価なコンデンサーを取り付けていた時期がありました。それはそれらがあまり長くは続かなかったことを意味しました。

ケーブルではないことをテストするには、Linux PCを一方の端に接続し、一方の端でcat /dev/zero | nc -l 8を実行し、もう一方の端でnc <otherIPAddress> 8 > /dev/nullを実行します。 iptraf-ngのようなCLIツールを開くと、100Base-TX接続で少なくとも70Mb/s、1000Base-Tで少なくとも500Mb/sの速度が表示されます。パケット損失のもう1つの良いテストは、ping -f <ipaddress>です。端末がドットでいっぱいになり始めた場合...それは悪いことです。

もちろん、デバイス自体に問題がある可能性もありますが、これも、まったく異なるケーブルでデバイスを相互に接続することでテストできます。

1
ThankYee