NetBSD Problem Report #35196

From perry@piermont.com  Thu Dec  7 02:21:32 2006
Return-Path: <perry@piermont.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id D381D63BA5D
	for <gnats-bugs@gnats.NetBSD.org>; Thu,  7 Dec 2006 02:21:31 +0000 (UTC)
Message-Id: <20061207012102.1041D78B607@hackworth.piermont.com>
Date: Wed,  6 Dec 2006 20:21:02 -0500 (EST)
From: perry@piermont.com
Reply-To: perry@piermont.com
To: gnats-bugs@NetBSD.org
Subject: sockets should die if addresses vanish
X-Send-Pr-Version: 3.95

>Number:         35196
>Category:       kern
>Synopsis:       sockets should die if addresses vanish
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 07 02:25:00 +0000 2006
>Last-Modified:  Fri Dec 08 18:25:01 +0000 2006
>Originator:     Perry E. Metzger
>Release:        NetBSD 4.99.3
>Organization:
Perry E. Metzger		perry@piermont.com
--
"Ask not what your country can force other people to do for you..."
>Environment:


System: NetBSD hackworth 4.99.3 NetBSD 4.99.3 (HACKWORTH) #0: Fri Oct 27 14:05:48 EDT 2006 perry@hackworth:/usr/obj/sys/arch/i386/compile/HACKWORTH i386
Architecture: i386
Machine: i386
>Description:

Lets say that you have an interface that has fairly dynamic addresses
-- a ppp dialup connection or an 802.11 adapter on a machine that
moves around a lot.

The addresses bound to said interface will often go away, to be
replaced by new ones (or none at all). However, even after they go
away, TCP connections will continue to live for quite some time,
eventually timing out, going into time wait, etc.

This is quite clearly silly. If you no longer have the address from
which the packets for the socket putatively originate, you will
*never* get any reply packets. Your counterparty is *never* going to
be able to reply to you. The careful timeout machinery is useless.

Thus, my claim is that if you delete an address from an interface, you
should immediately tear down all connections associated with it and
revoke all the file descriptors for sockets bound to the address that
has gone away for good.

By the way, for certain services, such as some EVDO providers, sending
out packets from an address you do not control causes the connections
to drop. The reason I noticed this problem in the first place is
because if I lose my EVDO connection and restart it (which implies a
new address), dying sockets that I cannot get rid of send out packets
that cause the connection to die again. This can be worked around with
packet filters, but in general, we should not be keeping around TCP
state for connections that we know are permanently dead by virtue of
the fact that the origination address is no longer one we are assigned.

>How-To-Repeat:

Delete an address that has a bunch of connections bound to it. Note
that the connections don't go away -- netstat still shows them.

>Fix:


>Audit-Trail:
From: SODA Noriyuki <soda@sra.co.jp>
To: perry@piermont.com
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Thu, 7 Dec 2006 11:34:35 +0900

 >>>>> On Thu,  7 Dec 2006 02:25:01 +0000 (UTC), perry@piermont.com said:

 > The addresses bound to said interface will often go away, to be
 > replaced by new ones (or none at all). However, even after they go
 > away, TCP connections will continue to live for quite some time,
 > eventually timing out, going into time wait, etc.

 > This is quite clearly silly.

 It is not so silly, acutally.
 Think about unstable PPP link which nearly always assigns same IP
 address for each host.
 With current behavior, we can still use same TCP connect, after the
 links goes down and then the link is reconnected.
 -- 
 soda

From: Quentin Garnier <cube@cubidou.net>
To: SODA Noriyuki <soda@sra.co.jp>
Cc: perry@piermont.com, gnats-bugs@NetBSD.org
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Thu, 7 Dec 2006 09:05:24 +0100

 --+5X6wed+orjucm7J
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable

 On Thu, Dec 07, 2006 at 11:34:35AM +0900, SODA Noriyuki wrote:
 > >>>>> On Thu,  7 Dec 2006 02:25:01 +0000 (UTC), perry@piermont.com said:
 >=20
 > > The addresses bound to said interface will often go away, to be
 > > replaced by new ones (or none at all). However, even after they go
 > > away, TCP connections will continue to live for quite some time,
 > > eventually timing out, going into time wait, etc.
 >=20
 > > This is quite clearly silly.
 >=20
 > It is not so silly, acutally.
 > Think about unstable PPP link which nearly always assigns same IP
 > address for each host.

 And not necessarily unstable;  not so long ago most ADSL ISPs in France
 used to disconnect people after 24h.  It was a pain for Windows users,
 that OS being one that does what Perry wants.

 --=20
 Quentin Garnier - cube@cubidou.net - cube@NetBSD.org
 "You could have made it, spitting out benchmarks
 Owe it to yourself not to fail"
 Amplifico, Spitting Out Benchmarks, Hometakes Vol. 2, 2005.

 --+5X6wed+orjucm7J
 Content-Type: application/pgp-signature
 Content-Disposition: inline

 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.5 (NetBSD)

 iQEVAwUBRXfLRNgoQloHrPnoAQLOxQf/bi3jsPBulH/DXp+TCIVjCWki60V0QLbq
 ba1B6RV7IpHvvS0v9EiuFrUc7BJAQwPI3yAmYi/XnO7WP90MSQhDj6J1xfXtbUne
 cVZs+owhKhOn+N3TAtv330ZyiUJd1x/DnGpinRKcai/Y2bOXkCb0Sv83Fqz4OoIZ
 0KaV9l9uYckWUwERucEdT0iHyuHJS8Nc6kUckWcAwSQsT5l+An1WvScmfNm0JFej
 b6dg4Cv41wATTx+lZDOC5rj1Co6lIeJz8UrP0pMU8Rya2g9k80gaBWPMhwM4Wydh
 kPdH5Asj9SOh6L8Jij5RZoplv3a9kVsOhtcm0wIJheUL3P52OETkrQ==
 =9T4u
 -----END PGP SIGNATURE-----

 --+5X6wed+orjucm7J--

From: Alan Barrett <apb@cequrux.com>
To: gnats-bugs@NetBSD.org, netbsd-bugs@NetBSD.org
Cc: 
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Thu, 7 Dec 2006 10:13:03 -0200

 On Thu, 07 Dec 2006, SODA Noriyuki wrote:
 > It is not so silly, acutally.
 > Think about unstable PPP link which nearly always assigns same IP
 > address for each host.
 > With current behavior, we can still use same TCP connect, after the
 > links goes down and then the link is reconnected.

 I also find the existing behaviour useful with VPN links, which go down
 and come back up with the same IP address when I move my laptop from one
 location to another.

 It might be nice if "ifconfig ${interface} [down|destroy]" or "ifconfig
 ${interface} ${family} ${address} delete" had an extra flag to mean
 "also invalidate any sockets bound to this address, or to any address on
 this interface".

 --apb (Alan Barrett)

From: dieter roelants <dieter.NetBSD@pandora.be>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Thu, 07 Dec 2006 11:19:56 +0100

 > >Synopsis:       sockets should die if addresses vanish

 Sometimes I switch my laptop from wired to wireless and opposite and I =20
 really don't want it to close all connections. (I use the same IP for =20
 both NICs). If this behaviour is changed, please make it a =20
 (sysctl'able) option.

 Kind regards
 dieter

From: "Perry E. Metzger" <perry@piermont.com>
To: SODA Noriyuki <soda@sra.co.jp>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Thu, 07 Dec 2006 09:22:54 -0500

 SODA Noriyuki <soda@sra.co.jp> writes:
 >>>>>> On Thu,  7 Dec 2006 02:25:01 +0000 (UTC), perry@piermont.com said:
 >> The addresses bound to said interface will often go away, to be
 >> replaced by new ones (or none at all). However, even after they go
 >> away, TCP connections will continue to live for quite some time,
 >> eventually timing out, going into time wait, etc.
 >
 >> This is quite clearly silly.
 >
 > It is not so silly, acutally.
 > Think about unstable PPP link which nearly always assigns same IP
 > address for each host.
 > With current behavior, we can still use same TCP connect, after the
 > links goes down and then the link is reconnected.

 My problem is when the address does *not* return, which also happens
 in a lot of cases. Perhaps we could have a sysctl to control my
 proposed behavior (or to add a switch+timeout for it) so that users
 can pick their preferred behavior based on their usage pattern.

 Another alternative would be to tear down the connections when the
 same interface comes up again but with a different IP address.

 Perry

From: "Perry E. Metzger" <perry@piermont.com>
To: Quentin Garnier <cube@cubidou.net>
Cc: SODA Noriyuki <soda@sra.co.jp>, gnats-bugs@NetBSD.org
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Thu, 07 Dec 2006 09:29:33 -0500

 Quentin Garnier <cube@cubidou.net> writes:
 > On Thu, Dec 07, 2006 at 11:34:35AM +0900, SODA Noriyuki wrote:
 >> >>>>> On Thu,  7 Dec 2006 02:25:01 +0000 (UTC), perry@piermont.com said:
 >> 
 >> > The addresses bound to said interface will often go away, to be
 >> > replaced by new ones (or none at all). However, even after they go
 >> > away, TCP connections will continue to live for quite some time,
 >> > eventually timing out, going into time wait, etc.
 >> 
 >> > This is quite clearly silly.
 >> 
 >> It is not so silly, acutally.
 >> Think about unstable PPP link which nearly always assigns same IP
 >> address for each host.
 >
 > And not necessarily unstable;  not so long ago most ADSL ISPs in France
 > used to disconnect people after 24h.  It was a pain for Windows users,
 > that OS being one that does what Perry wants.

 Well, as I said, we could always make the behavior sysctl'able so you
 could pick based on your usage pattern.

 For my usage, I'm constantly opening up my laptop and acquiring a new
 address when I arrive somewhere. Generally, I then have all these
 connections that were active when I was at my last location some hours
 earlier that are now dead, and yet which now are around and sending
 out packets that can never be replied to.

 In addition to the possibility of a sysctl for the behavior, here is
 another idea: perhaps if you no longer have the origination address
 bound to any interface, you drop the packets you would otherwise send
 out from earlier connections rather than sending them out on an actual
 network. Then, if you get the address back, you can stop dropping
 them. This surely will cause no one any inconvenience, since those
 packets could never be replied to. It will not, however, be an optimal
 solution from my point of view...

 Perry

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
	netbsd-bugs@NetBSD.org
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Thu, 7 Dec 2006 22:32:54 +0100

 On Thu, Dec 07, 2006 at 02:25:01AM +0000, perry@piermont.com wrote:
 > [...]
 > 
 > This is quite clearly silly. If you no longer have the address from
 > which the packets for the socket putatively originate, you will
 > *never* get any reply packets. Your counterparty is *never* going to
 > be able to reply to you. The careful timeout machinery is useless.

 How do you know you won't get this same IP back later ? Say I have a
 USB or pcmcia interface that I plug out and plug back in, the
 connections should stay alive in that case.
 The timeout mechanism is certainly appropriate in this case.

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
	netbsd-bugs@NetBSD.org, perry@piermont.com
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Thu, 7 Dec 2006 22:36:32 +0100

 On Thu, Dec 07, 2006 at 02:30:08PM +0000, Perry E. Metzger wrote:
 >  > And not necessarily unstable;  not so long ago most ADSL ISPs in France
 >  > used to disconnect people after 24h.  It was a pain for Windows users,
 >  > that OS being one that does what Perry wants.
 >  
 >  Well, as I said, we could always make the behavior sysctl'able so you
 >  could pick based on your usage pattern.
 >  
 >  For my usage, I'm constantly opening up my laptop and acquiring a new
 >  address when I arrive somewhere. Generally, I then have all these
 >  connections that were active when I was at my last location some hours
 >  earlier that are now dead, and yet which now are around and sending
 >  out packets that can never be replied to.
 >  
 >  In addition to the possibility of a sysctl for the behavior, here is
 >  another idea: perhaps if you no longer have the origination address
 >  bound to any interface, you drop the packets you would otherwise send
 >  out from earlier connections rather than sending them out on an actual
 >  network. Then, if you get the address back, you can stop dropping
 >  them. This surely will cause no one any inconvenience, since those
 >  packets could never be replied to. It will not, however, be an optimal
 >  solution from my point of view...

 If your problem is that the system sends packets that could be seen as
 spoofed, then yes it's an acceptable solution.

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: "Perry E. Metzger" <perry@piermont.com>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Thu, 07 Dec 2006 16:40:24 -0500

 Manuel Bouyer <bouyer@antioche.eu.org> writes:
 >>  In addition to the possibility of a sysctl for the behavior, here is
 >>  another idea: perhaps if you no longer have the origination address
 >>  bound to any interface, you drop the packets you would otherwise send
 >>  out from earlier connections rather than sending them out on an actual
 >>  network. Then, if you get the address back, you can stop dropping
 >>  them. This surely will cause no one any inconvenience, since those
 >>  packets could never be replied to. It will not, however, be an optimal
 >>  solution from my point of view...
 >
 > If your problem is that the system sends packets that could be seen as
 > spoofed, then yes it's an acceptable solution.

 That is one problem. The bigger problem is processes that don't know
 that they should be doing something to re-open a socket because their
 original connection is no longer actually real.

 Perry

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Thu, 7 Dec 2006 22:41:34 +0100

 On Thu, Dec 07, 2006 at 04:40:24PM -0500, Perry E. Metzger wrote:
 > > spoofed, then yes it's an acceptable solution.
 > 
 > That is one problem. The bigger problem is processes that don't know
 > that they should be doing something to re-open a socket because their
 > original connection is no longer actually real.

 Sure but I'm not sure this would be fixed by closing connections.
 This issues also happens for UDP sockets.

 -- 
 Manuel Bouyer <bouyer@antioche.eu.org>
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: "Perry E. Metzger" <perry@piermont.com>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Thu, 07 Dec 2006 22:33:02 -0500

 Manuel Bouyer <bouyer@antioche.eu.org> writes:
 > On Thu, Dec 07, 2006 at 04:40:24PM -0500, Perry E. Metzger wrote:
 >> > spoofed, then yes it's an acceptable solution.
 >> 
 >> That is one problem. The bigger problem is processes that don't know
 >> that they should be doing something to re-open a socket because their
 >> original connection is no longer actually real.
 >
 > Sure but I'm not sure this would be fixed by closing connections.

 There we will have to disagree. I don't think it is reasonable to
 leave around "connections to nowhere". If you know that a connection
 can't be of any further use and that the packets it could send will
 never get anywhere and can't be replied to, I think there is something
 wrong with leaving things be.

 .pm

From: matthew green <mrg@eterna.com.au>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
	Manuel Bouyer <bouyer@antioche.eu.org>
Subject: re: kern/35196: sockets should die if addresses vanish 
Date: Fri, 08 Dec 2006 15:22:47 +1100

 i think this would best be solved by adding a ifconfig command to
 destroy sockets attached to an interface.  i do not recommend this
 name, but eg "ifconfig foo0 killconn".


 .mrg.

From: Manuel Bouyer <bouyer@antioche.eu.org>
To: "Perry E. Metzger" <perry@piermont.com>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Fri, 8 Dec 2006 08:55:34 +0100

 On Thu, Dec 07, 2006 at 10:33:02PM -0500, Perry E. Metzger wrote:
 > 
 > Manuel Bouyer <bouyer@antioche.eu.org> writes:
 > > On Thu, Dec 07, 2006 at 04:40:24PM -0500, Perry E. Metzger wrote:
 > >> > spoofed, then yes it's an acceptable solution.
 > >> 
 > >> That is one problem. The bigger problem is processes that don't know
 > >> that they should be doing something to re-open a socket because their
 > >> original connection is no longer actually real.
 > >
 > > Sure but I'm not sure this would be fixed by closing connections.
 > 
 > There we will have to disagree. I don't think it is reasonable to
 > leave around "connections to nowhere". If you know that a connection

 We're not talking about the same thing; here we're talking about established
 connections, I was talking about daemons that needs to notice the host IP
 address has changed

 > can't be of any further use and that the packets it could send will
 > never get anywhere and can't be replied to, I think there is something
 > wrong with leaving things be.

 We're disagreeing on the "never". You don't know if the IP address that
 dissapeared will be back or not.

 -- 
 Manuel Bouyer, LIP6, Universite Paris VI.           Manuel.Bouyer@lip6.fr
      NetBSD: 26 ans d'experience feront toujours la difference
 --

From: Martin Husemann <martin@duskware.de>
To: matthew green <mrg@eterna.com.au>
Cc: "Perry E. Metzger" <perry@piermont.com>, gnats-bugs@NetBSD.org,
	kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
	netbsd-bugs@NetBSD.org, Manuel Bouyer <bouyer@antioche.eu.org>
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Fri, 8 Dec 2006 11:12:09 +0100

 On Fri, Dec 08, 2006 at 03:22:47PM +1100, matthew green wrote:
 > i think this would best be solved by adding a ifconfig command to
 > destroy sockets attached to an interface.  i do not recommend this
 > name, but eg "ifconfig foo0 killconn".

 I agree with the idea, but am not sure if "ifconfig" is the right place
 to add this functionality.

 Could it be added to route(1) instead? It could probably be generalized then,
 like "kill all open connections using this route", and optionaly specify
 a route via an interface, meaning "all routes pointing to this interface".

 Anyway, a PR is not the right forum to discuss new ideas, let's please move
 this to tech-kern.

 Martin

From: Martin Husemann <martin@duskware.de>
To: matthew green <mrg@eterna.com.au>
Cc: "Perry E. Metzger" <perry@piermont.com>, gnats-bugs@NetBSD.org,
	kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
	netbsd-bugs@NetBSD.org, Manuel Bouyer <bouyer@antioche.eu.org>
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Fri, 8 Dec 2006 11:12:54 +0100

 On Fri, Dec 08, 2006 at 11:12:09AM +0100, Martin Husemann wrote:
 > Could it be added to route(1) instead?

 route(8) of course!

From: "Perry E. Metzger" <perry@piermont.com>
To: Manuel Bouyer <bouyer@antioche.eu.org>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Fri, 08 Dec 2006 09:45:13 -0500

 Manuel Bouyer <bouyer@antioche.eu.org> writes:
 >> can't be of any further use and that the packets it could send will
 >> never get anywhere and can't be replied to, I think there is something
 >> wrong with leaving things be.
 >
 > We're disagreeing on the "never". You don't know if the IP address that
 > dissapeared will be back or not.

 Most of the time you do, in fact, know. Some ISPs will give you your
 PPP address back. If you are using Verizon's EVDO service, you will
 not (except with vanishing probability) see the same address
 twice. That's why I suggested a sysctl.

 Perry

From: "Perry E. Metzger" <perry@piermont.com>
To: matthew green <mrg@eterna.com.au>
Cc: gnats-bugs@NetBSD.org, kern-bug-people@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org,
	Manuel Bouyer <bouyer@antioche.eu.org>
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Fri, 08 Dec 2006 09:46:02 -0500

 matthew green <mrg@eterna.com.au> writes:
 > i think this would best be solved by adding a ifconfig command to
 > destroy sockets attached to an interface.  i do not recommend this
 > name, but eg "ifconfig foo0 killconn".

 That would be perfectly acceptable to me, as would a command other than
 ifconfig that allowed me to destroy all connections associated with a
 particular local IP address.

 Perry

From: "Perry E. Metzger" <perry@piermont.com>
To: Martin Husemann <martin@duskware.de>
Cc: matthew green <mrg@eterna.com.au>, gnats-bugs@NetBSD.org,
	kern-bug-people@NetBSD.org, gnats-admin@NetBSD.org,
	netbsd-bugs@NetBSD.org, Manuel Bouyer <bouyer@antioche.eu.org>
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Fri, 08 Dec 2006 09:47:33 -0500

 Martin Husemann <martin@duskware.de> writes:
 > On Fri, Dec 08, 2006 at 03:22:47PM +1100, matthew green wrote:
 >> i think this would best be solved by adding a ifconfig command to
 >> destroy sockets attached to an interface.  i do not recommend this
 >> name, but eg "ifconfig foo0 killconn".
 >
 > I agree with the idea, but am not sure if "ifconfig" is the right place
 > to add this functionality.
 >
 > Could it be added to route(1) instead? It could probably be generalized then,
 > like "kill all open connections using this route", and optionaly specify
 > a route via an interface, meaning "all routes pointing to this interface".

 The one problem is, sometimes the interface doesn't exist any more at
 the point where you want to kill the things. (This is often the case
 for me, when popping out my EVDO card.)

 > Anyway, a PR is not the right forum to discuss new ideas, let's please move
 > this to tech-kern.

 I'll happily do so if someone will volunteer to summarize the
 discussion on tech-kern to get the ball rolling...

 Perry

From: "Jeremy C. Reed" <reed@reedmedia.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Fri, 8 Dec 2006 11:21:55 -0600 (CST)

 A sysctl for dropping tcp is found via 
 http://users.ece.gatech.edu/~dheeraj/netbsd.html

 (As an alternative maybe?)

From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, kern-bug-people@netbsd.org,
	gnats-admin@netbsd.org, netbsd-bugs@netbsd.org, perry@piermont.com
Cc: 
Subject: Re: kern/35196: sockets should die if addresses vanish
Date: Fri, 8 Dec 2006 13:20:19 -0500

 On Dec 8,  5:25pm, reed@reedmedia.net ("Jeremy C. Reed") wrote:
 -- Subject: Re: kern/35196: sockets should die if addresses vanish

 | The following reply was made to PR kern/35196; it has been noted by GNATS.
 | 
 | From: "Jeremy C. Reed" <reed@reedmedia.net>
 | To: gnats-bugs@NetBSD.org
 | Cc: 
 | Subject: Re: kern/35196: sockets should die if addresses vanish
 | Date: Fri, 8 Dec 2006 11:21:55 -0600 (CST)
 | 
 |  A sysctl for dropping tcp is found via 
 |  http://users.ece.gatech.edu/~dheeraj/netbsd.html
 |  
 |  (As an alternative maybe?)

 This patch has been around too long and it is really useful. The enemy
 of the good is the best. We need to decide on how to incorporate it
 in the source tree. I still think that sysctl is hacky, but I don't
 have any better ideas.

 christos

>Unformatted:

Home	PR Database Search