Re: Multicast problems [PATCH]

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