web-dev-qa-db-ja.com

一部のWiFiルーターが有線から無線へのマルチキャストパケットをブロックするのはなぜですか？

私は何十ものコンシューマグレードのWiFiルーターを使用してきましたが、改善の傾向はありますが、実際にはこれで大失敗しています。

問題の例：

  1. MDNSで検出できるデバイスは、ケーブルでルーターに接続されます。
  2. WiFi上のルーターに接続されている別のデバイスが、手順1でデバイスを検出しようとします。
  3. WiFi上のデバイスからのパケットは有線デバイスに到達しません。または、到達した場合、有線デバイスから送信されたパケットはワイヤレスデバイスに到達しません。

多くのルーターには、これを機能させる設定があります。

http://community.linksys.com/t5/Wireless-Routers/WRT120N-WLAN-Issues/td-p/40007 および http://forums.verizon.com/を参照してください。 t5/FiOS-Internet/Communication-between-wired-and-wireless-network-on-actiontec/td-p/461359 例。

これと互換性のない場所のリストはありますか？原因は何ですか？ルーターのバグですか？

routerwireless-networkingblockingbonjourmdns
26
hooby3dfx

通常、これはWi-Fiホームゲートウェイルーター（AP）のバグ、またはワイヤレスクライアントのチップセット/ドライバー/ソフトウェアのバグが原因です。

Wi-Fiでは、APからワイヤレスクライアントへのマルチキャストの送信（これは標準では「配布システムから」または「FromDS」として知られています）はトリッキーなので、失敗する可能性のある方法はたくさんあり、簡単に実行できますバグを紹介します。

  1. 無線メディアは信頼性が低いため、802.11ユニキャストはリンクレベルの確認応答（ACK）を必要とし、ACKがない場合は数回再送信される必要がありますが、FromDSマルチキャストはすべてのワイヤレスクライアントによってACKされる必要があるため、ACKされることはありませんAPの「かなりのACKストーム」になる可能性があります。したがって、代わりに、FromDSマルチキャストは低いデータレートで送信する必要があります。よりシンプルで、低速で、デコードが簡単で、信号対ノイズ比が低い変調方式を使用します。これは、APのすべてのクライアントが確実に受信できることを期待しています。一部のAPは、管理者がマルチキャストレートを設定できるようにし、一部の管理者は、一部のクライアントが確実に受信するには高すぎるためにそれらを設定し、それらのクライアントへのマルチキャスト配信を中断します。
  2. WPA（TKIP）またはWPA2（AES-CCMP）暗号化が使用されている場合、FromDSマルチキャストは、すべてのクライアントに知られている個別の暗号化キーで暗号化する必要があります（これは、グループキー）。
  3. クライアントがネットワークを離れるとき、または1時間ごとなど、適切な対策として、グループキーを変更して、離れたクライアントがマルチキャストを復号化するためのアクセス権を持たないようにする必要があります。この「グループキーローテーション」プロセスには、時々問題があります。クライアントが新しいグループキーの受信を確認しない場合、APはそのクライアントの認証を解除することになっていますが、バグが原因で認証に失敗した場合、クライアントは間違ったグループキーを持っている可能性があるため、 "気付かずにマルチキャストする。
  4. WPA2「混合モード」が有効な場合（つまり、WPAとWPA2が同時に有効な場合）、通常、FromDSマルチキャストはTKIP暗号でエンコードする必要があるため、すべてのクライアントはそれをデコードする方法を知っていることが保証されています。
  5. FromDSマルチキャストは、APによってキューに入れられ、マルチキャストに関心のあるすべてのクライアントが受信機の電源をオンにすることが期待できるときにのみ送信される必要があります。 「FromDSマルチキャストを安全に送信」する期間の間の時間は、「DTIM間隔」と呼ばれます。 APまたはクライアントがDTIM間隔の処理を台無しにすると、クライアントがマルチキャストを確実に受信できなくなる可能性があります。
  6. 一部のAPには、ワイヤレスクライアントが互いに直接通信できないようにする機能があり、ワイヤレスゲストが他のワイヤレスゲストをハッキングするのを防ぐことができます。これらの機能は通常、WLANデバイスから他のWLANデバイスへのマルチキャストをブロックし、LANからWLANへのマルチキャストをブロックする素朴な方法で実装することもできます。

奇妙なことに、「ToDS」マルチキャストはToDSユニキャストと同じように行われるため、破壊されることはほとんどありません。また、ワイヤレスクライアントがDHCPリースとARPを取得してデフォルトゲートウェイを見つけるときに必要なのは、ToDSマルチキャストではなく（FromDSマルチキャストではない）ため、ほとんどのクライアントは、FromDSの場合でも接続してWebを閲覧したり、電子メールをチェックしたりできます。マルチキャストが壊れています。そのため、多くの人は、mDNS（別名IETF ZeroConf、Apple Bonjour、Avahiなど）を実行しようとするまで、ネットワークにマルチキャストの問題があることに気づきません。

有線から無線へのマルチキャスト送信に関して、他に注意すべき点がいくつかあります。

  1. MDNSなどのほとんどのLANマルチキャストは、ルーター間でルーティングすることを意図していない特別なマルチキャストアドレス範囲を使用して行われます。 NATが有効になっているWi-Fi対応のホームゲートウェイはルーターとしてカウントされるため、mDNSはWANから[W] LANに接続することを意図したものではありません。ただし、SHOULD LANからWLANまで機能します。
  2. Wi-Fi上のマルチキャストは低いデータレートで送信する必要があるため、多くの通信時間がかかります。したがって、それらは「高価」であり、それらをあまり多く持ちたくありません。これは、有線イーサネットでの動作とは逆です。たとえば、マルチキャストは、「マルチキャストビデオストリームに同調する」など、各マシンに個別のユニキャストを送信するよりも「安価」です。このため、多くのWi-Fi APは「IGMPスヌーピング」を実行して、どのマシンがインターネットグループ管理プロトコル（IGMP）要求を送信しているかを監視し、特定のマルチキャストストリームにチューニングしたいという要望を表明します。 IGMPスヌーピングを実行するWi-Fi APは、ワイヤレスクライアントがIGMPを介してそのストリームにサブスクライブしようとしない限り、一部のクラスのマルチキャストをワイヤレスネットワークに自動的に転送しません。 IGMPスヌーピングを適切に行う方法を説明するドキュメントでは、特定のクラスの低帯域幅マルチキャスト（このカテゴリに適合するmDNS）は、誰もIGMPを介して明示的に要求していなくても、常に転送されることになっています。ただし、IGMPスヌーピングの実装が壊れていて、IGMP要求が見つかるまで、いかなる種類のマルチキャストも絶対に転送しない場合でも、私は驚かないでしょう。

tl; dr：バグ。バグの機会がたくさん。そして、時折設計が不十分な機能と構成エラー。最善の防御策は、マルチキャストが確実に機能することを重視する企業から高品質のAPを購入することです。 AppleはBonjour（mDNS）が大好き）であるため、AppleのAPはおそらくマルチキャストを確実に渡すことに最も一貫して優れており、AppleのWi-Fiクライアントデバイスはおそらくマルチキャストを確実に受信することに最も一貫して優れています。

41
Spiff

@Spiffは彼の回答にいくつか素晴らしい点を挙げました。ここでは繰り返しません。しかし、この問題を回避するための他のいくつかの回答と代替案があります。

短い答え？エンジニアが特定のデバイスを作成するのが面倒であるため、彼らは常に「最初からやらない」ほど常に「ブロック」しているとは思いません。優先度が高くないものもあれば、機能させる時間がないものもあります。

マーケティングがこれらのコンシューマーグレードのデバイスを販売するために使用しているすべての新しい「機能」と比較して、優先度リストでは高くありません。それはほとんどの非技術に詳しい人が手がかりを持たない機能なので、優先度リストを下に行くまで続きます所有者の大規模なプールがそれについて不満を言わない限り、リビジョンの更新から除外されます。

それをサポートするデバイスが必要な場合は、調査にデューデリジェンスを行うと、それをサポートするデバイスが得られます。または、 OpenWrt または トマト Polarcloudから、必要なものを確実に入手できます。

幸運を。 :)

1
isildur