Hi, If anyone is experiencing panics with IPv6 in the kernel, and multicast applications active, please test this patch. I think some folk here saw this with VLC. re_at_: If this patch is good (I'll try to test locally) then it should go into HEAD ASAP. Some poorly behaved IPv6 multicast applications don't specify an interface for the join, and this triggers a KASSERT I put in to catch such corner cases. Multicast doesn't work unless apps are aware of the links active in the system they're running on, and this is a glaring hole in the Boost.ASIO API, sadly. This was caught by a Boost regression run on ref8.freebsd.org. Thanks to simon_at_ for logging the panic from the cluster console servers. cheers, BMS Index: in6_mcast.c =================================================================== --- in6_mcast.c (revision 195752) +++ in6_mcast.c (working copy) _at__at_ -2166,8 +2166,23 _at__at_ * refactored, assuming the scope IDs are the way to go. */ ifindex = ntohs(gsa->sin6.sin6_addr.s6_addr16[1]); +#if 0 KASSERT(ifindex != 0, ("%s: bad zone ID", __func__)); ifp = ifnet_byindex(ifindex); +#else + /* + * Some badly behaved applications don't pass an ifindex + * or a scope ID, which is an API violation. + */ + if (ifindex == 0) { + CTR2(KTR_MLD, "%s: warning: no ifindex, looking up " + "ifp for group %s.", __func__, + ip6_sprintf(ip6tbuf, &gsa->sin6.sin6_addr)); + ifp = in6p_lookup_mcast_ifp(inp, &gsa->sin6); + } else { + ifp = ifnet_byindex(ifindex); + } +#endif if (ifp == NULL) return (EADDRNOTAVAIL); }Received on Sat Jul 18 2009 - 14:41:55 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:52 UTC