v2.6 IGMPv3 implementation

v2.6 IGMPv3 implementation

[Charles R. Anderson]

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.

Re: v2.6 IGMPv3 implementation

[David S. Miller]

On Mon, 12 Jul 2004 16:30:56 -0400
"Charles R. Anderson" <cra@WPI.EDU> wrote:

> /* 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?

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.

Re: v2.6 IGMPv3 implementation

[Charles R. Anderson]

On Mon, Jul 12, 2004 at 02:04:09PM -0700, David S. Miller wrote:
> include/linux/in.h
> Specifically IP_MSFILTER and friends.

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];
};

> 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.

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

Re: v2.6 IGMPv3 implementation

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20040712222713.GK7822@angus.ind.WPI.EDU> (at Mon, 12 Jul 2004 18:27:13 -0400), "Charles R. Anderson" <cra@WPI.EDU> says:

> 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:

Please refer standards (e.g. RFC3678).

-- 
Hideaki YOSHIFUJI @ USAGI Project <yoshfuji@linux-ipv6.org>
GPG FP: 9022 65EB 1ECF 3AD1 0BDF  80D8 4807 F894 E062 0EEA

Re: v2.6 IGMPv3 implementation

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20040712203056.GI7822@angus.ind.WPI.EDU> (at Mon, 12 Jul 2004 16:30:56 -0400), "Charles R. Anderson" <cra@WPI.EDU> says:

> /* 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?

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

Re: v2.6 IGMPv3 implementation

[Charles R. Anderson]

On Tue, Jul 13, 2004 at 06:22:26AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> These ioctls are "historic" and deprecated API.
> So, just kill them to avoid confusion.
> We use socket options.

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.

Re: v2.6 IGMPv3 implementation

[YOSHIFUJI Hideaki / 吉藤英明]

In article <20040713012152.GL7822@angus.ind.WPI.EDU> (at Mon, 12 Jul 2004 21:21:52 -0400), "Charles R. Anderson" <cra@WPI.EDU> says:

> On Tue, Jul 13, 2004 at 06:22:26AM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote:
> > These ioctls are "historic" and deprecated API.
> > So, just kill them to avoid confusion.
> > We use socket options.
> 
> 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:
:
> 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()

Yes.

> Does the following limitation from RFC3678 Appendix A (rationale for
> the ioctl interface) apply to the Linux kernel getsockopt(), or can

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

--yoshfuji