Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Mar 1995 15:33:32 -0500
From:      Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu>
To:        Thomas Pusateri <pusateri@netedge.com>
Cc:        freebsd-questions@FreeBSD.org, gated-alpha@gated.cornell.edu, Steve Deering <deering@parc.xerox.com>, John Wroclawski <jtw@lcs.mit.edu>, ajit@ee.udel.edu
Subject:   Re: Gated is crashing my system! 
Message-ID:  <9503212033.AA29740@halloran-eldar.lcs.mit.edu>
In-Reply-To: <9503211938.AA04017@NetEdge.COM>
References:  <9503211511.AA29099@halloran-eldar.lcs.mit.edu> <9503211938.AA04017@NetEdge.COM>

next in thread | previous in thread | raw e-mail | index | archive | help
<<On Tue, 21 Mar 1995 14:38:14 -0500, Thomas Pusateri <pusateri@NetEdge.COM> said:

> When a group is added to the interface, the group information hangs off
> the in_ifaddr and well as the socket in_pcb since it is added with a
> socket option. If the interface address changes while an application
> is running that has joined a group, the group membership information
> gets blown away when the in_ifaddr is deleted but the socket in_pcb information
> remains because the socket is still open. Later, when you leave the group,
> the socket information gets deleted but there is nothing now on the in_ifaddr
> and you panic.

It seems that there are three possibilities for a real solution to
this problem:

1) Gain a reference to the ifaddr structure.  This keeps the system
from blowing up, but it means that programs silently fail if that
interface address comes back, since there's no way to re-associate the
interface with the old in_multi chain (or is there?).

2) Iterate over all PCBs deleting in_multi references when an address
is about to go away.  This is a slightly more expensive way of causing
programs to fail silently as in (1).

[Both (1) and (2) would solve the problem of FreeBSD users who have
intermittent SLIP or PPP connections.]

3) Iterate over all PCBs marking in_multi structures as ``this address
has gone away''; then, when adding a new address for the same
interface, go back through and re-point them to the new ifaddr.

(1) seems the least painful, but is arguably the least correct.

> The real issue is how to make an address change atomic. You could
> add a change ioctl operation (SIOCCIFADDR) or maybe some of you have
> a better idea.

Unfortunately, this doesn't work in the common case which is a problem
for our users, since the address goes away, and may never come back
(at least not on the same interface).

-GAWollman

--
Garrett A. Wollman   | Shashish is simple, it's discreet, it's brief. ... 
wollman@lcs.mit.edu  | Shashish is the bonding of hearts in spite of distance.
Opinions not those of| It is a bond more powerful than absence.  We like people
MIT, LCS, ANA, or NSA| who like Shashish.  - Claude McKenzie + Florent Vollant



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503212033.AA29740>