v2.6 IGMPv3 implementation

Please Cc any replies directly to my address, since I am not subscribed. Thanks.

I'm taking a look at the IGMPv3 implementation that was integrated into the 2.6 kernel (2.6.7 specifically). In the past there have been patches floating around that implemented the IGMPv3 stack, and these provided some new IOCTLs:

/* Multicast source filter calls */
#define SIOCSIPMSFILTER 0x89a0 /* set mcast src filter (ipv4) */

#define SIOCGIPMSFILTER 0x89a1         /* get mcast src filter (ipv4) */
#define SIOCSMSFILTER  0x89a2          /* set mcast src filter (proto indep) */
#define SIOCGMSFILTER  0x89a3          /* get mcast src filter (proto indep) */

These do not appear in the Linus kernel, though. Does anyone know the status of these ioctls and the IGMPv3 implementation in general? I'm trying to get the proper bits stuffed into glibc to make IGMPv3/SSM usable, and I'm not sure what to do about these ioctls. Should 4 new ioctl numbers be reserved for these in case an implementation is integrated, or should I just leave them out of glibc headers entirely?

Thanks.

We didn't use ioctls, we used socket options. See:

include/linux/in.h

Specifically IP_MSFILTER and friends.

BTW, unlike you claim, the IGMPv3 stack implementation has been in the kernel for a long time, much before 2.6.7 It is even in the current 2.4.x sources as well.

I noticed these. Do you have a pointer to documentation on this API?

Another thing I noticed. Which is better, __u32 or struct in_addr and int? Both are used in include/linux/in.h for what appear to be the same objects:

struct ip_mreq
{
struct in_addr imr_multiaddr; /* IP multicast address of group */
struct in_addr imr_interface; /* local IP address of interface */
};

struct ip_mreqn
{
struct in_addr imr_multiaddr; /* IP multicast address of group */
struct in_addr imr_address; /* local IP address of interface */
int imr_ifindex; /* Interface index */
};

struct ip_mreq_source {
	__u32		imr_multiaddr;
	__u32		imr_interface;
	__u32		imr_sourceaddr;
};

struct ip_msfilter {
	__u32		imsf_multiaddr;
	__u32		imsf_interface;
	__u32		imsf_fmode;
	__u32		imsf_numsrc;
	__u32		imsf_slist[1];
};

Thank you for clarifying. I only wish the userspace was caught up.

In article <[email protected]> (at Mon, 12 Jul 2004 18:27:13 -0400), "Charles R. Anderson" <[email protected]> says:

Please refer standards (e.g. RFC3678).

Hideaki YOSHIFUJI @ USAGI Project <[email protected]>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

In article <[email protected]> (at Mon, 12 Jul 2004 16:30:56 -0400), "Charles R. Anderson" <[email protected]> says:

These ioctls are "historic" and deprecated API.
So, just kill them to avoid confusion.
We use socket options.

Thanks.

Reference:
D. Thaler, B. Fenner and B. Quinn, "Socket Interface Extensions for Multicast Source Filters," RFC3678, January 2004.

--yoshfuji

Thank you. I have now read RFC3678 carefully and I have more questions. The kernel still declares the structs used for these obsolete ioctls, but instead defines sockoptions for them:

#define IP_MSFILTER 41
...
#define MCAST_MSFILTER 48
...

struct ip_msfilter {
	__u32		imsf_multiaddr;
	__u32		imsf_interface;
	__u32		imsf_fmode;
	__u32		imsf_numsrc;
	__u32		imsf_slist[1];
};

#define IP_MSFILTER_SIZE(numsrc) \
	(sizeof(struct ip_msfilter) - sizeof(__u32) \
	+ (numsrc) * sizeof(__u32))
...
struct group_filter
{
	__u32				 gf_interface;	/* interface index */
	struct __kernel_sockaddr_storage gf_group;	/* multicast address */
	__u32				 gf_fmode;	/* filter mode */
	__u32				 gf_numsrc;	/* number of sources */
	struct __kernel_sockaddr_storage gf_slist[1];	/* interface index */
};

#define GROUP_FILTER_SIZE(numsrc) \
	(sizeof(struct group_filter) - sizeof(struct __kernel_sockaddr_storage) \
	+ (numsrc) * sizeof(struct __kernel_sockaddr_storage))

Is it intended that glibc use these sockoptions internally for its implementation of the approved Advanced API functions, which are then exported to user programs:

setipv4sourcefilter()
getipv4sourcefilter()
setsourcefilter()
getsourcefilter()

Does the following limitation from RFC3678 Appendix A (rationale for the ioctl interface) apply to the Linux kernel getsockopt(), or can getsockopt() be used to retrieve the source filter for a given group?

Retrieving the source filter for a given group cannot be done with getsockopt() on some existing platforms, since the group and interface must be passed down in order to retrieve the correct filter, and getsockopt only supports an output buffer. This can, however, be done with an ioctl(), and hence for symmetry, both gets and sets are done with an ioctl.

Thank you for putting up with all my questions.

In article <[email protected]> (at Mon, 12 Jul 2004 21:21:52 -0400), "Charles R. Anderson" <[email protected]> says:

:

Yes.

No, so we can do both (set/get) by sockopt.

--yoshfuji