Microchip
直播中

李路明

7年用户 203经验值
私信 关注
[问答]

无法接收多播过滤器集pic32mz/mrf24wg0ma

大家好,我把一些旧的多播接收代码从MAL/MLA移植到ValueV1.08上运行。它目前无法接收数据包,并且已经调试到堆栈中,我怀疑它对过滤可能不满意,因为我看不到堆栈中出现的任何组播数据包。如果有人可以查看我正在使用的代码,我会很感激…我使用PIC32 MZ启动器套件和MRF24WG0MA模块。这些数据包通过iPad通过Wi-Fi路由器(B/G)传送给PIC。该网络在基础设施模式中配置,并且安全性是WPA2-PSK。我在PC上使用WiReSARK监控Wi-Fi,并附加了一个数据包捕获到这个消息。该项目基于Micro.sample web_server_nvm_mpfs,并在所有其他方面正常工作,例如通过wi-fi和以太网接口提供网页服务。这只是多播方面的问题。iPad正在通过Wi-Fi向多播地址239.251.0.1和端口5568发送分组。这些分组的以太网目的地址是01:00:5E:7F:00:01。作为实验,我试图使用DRV_WIFI_MULtiCAST_ENABLE_ALL作为过滤。以下是代码:DRV_WIFI_MULTICAST_MULTICAST_MULTICAST_MULTICAST_FIFI_MULTICAST_FIFIFIFI_MULTICAST_FIFIFIST_FIFIFIFIFIFI_CONFIFIST没有改变行为。以下是代码:DRV_WIFI_WIFI_WIFI_MULTICAST_MULTICAST_CONFIFIFIFIFIFI_CONFIFIFIFIFIFIFIFIFIFIFI_FIFIFIFIFIFI_FIFIFIFIFIFIFIFIFIFIFI_1;Config.macBitMask=Config.macBitMask=0x38;memcpy(&.mac.MacBitMask=0x38;memcpy(&(配置macB)6字节,mac掩码,6);DRV_WIFI_MultiCastFilterFilterEnEnEnable();DRV_WIFI_多播过滤器集(&配置);DRV_WIFI_多播过滤器集(&;DRV_WIFI_多播过滤器集(&配置图);DRV_WIFI_多播过滤器集(&;配置图);DRV_WIFIFIFI_多播过滤器集(&;配置图);DRV_WIFIFIFI_多播过滤器集(&;配置图);DRV_DRFI_多播过滤器集(&;配置图;配置图);DRV_DRV_DRFI;配置图;配置图;配置图;配置图);char地址地址[]]]]]];char地址IP地址;如果插座!= INVALID_SOCKET){如果(TCPIP_UDP_Bind(Socket,IP_ADDRESS_TYPE_IPV4,0,0)){}}}稍后我将使用TCPIP_UDP_GetIsReady()检查接收的数据,该数据总是返回0

以上来自于百度翻译


      以下为原文

    Hello all,

I'm porting some old multicast receive code from MAL/MLA to run on HARMony v1.08. It's presently unable to receive packets and having debugged into the stack I suspect it may be unhappy with the filtering as I can't see any of the multicast packets appearing in the stack. I'd be grateful if someone could review the code I'm using below...

I'm using a PIC32MZ Starter Kit and MRF24WG0MA module. The packets are being transmitted by an iPad to the PIC via a Wi-Fi router (b/g). The network is configured in Infrastructure mode and the security is WPA2-PSK. I'm monitoring Wi-Fi using Wireshark on a PC and have attached a packet capture to this message. The project is based on the Microchip sample web_server_nvm_mpfs and is working correctly in all other respects - such as serving up webpages via both the wi-fi and ethernet interfaces. It's only the multicast side which I am having issues with.

The iPad is sending packets via Wi-Fi to the multi-cast address 239.251.0.1 and port 5568.
The Ethernet destination address of these packets is 01:00:5E:7F:00:01.

As an experiment I've tried using DRV_WIFI_MULTICAST_ENABLE_ALL as the filtering option but it didn't change the behaviour.

Here is the code:

DRV_WIFI_MULTICAST_CONFIG Config;
uint8_t macMask[] = { 0x01, 0x00, 0x5E, 0x7F, 0x00, 0x01 };
Config.action = DRV_WIFI_MULTICAST_USE_FILTERS;
Config.filterId = DRV_WIFI_MULTICAST_FILTER_1;
Config.macBitMask = 0x38;
memcpy(&(Config.macBytes), macMask, 6);
DRV_WIFI_MultiCastFilterEnable();
DRV_WIFI_MulticastFilterSet(&Config);

char Address[] = "239.255.0.1";
IP_MULTI_ADDRESS IPAddress;
TCPIP_Helper_StringToIPAddress(Address, &IPAddress.v4Add);
Socket = TCPIP_UDP_ClientOpen(IP_ADDRESS_TYPE_IPV4, 5568, &IPAddress);
if (Socket != INVALID_SOCKET)
{
if (TCPIP_UDP_Bind(Socket, IP_ADDRESS_TYPE_IPV4, 0, 0))
{
}
}
....later on I am checking for received data using TCPIP_UDP_GetIsReady() which is always returning 0
   Attachment(s)

Multicast Packet.zip (0.34 KB) - downloaded 28 times

回帖(3)

陈臻江

2019-7-17 14:22:49
在进一步的调查中,似乎有一些问题之间的组播过滤和谐和MRF24WG0MA。该设备可以接受寻址到01:00:5E:00:00:FB(组播DNS)的分组,但是即使过滤配置正确,也不能接受到01:00:5E:7F:00:01(sACN)的分组。de in'DRV_WIFI_DataRxTask()',将Wi-Fi接收并传递到TCP/IP堆栈的任何传入数据包的目的地以太网地址转储到控制台。在函数“TCPIpH-MDSNSUBPATION())中,Orthon配置MRF只接受发送到MNS的数据包。在这个配置中,它工作得很好,我看到调试控制台上带有匹配地址的数据包到达,Wireshark中捕获了相同的数据包。如果我改变多播过滤器接受来自iPad的SACN数据包,MRF就不会将它们转发到TCP/IP协议栈。如果我将过滤器改回接受MDNS,并且修改iPad代码以将其数据作为MDNS而不是sACN发送,MRF会将它们转发到TCP/IP堆栈。这提示我,不管我设置了什么过滤,sACN流量总是被过滤掉。下一个测试是关闭过滤,看看我是否可以接收MDNS和sACN。为此,我将“MRF24W_MACMulticastFilterSet()”中的筛选器类型更改为“DRV_WIFI_MULTICAST_ENABLE_ALL”,文档状态将“将所有多播消息转发给主机MCU”。在完成此操作之后,我发现仍然只能接收MDNS数据包。在此移植练习之前,我已经能够成功地使用MRF24WB0MA和MAL/MLA栈从iPad接收数据包。不幸的是,Harmony不支持“B”模块,因此无法将其切换并重新运行测试,并识别出其中哪一个有问题。我的G模块中的固件是0x310C,我将用Microchip打开一张罚单。

以上来自于百度翻译


      以下为原文

    Upon further investigation there seem to be some issues with multicast filtering between Harmony and the MRF24WG0MA. The device is OK with accepting packets addressed to 01:00:5E:00:00:FB (Multicast DNS) but not to 01:00:5E:7F:00:01 (sACN) even when the filtering is configured correctly.
 
To check this I enabled the 'Use Link Local Zero Config' and 'Use Multicast DNS Zero Config (Bonjour)' options and added some code in 'DRV_WIFI_DataRxTask()' to dump to the console the destination ethernet address of any incoming packets being received by the Wi-Fi and passed up to the TCP/IP stack. In the function 'TCPIP_MDNS_Process()', Harmony configures the MRF to only accept packets addressed to MDNS. In this configuration it works fine and I see the packets arriving with the matching address on the debug console and those same packets being captured in Wireshark.
 
This is where it gets interesting. If I change the multicast filter to accept sACN packets from the iPad the MRF doesn't forward them to the TCP/IP stack. If I change the filter back to accept MDNS and I modify the iPad code to send it's data as MDNS instead of sACN the MRF forwards them to the TCP/IP stack. This suggests to me that regardless of the filtering I set, the sACN traffic is always filtered out.
 
The next test was to turn off the filtering and see if I could receive both the MDNS and sACN. To do this I changed the filter type in 'MRF24W_MACMulticastFilterSet()' to 'DRV_WIFI_MULTICAST_ENABLE_ALL' which the doc states will 'forward all multicast messages to the host MCU'. After doing this I found I could still only receive the MDNS packets.
 
Prior to this porting exercise I had been able to receive the packets from the iPad successfully using an MRF24WB0MA and the MAL/MLA stack. Unfortunately the 'B' module is not supported by Harmony so it's not possible to switch it out and re-run the tests and identify which of the two has the problem. The firmware in my 'G' module is 0x310C.
 
I will open a ticket with Microchip. 
 
 
 
 
举报

张玉

2019-7-17 14:40:07
你移植了你的E1.31/SACN代码?很好。你如何使IGMP工作和谐?

以上来自于百度翻译


      以下为原文

    Your porting your E1.31 / sACN code?  Nice.  How are you making IGMP work with Harmony?
 
举报

陈臻江

2019-7-17 14:56:14
我已经确认,MRF24WG0MA的行为不同于MRF24WB0MA当馈送相同的流量和过滤器设置。在“G”模块的情况下,即使在过滤器设置启用了该地址时,它也不会向PIC32转发01:0:5E:7F:0:01(SACN)分组。如果启用了该过滤器,“B”模块将转发相同的数据包。对于这一轮测试,由于不支持MRF24WB0MA的和声,我返回到使用MAL和PIC32 MX,并从MAL 2013-0615建立TCP/IP’demo应用程序。我添加了跟踪代码,这样我就可以看到Wi-Fi模块转发到PIC的哪些数据包。我测试了三个不同的模块,首先用过滤器集接收01:00:5E:0:00:FB(多播DNS),然后再次将过滤器设置为接收01:00:5E:7F:0:01(SACN):1)MRF24WB0MA固件RMV固件Rev 0x310C3)MRF24WG0MA固件Rev,我不记得,但早于0x310C和它。不支持由OrthIi支持所有3个模块将转发01:00:5E:0:00:FB(多播DNS)流量到PIC,但只有MMFR24WB0MA将转发01:00:5E:7F:00∶01(SACN)。所以我的结论是和谐不是问题;它是MRF24WG0MA。由于协议规范未公布,不可能知道这种行为是否是缺陷或故意的。我会问Microchip。

以上来自于百度翻译


      以下为原文

    I've confirmed that the MRF24WG0MA behaves differently to the MRF24WB0MA when fed the same traffic and filter settings. In the case of the 'G' module it will not forward 01:00:5E:7F:00:01 (sACN) packets to the PIC32 even when the filter setting has that address enabled. The 'B' module will forward the same packets if the filter is enabled.
 
For this round of testing due to Harmony not supporting the MRF24WB0MA, I went back to using MAL and a PIC32MX and built the TCP/IP 'Demo App' from MAL 2013-06-15. I added trace code so I could see which packets the Wi-Fi module forwarded onto the PIC. I tested three different modules, first with the filter set to receive 01:00:5E:00:00:FB (Multicast DNS) and then again with the filter set to receive 01:00:5E:7F:00:01 (sACN):
 
1) MRF24WB0MA firmware
2) MRF24WG0MA firmware rev 0x310C
3) MRF24WG0MA firmware rev I don't recall but predates 0x310C and it isn't supported by Harmony
 
I confirmed all 3 modules would forward 01:00:5E:00:00:FB (Multicast DNS) traffic to the PIC, but only the MRF24WB0MA would forward the 01:00:5E:7F:00:01 (sACN).
 
So my conclusion is that Harmony is not the issue; it is the MRF24WG0MA. Since the protocol specifications are not published it is impossible to know if this behaviour is a defect or intentional. I will ask Microchip.
举报

更多回帖

发帖
×
20
完善资料,
赚取积分