IGMP和Wake On Lan
我有一台Windows 10服务器，使用Wake On Lan已经运行了一段时间。Realtek适配器设置为启用唤醒魔术包并禁用唤醒模式匹配。同样，Windows设置为“仅在Magic Packet上唤醒”。这通常适用于我的家庭网络：我有几个WoL客户端，每个客户端都可以在需要时唤醒服务器，并且服务器在不再需要时立即进入睡眠状态。 最近我在家用路由器上启用了IGMP代理以支持IPTV应用。但是，现在，只要服务器休眠，它就会在几秒钟内再次唤醒，由网络适配器发出的唤醒信号触发。关闭IGMP代理，它会停止唤醒。 我相信它是某种触发唤醒的组播数据包。我使用Wireshark来嗅探导致唤醒的数据包，但我找不到罪魁祸首：唤醒时没有魔法数据包，但有很多组播数据包。 发生什么了？为什么适配器在看起来不是魔术的数据包上醒来？我该如何解决？ 更新： 我采取了一个数据包捕获（只有28个数据包），它跨越从睡眠到服务器唤醒的时间段，因此应该包含有问题的数据包。我注意到没有一个帧包含服务器的MAC地址（作为魔术数据包）但大多数是UDP - > RTTP - > ISO / IEC 13818-1 - > DVB-EIT数据包，其中包含大量的“ FF“填充（作为魔术包）。 还有1个ICMP v6数据包和2个STP帧。我不认为这些是这样做的，因为我认为我已经看过没有它们的唤醒捕获 - 但我可能是错的。 但请注意，数据包捕获是通过交换机进行的。因此，它会看到任何广播的魔术包（正如我故意发送的那样），但它不会捕获直接发送到服务器MAC的假设魔术包。另一方面，当我在服务器上捕获时（在它唤醒的条件下，当它醒来时 - 当然）我没有看到任何类似魔术包指向其MAC地址的东西。 网卡是与最新的驱动程序我的华硕P 8Z77-V LX主板上提供一个Realtek的8168 PCI千兆以太网适配器这里。 更新更精确的症状更新 因此，IGMP不是直接原因。我可以在不使用Multicast的情况下相当可靠地重现问题。如果我只是将一个特定的UDP数据包（有效载荷）作为UDP广播重复发送到适配器，我最终可以将其唤醒。它通常需要300或400次发送。数据包是从多播流的捕获中复制出来的，是典型的数据包。 这是我用来发送数据包的Python 3代码（以及显示为十六进制转储的数据包的字节）： import time from socket import * cs = socket(AF_INET, SOCK_DGRAM) hex_dump = …