John, I'm glad there are people, outside of finance and broadcast, who understand the teething pains of multicast.
I might be able to spare cycles to test patches, so if someone steps up to the plate in the meantime, I'm happy to look where I can. We now have a FreeBSD testbed at work, having started a FreeBSD-based project with no infrastructure. "Of course it runs ZFS." John Baldwin wrote: > On Monday, January 09, 2012 10:23:48 am Bruce Simpson wrote: >> You've also stumbled on the behaviour specific to how BSD has >> traditionally dealt with broadcast/multicast sockets. The pcbinfo >> structure can't really be disentangled from this. >> >> Of course, it doesn't help that we have historically required these >> sockets to be bound to INADDR_ANY. It might be useful to break reception >> out using a separate hash/tree, rather than walking all sockets as is >> currently done, but legacy usage needs to be supported. >> > The other fun part in this case is that if it is going to take a long time, a > driver should probably be enabling reception of all multicast (equivalent of > IFF_ALLMULTI) while it reprograms the table to avoid dropping packets for > already-joined groups. I'm not currently doing this as we are using a > different > hack, but I think that is something drivers should probably be doing. I couldn't agree more re IFF_ALLMULTI. One change which I would have liked to have made, during the IGMPv3/SSM project, was to re-do the join operation so we could do things like this a little more easily. Another would have been to add a limited wrapper around IFF_PROMISC (let's call that one IFF_SOFTMULTI), in situations where cards were known to have broken IFF_ALLMULTI. This would extend their useful lifetime into the IPv6 era, as well as making it possible to use them for ISO protocols, historic (CLNP) and useful (IS-IS), which like to have working link-layer multicast. The chances are that if you're doing any of these things, you are probably using non-broken hardware, or a vendor already lugging patches around for these things (in which case, please share). Or you are using pcap directly and feeling the suck of having to write everything userland at layer 2. I don't have much free time for development outside of work at the moment, otherwise I would be rattling off more diffs. As it is, I have Git to look forward to. Bruce _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
