# +TCP UDP multi-cast support

**URL:** <https://forums.freertos.org/t/tcp-udp-multi-cast-support/6138>\
**Category:** Kernel\
**Created:** [August 31, 2016, 6:47pm UTC](https://forums.freertos.org/t/tcp-udp-multi-cast-support/6138 "2016-08-31T18:47:18Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![system](https://d2v6vdsk2p900z.cloudfront.net/original/1X/7fc8fdb729c645aab5b20282bbe34e57cb407be6.jpeg) [@system](https://forums.freertos.org/u/system)\
**Post date:** [August 31, 2016, 6:47pm UTC](https://forums.freertos.org/t/tcp-udp-multi-cast-support/6138/1 "2016-08-31T18:47:18Z")

</div>

**[joehinkle](https://sourceforge.net/u/joehinkle/)** wrote on [Wednesday, August 31, 2016](https://sourceforge.net/p/freertos/discussion/382005/thread/658bdb52/#8f87):

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 FreeRTOS\_recvfrom() with the FREERTOS\_ZERO\_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

---

<div class="post-metadata">

**Author:** ![rtel](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/rtel/32/31_2.png) [@rtel](https://forums.freertos.org/u/rtel)\
**Post date:** [August 31, 2016, 7:53pm UTC](https://forums.freertos.org/t/tcp-udp-multi-cast-support/6138/2 "2016-08-31T19:53:21Z")

</div>

**[rtel](https://sourceforge.net/u/rtel/)** wrote on [Wednesday, August 31, 2016](https://sourceforge.net/p/freertos/discussion/382005/thread/658bdb52/#8f87/ec31):

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.

---

<div class="post-metadata">

**Author:** ![htibosch](https://d3iykfbgfh8zhg.cloudfront.net/user_avatar/forums.freertos.org/htibosch/32/62_2.png) [@htibosch](https://forums.freertos.org/u/htibosch)\
**Post date:** [September 1, 2016, 8:25am UTC](https://forums.freertos.org/t/tcp-udp-multi-cast-support/6138/3 "2016-09-01T08:25:45Z")

</div>

**[heinbali01](https://sourceforge.net/u/heinbali01/)** wrote on [Thursday, September 01, 2016](https://sourceforge.net/p/freertos/discussion/382005/thread/658bdb52/#5ed3):

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:

```auto
    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:

```auto
   int32_t FreeRTOS_recvfrom(
       Socket_t xSocket,
       void *pvBuffer,
       size_t xBufferLength,
       BaseType_t xFlags,
       struct freertos_sockaddr *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