From owner-freebsd-net Sun Feb 4 7:59:51 2001 Delivered-To: freebsd-net@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0B2B737B4EC; Sun, 4 Feb 2001 07:59:31 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.1/8.11.1) with SMTP id f14FxTh70923; Sun, 4 Feb 2001 10:59:29 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 4 Feb 2001 10:59:29 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: Rich Wales Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: BRIDGE breaks ARP? (more info) In-Reply-To: <20010204062837.94849.richw@wyattearp.stanford.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 3 Feb 2001, Rich Wales wrote: > Earlier, I reported an ARP problem on a 4.2-STABLE bridge system. > > A few people wrote me privately, advising me to include a firewall rule > passing UDP packets on port 2054 to/from the IP address 0.0.0.0. > > I've tried this, but it doesn't help any. I should mention, though, > that I don't think this firewall rule is relevant in any case. > > First, the "port 2054" kludge doesn't appear to be in the networking > code any more. I grep'ed the entire -STABLE base source for any > references to UDP port 2054, and I found nothing at all except for the > commented-out line in the etc/rc.firewall file. As far as I'm aware, > bridging of non-IP packets is now controlled by the kernel's default > "ipfw" rule -- and, yes, I do have the options IPFIREWALL and > IPFIREWALL_DEFAULT_TO_ACCEPT in my configuration. There used to be a kludge that mapped the ether_header.ether_type field of non-IP packets into the UDP port number for the purposes of certain IPFW rules when bridging. This was pretty awful. :-) That kludge was removed, and the BRIDGE code now simply forwards all non-IP packets, including ARP, and does not pass them through IPFW when IPFW is enabled, making them follow the equivilent of a default pass rule. This is a kludge that I am glad to see go: I can certainly imagine the desire to support non-IP filtering in a bridge, but IPFW was not the right vehicle for that. I believe the removal of the kludge occurred along with Archie's other fixups around Jun 21, 2000, which was certainly prior to 4.2-RELEASE. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message