[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Multicast group memberships lost if eth0 brought down and up

On Mon, Oct 04, 2004 at 02:30:11PM +0200, Harald Hoyer wrote:
> Deron Meranda wrote:
> >On Sat, 02 Oct 2004 07:49:01 -0400, Ted Kaczmarek <tedkaz optonline net> 
> >wrote:
> >Thanks for the response, but my problem is for a normal application
> >running in user-space, not in the kernel. 
> >The problem occurs when the interface is brought down and then back
> >up.  The kernel looses track of all of the multicast memberships that
> >used to be associated with that interface.
> >Or, as a less desirable workaround, provide a way for an application
> >to be notified when an interface goes down or back up (yes, there are
> >kernel-level notifications, but nothing available at user-space. that
> >I know about).

In my opinion tearing down the infrastructure for a network
link should tear down and forget state.  i.e. the kernel
should forget about such things.   One of the 'reasons' for 
cycling an interface down/up is to clear out such state.

The point about notification is interesting.  I would have to do some
homework to convince myself what the correct actions should be.  Is
there some sort of timeout or heartbeat in the design that can be used
by the application to notice that the connection has been torn down.

One of the interesting about multicast is the action of routers.

I think IPV6 is involved.  There can be a handful of ways that that
plays out... are you tunneling.  If so does the tunnel collapse (as it
should) and routing can no longer find you.

One of the reasons that I believe that a lost link should tear down
state has to do with security.  If I was to pull your network link and
insert my own from a 'bad boy system' I do not believe that we would
want the 'bad boy system' to reconnect to all the network connections
that your system established.  switching a link or ifconfig linkN down/up 
should act the same in my mind.

	T o m  M i t c h e l l 
	Me, I would "Rather" Not.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]