How to get Raw ethernet frame in MQX 3.7

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

How to get Raw ethernet frame in MQX 3.7

跳至解决方案
1,227 次查看
suhas_badve
Contributor I

Hi , I am integrating PROFINET stack code in my MQX 3.7 based code. can anbody help me to understand how we get raw ethernet frame. I want to send that raw frame directly to application code by bypassing TCP/IP stack.

1 解答
1,006 次查看
fcw
Contributor IV

Suhas, I'm just guessing now: Take a look at EtherType - Wikipedia . I see the EtherType of Profinet = 0x8892.The packet receiver could be examining the EtherType field in the MAC header and rejecting any non-TCP/IP frames [e.g 0x0800=IPv4, 0x0806=ARP]. So maybe try tracing backward from "MACNET_process_rx_bds() " or tracing forward from the MAC interrupt handler to determine if that's the case.

在原帖中查看解决方案

3 回复数
1,006 次查看
fcw
Contributor IV

Can't answer in detail, but if there's no major differences between 3.7 and 4.2, the place to start looking is MACNET_process_rx_bds() in macnet_receive.c. Code in that function examines ethernet packets, determines if RTCS wants the packet [ ENET_find_receiver() ] and passes them into the stack if so. I'd guess you could graft your code somewhere in there.

1,006 次查看
suhas_badve
Contributor I

Hi Fred thanks for input. We are working on the same line , For other Ethernet frames "MACNET_process_rx_bds() " gest triggered and then ENET_find_receiver()  function gets called , but for PROFINET frame the Ethernet interrupt is not getting triggered and  "MACNET_process_rx_bds() "  function not getting called.  Is there any setting to be enabled so that The "MACNET_process_rx_bds() " function gets called (Ethernet interrupt gets triggered )for PROFINET multicast packets.

Regards,

0 项奖励
1,007 次查看
fcw
Contributor IV

Suhas, I'm just guessing now: Take a look at EtherType - Wikipedia . I see the EtherType of Profinet = 0x8892.The packet receiver could be examining the EtherType field in the MAC header and rejecting any non-TCP/IP frames [e.g 0x0800=IPv4, 0x0806=ARP]. So maybe try tracing backward from "MACNET_process_rx_bds() " or tracing forward from the MAC interrupt handler to determine if that's the case.