For TCP sockets I can find “ipconfigTCPRXBUFFER_LENGTH” for the receive buffer size. Is there a similar parameter for UDP sockets? Or is it only this one: ipconfigNUMNETWORKBUFFER_DESCRIPTORS ? regards, Ken

Interesting question! The number of UDP messages that you can receive without reading them, is indeed limited by ipconfigNUM_NETWORK_BUFFER_DESCRIPTORS. For TCP a circular “stream buffer” is created for each direction. TCP data must be buffered, and kept in a buffer until the transmission has been acknowledged by the peer. This TCP housekeeping of data is complicated. I tried to make clear how it works in 2 pictures ( attached to this post ). The implementation of UDP sockets is a lot simpler. It has a list ( List_t ) of Network Buffers that were received. Note that FreeRTOS_recvfrom() has a zero-copy possibility, so that you can peek directly into a Network Buffer. There is an important setting for UDP sockets, limiting the maximum number of received packets: ~~~

ifndef ipconfigUDPMAXRX_PACKETS

/* Make positive to define the maximum number of packets
 * which will be buffered for each UDP socket. Can be
 * overridden with the socket option FREERTOS_SO_UDP_MAX_RX_PACKETS
 */
#define ipconfigUDP_MAX_RX_PACKETS        0u

endif

~~~ Suppose that you get a UDP attack: thousands of packets are fired to your UDP port, the attack will not disturb the device because at most ipconfigUDP_MAX_RX_PACKETS network buffers will be stored.

Hi Hein, Thanks for the answer. I have an additional question. How are these 2 parameters related, ipconfigUDPMAXRXPACKETS and ipconfigNUMNETWORKBUFFERDESCRIPTORS? When I increase ipconfigUDPMAXRXPACKETS from (3) to (10), I get an Assertion fail: “Assertion failed in file ../src/FreeRTOS-Plus-TCP-multi/FreeRTOSIP.c, line 1610″. Line 1610 of FreeRTOSIP.c is this part of the code: ~~~ static void prvProcessEthernetPacket( NetworkBufferDescriptort * const pxNetworkBuffer ) { EthernetHeadert *pxEthernetHeader; volatile eFrameProcessingResultt eReturned; /* Volatile to prevent complier warnings when ipCONSIDERFRAMEFOR_PROCESSING just sets it to eProcessBuffer. */

configASSERT( pxNetworkBuffer );

~~~ regards, Ken

The Assert fail was caused by 2 globally declared network pointer buffers in xemacpsifdma.c: ~~~ static NetworkBufferDescriptort *ethMsg = NULL; static NetworkBufferDescriptort *ethLast = NULL; ~~~ Fixed by making them local.

Ken, thanks a lot for your big effort to find the cause of this problem. The driver x_emacpsif_dma.c worked fine as long as it handled a single NIC. You found that when it serves two EMAC’s, corruption may occur. So the problem was only present in the /multi version. My stupid: two tasks were storing temporary data in common variables. These simple changes were made to avoid mentioned problem: Around line 320: ~~~ -static NetworkBufferDescriptor_t *ethMsg = NULL;

-static NetworkBufferDescriptor_t *ethLast = NULL;

-static void passEthMessages( ) +static void passEthMessages( NetworkBufferDescriptor_t *ethMsg ) ~~~ Around line 346: ~~~ int emacpscheckrx( xemacpsifs *xemacpsif ) { NetworkBufferDescriptort *pxBuffer, *pxNewBuffer; int rx_bytes; volatile int msgCount = 0; int head = xemacpsif->rxHead; BaseType_t bHasDataPacket = pdFALSE; +NetworkBufferDescriptor_t *ethMsg = NULL; +NetworkBufferDescriptor_t *ethLast = NULL; – passEthMessages( ); + passEthMessages( ethMsg ); ~~~