On Sun, Sep 2, 2018 at 4:18 AM, Patrick Ruddy <pru...@vyatta.att-mail.com> wrote: > Hi Roopa > > inline > > thx > > -pr > > On Fri, 2018-08-31 at 09:29 -0700, Roopa Prabhu wrote: >> On Fri, Aug 31, 2018 at 4:20 AM, Patrick Ruddy >> <pru...@vyatta.att-mail.com> wrote: >> > Some userspace applications need to know about IGMP joins from the kernel >> > for 2 reasons >> > 1. To allow the programming of multicast MAC filters in hardware >> > 2. To form a multicast FORUS list for non link-local multicast >> > groups to be sent to the kernel and from there to the interested >> > party. >> > (1) can be fulfilled but simply sending the hardware multicast MAC >> > address to be programmed but (2) requires the L3 address to be sent >> > since this cannot be constructed from the MAC address whereas the >> > reverse translation is a standard library function. >> > >> > This commit provides addition and deletion of multicast addresses >> > using the RTM_NEWADDR and RTM_DELADDR messages. It also provides >> > the RTM_GETADDR extension to allow multicast join state to be read >> > from the kernel. >> > >> > Signed-off-by: Patrick Ruddy <pru...@vyatta.att-mail.com> >> > --- >> > v2: fix kbuild warnings. >> >> I am still going through the series, but AFAICT, user-space caches listening >> to >> RTNLGRP_IPV4_IFADDR will now also get multicast addresses by default ? >> > > Yes that's the crux of this change. It's unfortunate that I could not > use IFA_MULTICAST to distinguish the SAFI. I suppose the other option > would be to create a set of new NEW/DEL/GETMULTICAST messages but the > partial code for RTM_GETMULTICAST in ipv6/mcast.c complicates that > slightly. Happy to look at it if you think that would be be better. >
yeah, true. Thinking about this some more, you are adding an interface for multicast entries learnt via igmp. There is already a netlink channel for layer2 mc addresses via igmp. I can't see why that cannot be used. It is RTM_*MDB msgs. It is currently only available for the bridge. But, I have a requirement for it to be available via a vxlan dev...so, I am looking at making it available on other devices. Can you check if RTM_*MDB msgs can be made to work for your case ?. The reason I think it should be possible is because this is similar to bridge fdb entries. The bridge fdb api (RTM_NEWNEIGH with AF_BRIDGE) is overloaded to notify and dump netdev unicast addresses. similarly I think the mdb api can be overloaded to notify and dump netdev multicast addresses (statically added or learnt via igmp)
