Date: Tue, 03 Jul 2007 15:22:21 +0100 From: "Bruce M. Simpson" <bms@FreeBSD.org> To: Ian FREISLICH <ianf@clue.co.za> Cc: current@freebsd.org Subject: Re: Multicast problems [PATCH] Message-ID: <468A5B9D.6030401@FreeBSD.org> In-Reply-To: <E1I5iuL-0006kH-6s@clue.co.za> References: <E1I5iuL-0006kH-6s@clue.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
Ian FREISLICH wrote: > Bruce, sorry to require so much handholding. The quagga people > almost haven't heard of FreeBSD and I'm not very familiar with > multicast. I've already got it working with a private hack, but > I'm not sure that I've done it right. > > Quagga no longer uses the mreq hack to pass the ifindex due to the > presence of the imr_ifindex member to the struct ip_mreqn. > > Am I correct in my reading of the in_mcast.c that IP_ADD_MEMBERSHIP > will ignore a value in imr_ifindex and use the address in imr_address > And that it is no longer possible to add a multicast membership using > the ifindex? > Warning: long technical answer to explain horrible kludge, and why kludge was removed. imr_ifindex is never used for IP_ADD_MEMBERSHIP as it is not part of the original IPv4 any-source multicast API. It is part of the ip_mreqn structure defined in Linux, where it is used for the IP_MULTICAST_IF ioctl. FreeBSD previously supported a hack derived from RFC 1724 which allowed an interface index to be specified in the imr_interface field when using IP_ADD_MEMBERSHIP which is totally non standard and only allows 24 bits of a quantity which is 32 bits in modern APIs. It is however part of MCAST_JOIN_GROUP in the new SSM API, which accepts the ifindex in the field gsr_interface of the group_source_req structure. In the case of OSPF, 224.0.0.5 lies within 224.0.0.0/8. It therefore has link-local scope and SHOULD NOT be forwarded by an IGMP enabled router, so IGMP announcements don't matter here. It looks like in your situation the old API is insufficient to capture the semantics of what Quagga needs to do without the RFC 1724 hack, and simply passing ip_mreqn isn't enough as the receive filters won't change -- IP_MULTICAST_IF only changes the source interface for transmission, not the interface where the join has been made. The correct fix is for applications to use the new API if they need to explicitly join a multicast group on an interface index i.e. to support an unnumbered interface, because that was one of the motivations behind the new API in the first place. I see now that Linux also supports ip_mreqn in its IP_ADD_MEMBERSHIP path. I could potentially change the ASM API ioctl paths (IP_ADD_MEMBERSHIP, IP_DEL_MEMBERSHIP) to detect and support the ip_mreqn structure -- however -- I am loathe to do this as it introduces another bunch of nested conditionals, as the same code now has to support IP_ADD_SOURCE_MEMBERSHIP in FreeBSD, which has the same structure size. It is also a retrograde change. Regards, BMS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?468A5B9D.6030401>