+TCP IPv4 multicasts and IGMP

Hi all,
I found a topic here that said that Multicast and IGMP support is not planned, and I need it fairly quick, so I took it upon myself to add support for it to FreeRTOS+TCP. Please consider this a preliminary discussion.

I need implementation for sending/receiving UDP/IPv4 multicasts and IGMP snooping, pruning, and a querier. Currently, FreeRTOS+TCP only supports sending UDP datagrams to multicast IP addresses, so for the past week or so, I’ve been working on adding proper support for multicasts and IGMP.

My general question is: Are the maintainers and the community interested in bringing these features into FreeeRTOS+TCP “main”?

Below are some details on my vision of what needs changed or implemented to achieve this goal:

  • Add at least the following socket options for UDP sockets: SO_IP_ADD_MULTICAST, SO_IP_DROP_MULTICAST
  • Keep track (per socket) of which multicast the socket is subscribed for and be able to add/remove subscriptions
  • Add proper filtering for sockets that are subscribed for receiving a multicast group → Done
  • Add a network driver function for adding and removing multicast MACs to the EMAC hardware ( the failsafe approach here is to receive all multicasts if multicast support is enabled )
  • Support for multiple groups per socket as well as multiple interfaces ( aim is to make this code portable to “multi” branch )
  • IGMP <–> Socket interface so that IGMP knows what the local host is registered for.
  • IGMP v1/v2/v3 frame parsing
  • IGMP timers for sending “report” frames
  • optional IGMP querier
  • network driver hooks for multicast pruning ( only applicable when using a managed switch that is under the MCU control )

There is a lot more details and decisions behind every one of these bullet points, but let’s keep it simple for now.

I have a working first draft of the socket-related stuff and I haven’t yet started on the IGMP part. I will be able to share sample code in a few days as I’m still cleaning up and testing. I will also probably need a little help on some performance-related decisions as well as guidance on the feature-set what would be best for the general FreeRTOS+TCP user.

Is there general interest in this? Again, I’m already doing it because I need it, but do you think a PR along these lines will be met with any interest or is it totally out of the question?

1 Like

Maybe a big change like that can live on a branch or in the labs while it’s tested properly and the implementation polished and ironed out.

quick update:
The socket options are done, adding/dropping subscriptions to multiple groups works.
EMAC multicast filter functions work for my hardware ( same70 )

I’m starting to work on IGMP v1/v2/v3 which should be fairly straight-forward, but will surely take me a few days. I’ve started working on responding to multicast queries, but later, I’ll be implementing extra functionality related to IGMP snooping. Leavinf IGMP snooping for last because using it depends on using a managed switch instead of a straight-forward PHY chip.

Wow, that’s a whole lot. I can’t speak for all developers involved, but I think it would be a welcome extension of the stack. And preferably, we should add it to the /multi branch.

We are still working on both branches, main and multi, to increase the quality and safety of the code.
And so I hope that the core source files won’t need many changes. I propose to add a new module called FreeRTOS_IGMP or so, which will handle all multicast traffic and the IGMP memberships. Of course we will add hooks and callbacks in the main source, depending on some new macro like e.g. ipconfigUSE_IGMP and/or ipconfigUSE_MULTICAST.

Your observation was correct, there is some basic support for outgoing multicast traffic, the message eNetworkTxEvent can be sent to the IP-task. But received packets will mostly be dropped.

These 4 functions can be of help:

BaseType_t xIsIPv4Multicast( uint32_t ulIPAddress )
BaseType_t xIsIPv6Multicast( const IPv6_Address_t * pxIPAddress )
void vSetMultiCastIPv4MacAddress( uint32_t ulIPAddress,
								  MACAddress_t * pxMACAddress )
void vSetMultiCastIPv6MacAddress( IPv6_Address_t * pxAddress,
								  MACAddress_t * pxMACAddress )

I guess that you would need 2 call-backs, one for IGMP packets, and one tp forward received UDP/multicast packets?

I am working on a project that also needs Multicasting and would like to help with testing, which often leads to fixing code :slight_smile:

I also need more than one iface (Ethernet and USB)

Where can I get a copy/clone?

You need it “fairly quick” when do we need to have this finished?

Tom/W2VY

1 Like

Hi Thomas,
I got side-tracked from this for about a month, but I’m slowly getting back to this multicast stuff.
I have created a “first draft” type of a branch based on the main branch. You are welcome to take a look at it here but just keep in mind I might have to drop it an re-create it.
Lately, I’ve been trying to figure out how some cisco SG250 switches handle IGMP snooping, IGMP queriers and so on and I think I’m starting to figure out how all that multicast stuff tries together. The internet is full of basic multicast info, but I have a few issues with understanding the nitty-gritty details of a proper implementation. I just created an IGMP querier as well and I have the code to respond to IGMP queries, but not all of it is pushed to that branch.
Bare with me for a few days and I should be able to post more info and details here.

1 Like