[quagga-dev 4326] Re: ripd fails to leave multicast group ondeletedinterface
michal.ruzicka at comstar.cz
Wed Aug 23 10:25:24 BST 2006
>> No, the explicit leave of a multicast group (on a deleted/not up
>> interface) will still be needed even after the patch is accepted.
> Hmm, oh dear. On ~IFF_UP seems reasonable, but I have a notional problem
> with having to drop memberships on a deleted interface. That seems like a
> pure kernel bug to me. I join with Greg and his comments on this :).
Since there are two distinct lists of multicast meberships in linux (please
below, where I describe how the linux kernel keeps track of multicast group
meberships) and only one of them (the per interface list) is deleted on
delete, the explicit drop membership is needed to drop the entry from the
other (the per socket) list.
Well as they say "it's not a bug it's a feature" but really literally in
case of linux
(please see a discussion on this in my recent reply to Greg).
>> I'm not sure what kind of commands you mean here. If you mean multicast
>> group joining/leaving through setsockopt, it does make sense to leave a
>> multicast group explicitly on an interface that does not exist any more
>> since the group membership is not only an attribute of the interface but
>> also of the socket through which the group was joined (at least on
>> linux). And since the socket does not go away with the interface deletion
>> it is reasonable to leave the group explicitly as the commads themselves
>> are performed "on the socket" rather than "on the interface".
> Sure, but how does the socket describe the membership? The thing,
> notionally, is deleted.
It keeps track of the meberships by interface indices and as the indices
are unique (in fact they might start to be reused but it's merely
a theoretical possibility, please see one of my previous replies to Greg
for more details on this ... sorry for so many references but I hope you've
already read that as it is all on the list) there is no problem with that.
> I presume the reasoning is to avoid having, on delete events, having to
> search through all open sockets? But the problem lies in some global
> multicast membership list, not the sockets, so it can't be that surely?
There is no such thing (as far as I can tell ... I'm not a linux kernel
as a global multicast membership list. Rather there are a per interfire list
and a per socket list (quite literally as described in RFC 3376 (IGMPv3)).
Surely the per interface list is deleted along when the interface is deleted
but the per socket list is left untouched.
> It really sounds like the Linux kernel ought to clean up entries on this
> list on interface delete as appropriate - why can it not do so? If we
> understood the compelling reason for that, we might see things
As was already siad here and also in my other posts: It does only part of
job on interface delete (deletes the per interface list) and is able to cope
with the rest (delete entries from the per socket lists) when it is needed -
either on an explicit request (and this is the reason why the request is
necessary) or on a socket close.
>> Though I was not able to find the ospf_if_set_multicast() function in the
>> ospfd code (maybe it was added after 0.98.5)
> Check CVS HEAD.
I'll dig into it.
> Please file a bug too, unless you want to work on the "factor out ospfd's
> membership handling for use by all daemons" patch? :)
What bug do you mean here?
And well, yes, I'm considering to work on the generic code. Would you please
suggest what features it should have (I've aslo asked Greg this question).
More information about the Quagga-dev