为什么有些 WiFi 路由器会阻止从有线到无线的多播数据包？

Question 1

这通常是由于 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 多播），因此即使 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 侦听的文档明确指出，某些类别的低带宽多播（mDNS 属于此类别）应该始终被转发，即使没有人通过 IGMP 明确请求它们。然而，如果存在损坏的 IGMP 侦听实现，即在看到 IGMP 请求之前绝对不会转发任何类型的多播，我不会感到惊讶。

总结：漏洞。漏洞出现的机会很多。偶尔还会出现设计不良的功能和配置错误。最好的防御措施是购买那些关心确保多播正常工作的公司提供的高质量 AP。由于 Apple 非常喜欢 Bonjour (mDNS)，Apple 的 AP 可能是在可靠地传递多播方面表现最出色的，而 Apple 的 Wi-Fi 客户端设备可能是在可靠地接收多播方面表现最出色的。

Answer

这通常是由于 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 多播），因此即使 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 侦听的文档明确指出，某些类别的低带宽多播（mDNS 属于此类别）应该始终被转发，即使没有人通过 IGMP 明确请求它们。然而，如果存在损坏的 IGMP 侦听实现，即在看到 IGMP 请求之前绝对不会转发任何类型的多播，我不会感到惊讶。

总结：漏洞。漏洞出现的机会很多。偶尔还会出现设计不良的功能和配置错误。最好的防御措施是购买那些关心确保多播正常工作的公司提供的高质量 AP。由于 Apple 非常喜欢 Bonjour (mDNS)，Apple 的 AP 可能是在可靠地传递多播方面表现最出色的，而 Apple 的 Wi-Fi 客户端设备可能是在可靠地接收多播方面表现最出色的。

Question 2

@Spiff 在他的回答中提出了一些很棒的观点，我不会在这里重复。但是还有其他一些答案和替代方案可以解决这个问题。

简短回答？我不认为他们总是“阻碍”太多，而只是因为工程师懒惰而“从一开始就不做”。有些人不把它作为高优先级，有些人只是没有时间让它发挥作用。

与市场营销人员用来销售这些消费级设备的所有新“功能”相比，它在优先级列表中的排名并不高，而且大多数不懂技术的人对它一无所知，因此它在优先级列表中的排名会很低，除非大量用户对此抱怨，否则它不会被列入任何修订更新中。

如果你想要一个支持它的设备，请尽职尽责地进行研究，你会得到一个支持它的设备，或者你可以找到一个支持类似功能的新设备或二手设备开放Wrt或者番茄从 Polarcloud，您可以放心获得您所需要的一切。

祝你好运。：）

Answer