Subject: Re: if_detach
To: None <itojun@iijlab.net>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: tech-net
Date: 02/01/2000 22:09:17
On Wed, 02 Feb 2000 14:45:06 +0900 
 itojun@iijlab.net wrote:

 > 	in6_purgeaddr() calls in6_savemkludge().  when the last interface
 > 	address is removed by in6_purgeaddr(), the list of joined multicast
 > 	group will be attached into in6_mk.  when if_detach() removes ifnet
 > 	from if_list, I think if_detach should notify IPv6 part and ask
 > 	removal of kludge entry (otherwise ifnet * will be kept there).

Well... here's what I have:

        if (oia->ia6_multiaddrs.lh_first != NULL) {
                /*
                 * XXX thorpej@netbsd.org -- if the interface is going
                 * XXX away, don't save the multicast entries, delete them!
                 */
                if (oia->ia_ifa.ifa_ifp->if_output == if_nulloutput) {
                        struct in6_multi *in6m;

                        while ((in6m =
                            LIST_FIRST(&oia->ia6_multiaddrs)) != NULL)
                                in6_delmulti(in6m);
                } else
                        in6_savemkludge(oia);
        }

...i.e. if the interface associated with the ifaddr is dead, delete
the multicast addresses, rather than do the savemkludge... shouldn't
that get rid of them?

 > 	i think the code does the thing right.  the missing piece is
 > 	removal of kludge entry when ifnet goes invisible by if_detach
 > 	(I think kludge entry should go away - am I correct?)

Right... Shouldn't my code do that? :-)

 > 	I think there needs to be more LIST_REMOVE(inm, inm_list) in
 > 	sys/netinet/in.c, specifically when interface address is removed.
 > 	(otherwise multicast group info will become orphan)
 > 	We can just copy kludge entry code from IPv6 part.

I guess I need to do the same while loop in in_purgeaddr() as I
have in in6_purgeaddr().

You know, it occurs to me that {in,in6}_ifscrub() should be
handling these things!  The comment reads:

	* Delete any existing route for an interface.

Shouldn't that include any routes to multicast destinations
associated with that interface?

BTW, I've also noticed that ARP entries for IPv4 aren't going
away (don't know why I didn't notice that before, sigh).  I
do a routing table walk, so I'm a little confused about what's
really going on here... clearly time for more printfs...

        -- Jason R. Thorpe <thorpej@nas.nasa.gov>