FreeRTOS + TCP ARP only resolves when request is initiated from remote

[tony-josi-aws (Tony Josi)]

@DelicateMoomin

What happened is that eConsiderPacketForProcessing was not defined in the commit I was sitting in. So I simply removed that block of code for the time being (and promptly forgot about it).

With ipconfigETHERNET_DRIVER_FILTERS_PACKETS enabled and no call to eConsiderPacketForProcessing from the network interface, there is no packet filtering at all happening. You can take a look at what ipconfigETHERNET_DRIVER_FILTERS_PACKETS was doing in the legacy network interface for STM32.

@DelicateMoomin

I am however confused

I would expect with ipconfigETHERNET_DRIVER_FILTERS_FRAME_TYPES enabled that the ethernet driver is taking care of filtering MAC addresses. Why do we run eConsiderFrameForProcessing if supposedly the frame has been filtered by hardware already?

Here, ETHERNET_DRIVER in the name ipconfigETHERNET_DRIVER_FILTERS_FRAME_TYPES refers to the network interface RX task (the one that is running with the name EMAC_STM32), instead of the IP task of the FreeRTOS+TCP stack. The name is chosen such that when a network interface is implemented for hardware, it can use ipconfigETHERNET_DRIVER_FILTERS_FRAME_TYPES to call driver-specific APIs for that hardware to filter out packets that might be more faster/efficient. However, for the latest STM32 network interface, provided with the network stack, both APIs are the same; the only difference with the macro is the task from which it’s called.