Viewing multicast group membership?

Harti Brandt brandt at fokus.fraunhofer.de
Mon Nov 10 11:49:43 PST 2003


On Mon, 10 Nov 2003, Bruce M Simpson wrote:

BMS>On Mon, Nov 10, 2003 at 01:14:59PM -0500, Robert Watson wrote:
BMS>> I can't speak to existing code for this, but I can say I have a preference
BMS>> for having a sysctl version of the code available in the vague hopes that
BMS>> someday we can drop the setgid kmem bit from netstat...
BMS>
BMS>During operation, the kernel routing socket will report multicast group
BMS>joins/leaves using RTM_NEWMADDR/RTM_DELADDR messages. These contain an
BMS>ifma_msghdr structure, which encapsulates multicast addresses in an address
BMS>family independent manner. However, there is no mechanism to report currently
BMS>existing associations.
BMS>
BMS>Maybe the way to go is to extend getifaddrs(), or create a new API
BMS>a lot like it. Right now, it uses the NET_RT_IFLIST sysctl to retrieve
BMS>the interface list; the kernel appends RTM_NEWADDR messages to the
BMS>buffer contents returned by the sysctl to report each address family.
BMS>The function sysctl_iflist() in net/rtsock.c is responsible for this.
BMS>
BMS>However, not all getifaddrs() consumers are likely to be interested in
BMS>multicast associations, so this could end up adding bloat. The getifaddrs()
BMS>libc function and sysctl_iflist() kernel code do not touch
BMS>ifnet->if_multiaddrs at all.
BMS>
BMS>So my next question is: Do I create a new API function and sysctl, or
BMS>integrate into the existing code path?

I have a patch that creates a sysctl that returns the per-interface
multicast address lists that mimics the sysctl that returns the interface
address lists. If you can wait until tomorrow I'll send you the patch.
This is running for more than two years on all my machines.

harti

-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt at fokus.fraunhofer.de, harti at freebsd.org


More information about the freebsd-net mailing list