Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

+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.

Joe


+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:

~~~~ 225.0.0.37 port 5000 225.0.0.38 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 ) );
}
#endif

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 ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

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

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

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

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists