From owner-freebsd-current Tue Aug 17 0:11:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from mercury.is.co.za (mercury.is.co.za [196.4.160.222]) by hub.freebsd.org (Postfix) with ESMTP id 067B3156FC for ; Tue, 17 Aug 1999 00:11:19 -0700 (PDT) (envelope-from geoffr@is.co.za) Received: from ISJHBEX (isjhbexnode.is.co.za [196.26.1.2]) by mercury.is.co.za (8.9.3/8.9.3) with ESMTP id IAA02497; Tue, 17 Aug 1999 08:05:32 +0200 Received: by isjhbex.is.co.za with Internet Mail Service (5.5.2448.0) id ; Tue, 17 Aug 1999 09:14:31 +0200 Message-ID: From: Geoff Rehmet To: "'Archie Cobbs'" Cc: imp@village.org, brian@CSUA.Berkeley.EDU, current@FreeBSD.ORG Subject: RE: Dropping connections without RST Date: Tue, 17 Aug 1999 09:14:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > Geoff Rehmet writes: > > > : Not that easily.. how are you going to make ipfw > dynamically know > > > : which ports have listeners and which don't? > > > > > > By filtering all RST packets? > > > > My view was that this is much simpler than filtering packets - > > never generate the packet. My guess is that it creates lower > > overheads. In some instances, I don't want to look at every > > packet (which in effect happens with a packet filter). > > Plus, packets with RST in them are used for other purposes besides > rejecting new incoming connections.. True, my implementation is specific that I only omit generating a RST when the icoming segment is a SYN. All other instances where you would generate a RST are left alone, and carry on behaving as before - otherwise you might break TCP behaviour. Geoff. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message