OS Xnetworking堆栈忽略IGMP成员身份查询
我们有一个远程站点，Mac不响应IGMP成员身份查询 ，但是Windows的确有响应。 因此，大约10分钟后，IGMP感知networking交换机切断到Mac的组播stream。
这里是Wireshark的屏幕截图，显示了这个问题：
第一个数据包是应用程序请求networking开始允许从239.255.20.1到IGMP的IGMP数据包。 然后，大约每过125秒，您就会看到，configuration为IGMP查询器（10.1.254.254）的networking交换机询问我们是否仍然对该stream感兴趣。 注意到显着的缺乏反应。
这里是在本地networking上发生的情况，作比较：
在这里，大约每隔95秒查询器（172.20.0.2）询问我们是否仍然需要这个stream，并且有问题的Mac（172.20.0.144）说：“是的，请继续发送它。
graphics用户界面上的问题Mac上closures防火墙，我已经在命令行validation了它：
$ / usr / libexec / ApplicationFirewall / socketfilterfw --getglobalstate 防火墙被禁用。 （状态= 0） $ / usr / libexec / ApplicationFirewall / socketfilterfw --getblockall 阻止所有禁用！ $ / usr / libexec / ApplicationFirewall / socketfilterfw --getstealthmode 隐藏模式被禁用 $ / usr / libexec / ApplicationFirewall / socketfilterfw --getappblocked /Applications/mumblemutter.app / ... 该应用程序不是防火墙的一部分
该应用程序并不重要，因为堆栈在join群组后处理IGMP查询。
问题Mac电脑正在运行10.11.5，但我不能相信这个问题可以通过升级到绝对最新来解决，因为这意味着基于BSD的操作系统正在修复其networking堆栈中的严重错误。低概率。
第一次抓包就会显示问题，您会注意到IGMPjoin报文是IGMPv2报文，但IGMP查询器的回应都是v3。
这可能看起来很好，因为Mac OS X已经支持IGMPv3很长一段时间了，但是如果你在Darwin开源内核中深入研究IGMP实现 ，在igmp_input_v3_query()find这个代码，
/* * Discard the v3 query if we're in Compatibility Mode. * The RFC is not obviously worded that hosts need to stay in * compatibility mode until the Old Version Querier Present * timer expires. */ if (igi->igi_version != IGMP_VERSION_3) { ...etc...
这意味着Mac OS X（或者macOS，如果你喜欢的话）服从IGMPv3规范，并且将任何已经将IGMPv2数据包视为“兼容模式”的networking接口，这意味着它既不会承认IGMPv3数据包，也不会说IGMPv3那个networking接口。 根据上面的代码，它将接口标记为igi_version = 2 ，所以我们将打这个testing，并且忽略v3群组成员查询，理论上说在这个networking上说v3是不安全的，以免v2设备不能了解发生了什么事情。
我看到三个可行的补救措施：
-
让远程站点的负责人重新configuration交换机，将IGMPv2查询发回给请求IGMPv2组join的客户端。
-
在完全支持IGMP的networking交换机中closuresIGMPv3支持，以便只发送IGMPv2成员资格查询。
-
监视networking上的IGMPv2数据包，查找其源，并修复，升级或删除它们。 如果networking不能说v3直通，用＃1或＃2去。
这不是应用程序代码更改可以解决的问题。 setsockopt()的IP_ADD_MEMBERSHIP选项不包含版本号，所以该应用程序无法要求IGMPv3。 这个决定取决于堆栈。
虽然有可能会影响到操作系统的设置，但只有当Mac OS X IGMP实现不同于我们在igmp.c链接的igmp.c看到的情况时igmp.c如此。
如果您在Windows上嗅探IGMP的networking，则可以看到，尽pipenetworking上存在v2，它仍会响应v3响应的IGMPv3成员身份查询。 因此违反了RFC; 而一些networkingpipe理员会说：“好吧，它工作，不是吗？”，正确的回应必须是因为你不能强迫OS X也忽略RFC，解决scheme仍然是修复networking。