通常、Wi-Fiホームゲートウェイルーター（AP）のバグ、またはワイヤレスクライアントのチップセット/ドライバー/ソフトウェアのバグが原因です。
Wi-Fiでは、APからワイヤレスクライアント（これは標準では "From the Distribution System"または "FromDS"として知られています）にマルチキャストを送信するのは難しいため、失敗する方法はたくさんあります。バグを導入します。
- 無線メディアは信頼性が低いため、802.11ユニキャストはリンクレベルの確認応答（ACK）を持ち、ACKがない場合は数回再送信する必要がありますが、FromDSマルチキャストはすべてのワイヤレスクライアントによってACKされる必要があるため、ACKされることはありませんAPの「ACKストーム」である可能性があります。そのため、代わりにFromDSマルチキャストを低データレートで送信する必要があります。APのすべてのクライアントが確実に受信できるように、よりシンプルで、低速で、低レベルでも簡単にデコードでき、信号対ノイズ比の変調を使用します。一部のAPでは、管理者がマルチキャストレートを設定できます。一部の管理者は、クライアントの一部が信頼性の高い受信を行えないように無意識に高く設定し、それらのクライアントへのマルチキャスト配信を中断します。
- WPA（TKIP）またはWPA2（AES-CCMP）暗号化が使用されている場合、FromDSマルチキャストは、すべてのクライアントに既知の別個の暗号化キー（グループキーと呼ばれます）で暗号化する必要があります。
- クライアントがネットワークを離れるとき、または1時間ごとに、適切な測定のために、グループキーを変更して、マルチキャストを解読するためのアクセス権がなくなったクライアントを変更する必要があります。この「グループキーローテーション」プロセスには、時々問題があります。クライアントが新しいグループキーの受信を確認しない場合、APはそのクライアントの認証を解除することになっていますが、バグが原因で認証に失敗すると、クライアントは間違ったグループキーを取得し、 「気付かずにマルチキャストする。
- WPA2の「混合モード」が有効になっている場合（つまり、WPAとWPA2の両方が同時に有効になっている場合）、通常、FromDSマルチキャストはTKIP暗号でエンコードする必要があります。 。
- FromDSマルチキャストは、APによってキューに入れられ、マルチキャストを気にするすべてのクライアントが受信機の電源をオンにできると予想されるときにのみ送信される必要があります。「FromDSマルチキャストを安全に送信する」期間の間の時間は、「DTIM間隔」と呼ばれます。APまたはクライアントがDTIM間隔処理を台無しにすると、マルチキャストを確実に受信できなくなる可能性があります。
- 一部のAPには、ワイヤレスクライアントが他のワイヤレスゲストをハッキングしないようにするために、ワイヤレスクライアントが互いに直接通信できないようにする機能があります。これらの機能は通常、WLANデバイスから他のWLANデバイスへのマルチキャストをブロックし、LANからWLANへのマルチキャストもブロックする単純な方法で実装できます。
クレイジーなことは、「ToDS」マルチキャストはToDSユニキャストと同じように実行されるため、めったに壊れないことです。また、ワイヤレスクライアントがDHCPリースとARPを取得してデフォルトゲートウェイを見つける場合、ToDSマルチキャスト（FromDSマルチキャストではない）がすべて必要なため、ほとんどのクライアントはFromDSでも接続してWebを閲覧したり、メールをチェックしたりできます。マルチキャストが壊れています。そのため、多くの人々は、mDNS（別名IETF ZeroConf、Apple Bonjour、Avahiなど）を実行しようとするまで、ネットワークにマルチキャストの問題があることに気づきません。
有線から無線へのマルチキャスト送信に関して、他に注意すべき点がいくつかあります。
- mDNSなどのほとんどのLANマルチキャストは、ルーター間でルーティングされることを意図していない特別なマルチキャストアドレス範囲を使用して行われます。NATを有効にしたWi-Fi対応のホームゲートウェイはルーターとしてカウントされるため、mDNSはWANから[W] LANを通過することを意図していません。ただし、LANからWLANまで機能する必要があります。
- 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クライアントデバイスはおそらくマルチキャストを確実に受信するのに最も一貫して優れています。