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

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.

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, '', 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