From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Wed,  1 Jun 2011 22:57:13 -0400
To: 9fans@9fans.net
Message-ID: <326c09942bf9eb9d88c14d296c80b355@ladd.quanstro.net>
In-Reply-To: <20110602023648.8BB8AB827@mail.bitblocks.com>
References: <3c94c382decb6fec1b6fe5df7b29da66@ladd.quanstro.net>
	<alpine.OSX.2.00.1106011811560.26468@haldir.orthanc.ca>
	<37aa028227cbf68318c2703b7c6bf5ae@ladd.quanstro.net>
	<20110602014224.198F4B827@mail.bitblocks.com>
	<alpine.OSX.2.00.1106011859370.26468@haldir.orthanc.ca>
	<8407135a853d719d822d33eb6f5d014d@ladd.quanstro.net>
	<20110602020849.12628B827@mail.bitblocks.com>
	<74d0fe59cd997dda6e0c6df2d0be1cd7@ladd.quanstro.net>
	<20110602023648.8BB8AB827@mail.bitblocks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] icmp unreachable messages sometimes dropped
Topicbox-Message-UUID: ea6f5044-ead6-11e9-9d60-3106f5b1d025

> I thought reading the section would be enough. Sorry. Too much
> multiplexing.
> 1) you have to look at the codes to know whether what you
>    observed is a bug.
> 2) ignoring ICMP *except* during initial tcp negotiation seems
>    suboptimal -- the destination can disappear completely at
>    any time.  May be this results in an extra delay before a
>    connection is declared dead.  But I no longer remember
>    many details of tcp to know if this matters.
> 3) my main point was to check the rfcs to resolve such issues

the code has nothing to do with my argument.  let's take the
current behavior of terminating connection attempts on icmp
unreachable messages as correct.  nobody's argued differently.
so we can take the rfc out of the argument as well.

so unless you want your kernel to randomly respond to inputs,
an appropriate icmp unreachable matching your connection
attempt has got to always kill the connection.  surely you wouldn't
have it otherwise?

- erik