From owner-cvs-sys  Sat May 24 17:05:26 1997
Return-Path: <owner-cvs-sys>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id RAA26551
          for cvs-sys-outgoing; Sat, 24 May 1997 17:05:26 -0700 (PDT)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA26546;
          Sat, 24 May 1997 17:05:21 -0700 (PDT)
Received: (from daemon@localhost)
	by alpo.whistle.com (8.8.5/8.8.5) id QAA22656;
	Sat, 24 May 1997 16:53:37 -0700 (PDT)
Received: from current1.whistle.com(207.76.205.22)
 via SMTP by alpo.whistle.com, id smtpd022654; Sat May 24 23:53:31 1997
Date: Sat, 24 May 1997 16:52:56 -0700 (PDT)
From: Julian Elischer <julian@current1.whistle.com>
To: Darren Reed <darrenr@cyber.com.au>
cc: Julian Elischer <julian@FreeBSD.ORG>, cvs-committers@FreeBSD.ORG,
        cvs-all@FreeBSD.ORG, cvs-sys@FreeBSD.ORG
Subject: Re: cvs commit: src/sys/netinet ip_icmp.c
In-Reply-To: <199705240258.MAA11722@plum.cyber.com.au>
Message-ID: <Pine.BSF.3.95.970524164855.9921A-100000@current1.whistle.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-cvs-sys@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk



On Sat, 24 May 1997, Darren Reed wrote:

> In some mail I received from Julian Elischer, sie wrote
> > 
> > julian      1997/05/23 15:17:34 PDT
> > 
> >   Modified files:        (Branch: WHISTLE_NET_BRANCH_1)
> >     sys/netinet          ip_icmp.c 
> >   Log:
> >   Submitted by:	archie@whistle.com
> >   don't look for a matching receive interface if the packet was not received.
> >   This can happen if an icmp UNREACH or similar is being generated
> >   by firewall code. (Prior to firewall code this was not possible).
> 
> This series of changes intrigues me.  When I came upon this problem, I at
> first thought it a problem and then realised that for locally generated
> packets, this situation is usually handled by functions returning an error
> code (i.e. EHOSTUNREACH or similar) rather than there being an ICMP packet
> to respond to.
> 
> IMHO, ipfw shouldn't send an ICMP response to a locally generated packet.

In general I agree but there are some cases where it's more of a change
to do it your way, than to let one piece of code handle both cases
sub-optimally. It's a very minor change and we are seeing systems
crashing in the field for the lack of it. I agree that there are other
things that can be done about it but I still think this change
is a worth while sanity check.

 > Darren
>