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 Message-ID: <Pine.BSF.3.95.970524164855.9921A-100000@current1.whistle.com> In-Reply-To: <199705240258.MAA11722@plum.cyber.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.970524164855.9921A-100000>