Date: Tue, 21 Mar 1995 14:38:14 -0500 From: Thomas Pusateri <pusateri@NetEdge.COM> To: Garrett Wollman <wollman@halloran-eldar.lcs.mit.edu> Cc: captain@pubnix.net, freebsd-questions@FreeBSD.org, gated-alpha@gated.cornell.edu Subject: Re: Gated is crashing my system! Message-ID: <9503211938.AA04017@NetEdge.COM> In-Reply-To: Your message of "Tue, 21 Mar 1995 10:11:50 EST." <9503211511.AA29099@halloran-eldar.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <9503211511.AA29099@halloran-eldar.lcs.mit.edu> you write: ><<On Mon, 20 Mar 1995 16:55:54 EST5EDT, "Andrew Webster" <awebster@dataradio.c >om> said: > >> I'm having some problems with gated R3_5Alpha9 on a FreeBSD 2.0 system. >> The system has 5 dialin lines that either allow shell or slip access. >> After operating correctly for some time (1-2 hours), the system crashes >> after gated tries to remove a route from the kernel when one of the slip >> lines shuts down. The commands issued to shutdown the slip line are: >> ifconfig slx down >> ifconfig slx delete > >Try pulling over the -current version of netinet/ip_output.c. I >recently fixed some potential race conditions involving multicast >options which I think may be the cause of this problem. (And if this >doesn't fix it, I'd like to know that, too.) I have seen this problem many times over the past several years with Reno and later systems. The problem is this: 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. This never happened in 4.3 because when an address changes, the in_ifaddr just gets updated. But in 4.3 Reno and later, the in_ifaddr gets deleted by the SIOCDIFADDR and a new one is added with the SIOCAIFADDR. What it boils down to is that the 4.3 Reno and later change address operation is no longer atomic. The "ifconfig" command issues two seperate ioctl's (one to delete and one to add) when changing an address. The hack that Jeff Honig mentioned is one I had written that just saved the group information when a in_ifaddr was deleted and added them back when the new in_ifaddr was created. Its a hack because it always assumed that an Add would follow a Delete. Its tricky to decide if you are just deleting an in_ifaddr. I don't have it handy, but maybe Jeff can send it to anyone interested or I'll try and dig it up. 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. Thanks, Tom Pusateri
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503211938.AA04017>