Spi*_*iff
47
这通常是由于 Wi-Fi 家庭网关路由器 (AP) 中的错误，或者有时是无线客户端芯片组/驱动程序/软件中的错误。
在 Wi-Fi 上，从 AP 向无线客户端发送多播（这在标准中称为“来自分发系统”或“FromDS”）很棘手，因此有很多方法可能会失败，而且很容易引入错误。
- 即使无线电介质不够可靠，以至于 802.11 单播需要具有链路级确认 (ACK) 并在没有 ACK 时重新传输多次，但 FromDS 多播永远不会被确认，因为它们需要被所有无线客户端确认的 AP，这可能是一场“ACK 风暴”。因此，FromDS 组播必须以低数据速率发送；使用更简单、更慢、易于解码甚至在低信噪比调制方案，有望被 AP 的所有客户端可靠地接收。一些 AP 允许管理员设置多播速率，而一些管理员在不知不觉中将其设置得太高，以至于他们的某些客户端无法可靠地接收，从而中断了向这些客户端的多播传送。
- 当使用 WPA (TKIP) 或 WPA2 (AES-CCMP) 加密时，必须使用所有客户端都知道的单独加密密钥（称为组密钥）对 FromDS 多播进行加密。
- 当客户端离开网络时，或者每隔一小时左右，只是为了更好的衡量，需要更改组密钥，以便离开的客户端不再有权解密多播。这种“组密钥轮换”过程有时会出现问题。如果客户端不确认收到新的组密钥，AP 应该取消对该客户端的身份验证，但如果由于错误而未能这样做，则客户端可能拥有错误的组密钥，从而“失聪” " 没有意识到它的多播。
- 当启用 WPA2“混合模式”时（即，当同时启用 WPA 和 WPA2 时），FromDS 多播通常必须使用 TKIP 密码进行编码，以便保证所有客户端都知道如何对其进行解码.
- FromDS 多播必须由 AP 排队，并且仅在所有关心多播的客户端都可以预期其接收器打开时才传输。“安全传输 FromDS 多播”周期之间的时间称为“DTIM 间隔”。如果 AP 或客户端搞砸了它们的 DTIM 间隔处理，可能会导致客户端无法可靠地接收多播。
- 某些 AP 具有防止无线客户端相互直接通话的功能，以防止您的无线访客入侵您的其他无线访客。这些功能通常会阻止从 WLAN 设备到其他 WLAN 设备的多播，并且很可能以一种简单的方式实现，甚至可以阻止从 LAN 到 WLAN 的多播。
疯狂的是，“ToDS”多播就像 ToDS 单播一样完成，因此它们很少中断。并且由于当无线客户端获得 DHCP 租用和 ARP 以找到其默认网关时，ToDS 多播（不是 FromDS 多播）是所有需要的，大多数客户端都能够连接并浏览网页、查看电子邮件等。多播被破坏。因此，很多人在尝试执行诸如 mDNS（又名 IETF ZeroConf、Apple Bonjour、Avahi 等）之类的操作之前，并未意识到他们的网络存在多播问题。
关于有线到无线多播传输，还需要注意以下几点：
- 大多数 LAN 多播，例如 mDNS，都是使用特殊的多播地址范围完成的，这些地址范围不打算跨路由器路由。由于启用了 NAT 的具有 Wi-Fi 功能的家庭网关算作路由器，因此 mDNS 并不意味着从 WAN 跨越到 [W] LAN。但它应该从 LAN 到 WLAN 工作。
- 由于 Wi-Fi 上的多播必须以低数据速率发送，因此它们占用了大量的通话时间。所以它们很“昂贵”，你不想拥有太多它们。这与有线以太网的工作方式相反，例如，在有线以太网上，多播比向每台机器“调整到多播视频流”发送单独的单播“便宜”。因此，许多 Wi-Fi AP 将执行“IGMP 侦听”以观察哪些机器正在发送 Internet 组管理协议 (IGMP) 请求，表达他们希望调入给定多播流的愿望。执行 IGMP 侦听的 Wi-Fi AP 不会自动将某些类别的多播转发到无线网络，除非它们看到无线客户端尝试通过 IGMP 订阅该流。描述如何正确执行 IGMP 侦听的文档明确指出，即使没有人通过 IGMP 明确要求，也应该始终转发某些类别的低带宽多播（mDNS 属于这一类别）。但是，如果存在损坏的 IGMP 侦听实现，在看到 IGMP 请求之前绝对不会转发任何类型的多播，我不会感到惊讶。
tl;博士：错误。很多错误的机会。偶尔会出现设计不佳的功能和配置错误。您最好的防御措施是从关心确保多播工作的公司购买高质量的 AP。由于 Apple 非常喜欢 Bonjour (mDNS)，因此 Apple 的 AP 可能在可靠地传递多播方面最为出色，而 Apple 的 Wi-Fi 客户端设备在可靠地接收多播方面可能最为出色。