Deferring inp_freemoptions() to an asychronous task

[Bruce Simpson]

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