From owner-freebsd-current Mon Jan 24 19:41:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from mrynet.com (mrynet.com [24.234.53.177]) by hub.freebsd.org (Postfix) with ESMTP id 003F715429 for ; Mon, 24 Jan 2000 19:41:05 -0800 (PST) (envelope-from freebsd@mrynet.com) Received: (from freebsd@localhost) by mrynet.com (8.9.3/8.9.3) id TAA00561; Mon, 24 Jan 2000 19:41:02 -0800 (PST) (envelope-from freebsd) Posted-Date: Mon, 24 Jan 2000 19:41:02 -0800 (PST) Message-Id: <200001250341.TAA00561@mrynet.com> From: freebsd@mrynet.com (FreeBSD mailing list) Date: Mon, 24 Jan 2000 19:41:02 +0000 X-Mailer: Mail User's Shell (7.2.6 beta(3) 11/17/96) To: Alfred Perlstein Subject: Re: sys/net/bridge.c IPFIREWALL & DUMMYNET? WTF? Cc: freebsd-current@freebsd.org Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > * Matthew N. Dodd [000124 18:11] wrote: > > Any reason that the IPFIREWALL and DUMMYNET code is present in > > sys/net/bridge.c? It appears that it makes a number of bad assumptions > > and in general violates the semantics of 'bridging' vs. 'routing'. > > > > Should we even encourage people to use this functionality? Do we really > > want bridge.c to have its own private IP stack? > > > > Should this code be diked out before 4.0 so we don't expose the masses to > > it? > > I'm not sure what your proposing, if it's removing BRIDGE support from > the kernel, I'd have to object. BRIDGE enables me to run a transparent > firewall without worrying about routing issues, just drop a machine > with BRIDGE and IPFIREWALL in between two points and everything is ok. > > However enable a DIVERT socket, and it all goes to hell last i checked. > > Anyhow, can you clarify? > > -Alfred I would also object. Rather than Matthew just complaining he doesn't like the coding style or the implementation, perhaps he could suggest something constructive towards improvement or redesign rather than criticise and suggest callously pitching it. This functionality has proven instrumental and necessary for transparent and effortless combining of unlike physical topologies. It also provides the extra protective measure of being able to firewall public traffic on subnetworks connected to public-traffic providers such as cable modems. The functionality of bridging is solid. The added functionality of bridging has nothing offensive to it except perhaps offending someone's idea of sensibility in this instance. Questioning code and usefulness is one thing. Presumtive resolve with disregard is another. Regards, Scott -- Scott G. Akmentins-Taylor InterNet: staylor@mrynet.com MRY Systems staylor@mrynet.lv To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message