This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] CC3120:多播实现和数据包丢失/拒绝

Guru**** 2551110 points
Other Parts Discussed in Thread: CC3120

请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/wi-fi-group/wifi/f/wi-fi-forum/623742/cc3120-multicast-implementation-and-packet-loss-rejection

器件型号:CC3120

大家好、我已经从应用支持部门那里获得了指导。

我有一个实施多播套接字的主机 MCU、在套接字不再接收发送到其所属多播地址的数据之前、该 MCU 工作正常。

我可以确认从源发送的数据包在线上、其他主机 MCU 确实接收并响应相同的数据包。

有趣的是、我可以直接强制转换到"故障"器件、并且可以从不再看到多播流量的同一套接字接收数据包。

发送到正确端口上的子网广播地址的数据包也会从同一套接字接收。

在套接字 API 交互时、似乎进入此状态而不返回任何错误、其中套接字被配置为非阻塞并被频繁检查、通常返回-11 (try 再次)、直到它返回接收到的数据包的数据长度。

因此、考虑到没有配置 RX 滤波器且主机 MCU 将 WLAN 电源管理策略配置为"始终开启"、我想了解网络处理器做出的默认数据包抑制决策。 编程人员指南中有一些关于在默认模式下过滤多播和 MAC 层广播的丢弃线、但没有明确描述 NWP 所指的状态或如何进入。

考虑到所描述的问题、您是否可以提供任何建议? 您是否还能就支持 NWP 多播实施的接入点的关键配置要求提出建议?

如果我们需要获得一些直接支持或私人 NWP 文档来调查此问题、我还可以检查我们与 TI 的 NDA 是否仍然有效且适用。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    约书亚、您好!

    您能否提供有关所发送的测试数据包和测试环境的更多信息?

    您是否使用 WiFi 监听器在无线中捕获这些数据包?

    您在多播测试数据包中发送的有效载荷大小是多少? 这些是否与单播测试相同? 是否测试了各种有效载荷大小?

    如果缓冲有效负载似乎有问题、请尝试将 SL_SetSockOpt 与 SL_SO_RX_NO_IP_BOUNDARY 结合使用。 请注意、此选项仅适用于 UDP 套接字。 如需更多信息、请参阅 http://www.ti.com/lit/swru455的第6.5.2.2节

    对于 RX 滤波器-默认情况下不启用它们。 如果您遇到默认启用的 RX 滤波器行为、请检查您的闪存以确保您没有将滤波器数据库刷写到器件中。 如果 RX 滤波器数据库刷写到器件中、则器件上电时会自动加载。

    关于 AP 的多播配置- CC3120支持 IPv4 IGMPv2和 IPv6 MLDV1协议加入和离开多播组。

    此致、
    Bryan Kahler
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Bryan、

    测试环境是一种分布式网络布局、包含许多器件(使用 CC3120)。 器件可能会遇到状态变化并将数据包发送到特定的多播地址:端口、其他"订阅"该事件的器件(应用层)将在接收消息时执行某些功能、在某些情况下会响应或确认(同样、应用层)。 发送的这些数据包的有效载荷为57字节长。

    我们注意到、当测试环境扩展到~100个器件、具有~3个接入点(相同 SSID)和我认为连接 AP 的交换机时、这种故障会更可靠地发生。 不过、在单个接入点上对2-3个器件进行的较小的隔离式测试中发现了这种故障、由于规模的原因、故障的增加可能只是因为发现这种故障的机会更多、而不是任何拥塞因素。

    我们目前仅使用 Wireshark 捕获数据包、但也有一些工具来检查 RF/WiFi。

    我已经执行了一个测试、其中网络中的其他 CC3120器件接收发送到多播地址的57字节数据包(并使用相同的结果重复、33字节数据包)、但未接收被测器件、 然后、我将同一数据包单播到接收多播失败的单元、并发现它成功(它接收并响应消息)。

    我将介绍这个套接字选项、但我不确定缓冲有效负载是否是所描述的问题、因为我根本看不到 sl_Recvfrom 的任何字节返回、正如我说过的、同一数据包的单播成功。

    默认情况下、我不会遇到 RX 滤波器的行为、我遇到主动状态变化、结果与 RX 滤波非常相似、 并参考应用报告 SWRA502中的第8.4节"使用器件内置系统滤波器减少主机唤醒"、以了解问题的症状。

    目前、我们的测试环境已配置为禁用 IGMP 侦听、是否有任何"必须"配置参数需要启用以符合 IGMP/广播的 NWP 实施?

    谢谢、
    Josh
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Josh、您好!

    尝试降低多播数据速率。 如果使用 IPv4、请将路由器设置为使用相同版本的 IGMP、最好是 IGMPv2。

    IGMP 侦听也可能有所帮助。

    此致、
    Bryan Kahler
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Bryan、

    感谢您的建议、我们已经采取了一些步骤来提高可靠性、例如将多播数据速率降低到1mbps。

    正如我说过的、这是基于状态的故障、可能不是性能问题、因为一旦发现此故障、在重新启动器件并重新配置多播套接字之前不会修复。

    我可以将该建议传递给设置网络的用户、但已经被告知 IGMP 侦听已故意禁用。

    如果 IGMP 版本不匹配或基于 NWP 实施的 IGMP 侦听被禁用、或者 NWP 可能具有的任何配置相关性、您是否有理由认为消息可能永久失败?

    再次感谢、
    Josh
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    Josh、您好!

    如果按标准操作、IGMP 应向后兼容。 但是、这会导致主机以兼容模式运行、并且可能需要主机运行多个 Querier Present 计时器。

    这只是一个在调试期间降低复杂性的建议。

    此致、
    Bryan Kahler
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Bryan、如果主机禁用了 IGMP 侦听、并且可能没有为此组播组运行任何 Querier Present Timers、您认为这可能会导致 NWP 出现任何问题、以及是否会拒绝数据包? 我可以与网络团队确认 IGMP 配置、然后返回给您。

    我们遇到的故障与启用 IGMP 侦听的主机超出节点的查询器存在计时器、然后停止向该节点转发流量的情况类似。 但我提到的配置禁用了 IGMP 侦听。

    再次感谢您、Josh。