Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem


+TCP UDP multi-cast support

Posted by joehinkle on August 31, 2016

I see little to nothing mentioned about multi-cast capability.

I am only interested in receiving multi-cast messages - not replying to them and not transmitting them.

In my ENET driver I set a multi-cast filter to help weed out unwanted messages. I know the range of multi-cast IP addresses I'm interested in ... so Can I do the following within the current stack or will some changes be required.

I currently filter messages in the driver and call eConsiderFrameForProcessing() within the driver to decide if I pass the message on to the stack or discard it early.

The task looking for these multi-cast messdages is receiving them via a call to FreeRTOSrecvfrom() with the FREERTOSZERO_COPY flag set. The socket used is UDP with NO IP address set - only a PORT.

If I detect one of my multi-cast IP messages, will eConsiderFrameForProcessing() say it's not wanted? If so, can I bypass that "false" detection?

Thanks for any reply.


+TCP UDP multi-cast support

Posted by rtel on August 31, 2016

There is little direct support for multi-cast over and above LLMNR/NETBIOS at the moment, but there was a longish thread recently about how multicast functionality can be achieved with the correct filtering configuration and a little magic in the driver - but it doesn't seem to be in the support forum so must have been in a email thread I was copied on. Hein will be able to provide a informed response.

+TCP UDP multi-cast support

Posted by heinbali01 on September 1, 2016

Indeed there is no explicit support for multi-cast (except for LLMNR and LinkLayer Auto-IP).

The reception of multi-cast packets is perfectly possible if you:

ā— define ipconfigETHERNET_DRIVER_FILTERS_PACKETS as 1 to stop the IP-task from filtering packets ā— program the EMAC peripheral to allow for multi-cast IP addresses, this often uses a hash table ā— create an ordinary UDP socket and bind it to the target port number

Suppose you want to serve these two end-points:

~~~~ port 5000 port 5000 ~~~~

The IP-task will forward all multi-cast packets to a UDP socket bound to port 5000. Just like normal UDP traffic you can receive the messages by calling:

~~~~ int32t FreeRTOSrecvfrom( Sockett xSocket, void *pvBuffer, sizet xBufferLength, BaseTypet xFlags, struct freertossockaddr *pxSourceAddress, socklen_t *pxSourceAddressLength ) ~~~~

When receiving a UDP packet, you get to know the source IP-address and source port number. What you do not know is the destination address (x.x.x.37/x.x.x.38 in this example)

But :

In an email you asked: > I saw that there are some advanced callback features in the stack. > Any of those do what Iā€™m looking for?

For your UDP application FREERTOS_SO_UDP_RECV_HANDLER might be useful.

You'll find an example in NTPDemo.c :

#if( ipconfigUSE_CALLBACKS != 0 )
    memset( &xHandler, '\0', sizeof ( xHandler ) );
    xHandler.pxOnUDPReceive = xOnUDPReceive;
    FreeRTOS_setsockopt( xUDPSocket, 0, FREERTOS_SO_UDP_RECV_HANDLER, ( void * ) &xHandler, sizeof( xHandler ) );

You also get to see the destination address in pxDest :

static BaseType_t xOnUDPReceive( Socket_t xSocket, void * pvData, size_t xLength,
    const struct freertos_sockaddr *pxFrom, const struct freertos_sockaddr *pxDest )
    /* When returning non-zero, the packet data will be released.
    When returning zero, the packet data can still be received in a
    call to FreeRTOS_recvfrom(). */
    return 1;

The driver will pass both addresses: pxFrom and pxDest.

We called the call-back mechanisms "advanced" because they must be handled with care. Be aware that the function is called from the IP-task, which has its own high priority and its own small stack. It is not wise to do a blocking call from within a call-back. Also the use of +TCP API's is very limited.

Conclusion: it is very well possible to receive multi-cast traffic. When using FREERTOS_SO_UDP_RECV_HANDLER it is possible to see both source and destination address of each incoming packet. Replying to multi-cast messages is only possible with normal UDP, i.e. from the local IP address

[ Back to the top ]    [ About FreeRTOS ]    [ Privacy ]    [ Sitemap ]    [ ]

Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS v10.2.1 is available for immediate download. MIT licensed, includes 64-bit RISC-V, NXP Cortex-M33 demo, Nuvoton Cortex-M23 demo & STM32H745 dual core (AMP) demo.

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Cadence Tensilica Cortes

Espressif ESP32

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers





STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS

Xilinx Microblaze and Zynq partner