From owner-freebsd-questions Tue Mar 21 12:34:15 1995 Return-Path: questions-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA02531 for questions-outgoing; Tue, 21 Mar 1995 12:34:15 -0800 Received: from halloran-eldar.lcs.mit.edu (halloran-eldar.lcs.mit.edu [18.26.0.159]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA02525 for ; Tue, 21 Mar 1995 12:34:10 -0800 Received: by halloran-eldar.lcs.mit.edu; id AA29740; Tue, 21 Mar 1995 15:33:32 -0500 Date: Tue, 21 Mar 1995 15:33:32 -0500 From: Garrett Wollman Message-Id: <9503212033.AA29740@halloran-eldar.lcs.mit.edu> To: Thomas Pusateri Cc: freebsd-questions@FreeBSD.org, gated-alpha@gated.cornell.edu, Steve Deering , John Wroclawski , ajit@ee.udel.edu Subject: Re: Gated is crashing my system! In-Reply-To: <9503211938.AA04017@NetEdge.COM> References: <9503211511.AA29099@halloran-eldar.lcs.mit.edu> <9503211938.AA04017@NetEdge.COM> Sender: questions-owner@FreeBSD.org Precedence: bulk < 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