这几天测试设备的Wi-Fi相关功能时，发现有两款路由器存在问题，其行为与Wi-Fi协议的规定不一致。

其中一款为TP-LINK的TL-WR740N路由器；

当设备连接到该路由器的AP，并加入地址为239.0.0.1的组播组时，电脑采用网络调试助手定时往该地址发送组播数据包；

当发送周期设置为100ms时，设备接收到组播包的丢包率几乎为0%；

而将发送周期设置为1000ms，设备基本上接收不到组播包，丢包率几乎为100%，使用tcp dump 在设备上抓包，也几乎没有发现接收到的组播包；如果此时再打开一个网络调试助手， 定时100ms往设备发送UDP数据包，则设备几乎不再丢包；

根据测试时保存的日志分析来看，

除了组播，当有其他wifi 数据频繁发到这个设备，设备反复处于唤醒睡眠状态， 此时，以1s为周期的组播包可以被正常接收；

如果只有1000ms组播，wifi模组进入了睡眠模式，在睡眠时接受组播包出问题。

对于组播数据，根据Wi-Fi协议中关于低功耗的定义，

在Wi-Fi中beacon的802.11 management数据中，有tag为TIM的数据，该数据根据DTIM周期的设置，会携带1个bit的multicast位，如果该位为1，表示AP缓存了组播或者广播包，连接到该AP的station如果加入了组播组，则需要立即醒来接收该组播包，因为组播或者广播数据没有应答判断，AP只负责广播到空中，并不能保证station都能收到。

此时，如果station仍然处于睡眠状态将会接收不到，导致丢包。

使用MAC 电脑对Wi-Fi无线空口数据抓包并分析，发现TL-WR740N的问题在于，

当组播周期为100ms时，其定时100ms发送的beacon中的multicast位有相当一部分并没有置1，

而当组播周其为1000ms时，其beacon中的multicast位都是清零状态，而此时，设备的Wi-Fi模块进入了睡眠状态，定时醒来的收到的beacon数据中又未指定有组播或者广播的数据(multicast=0)，所以又立即进入睡眠，从而不能正常接收到组播包。

国外信息化水平远不如我国，应该还有大量用户使用老旧的路由器，其中可能有一些路由器存在类似的DTIM的multicast位处理错误的问题。

最后，我们修改了Wi-Fi模块的驱动程序，取消了低功耗模式，而且Wi-Fi模组一直处于工作状态，代价就是增加了不少功耗。

另外，设计产品时应当慎用TCP/IP的组播以及广播。