From owner-freebsd-ipfw Wed Oct 2 10:36:25 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCB7437B401; Wed, 2 Oct 2002 10:36:23 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6DD5843E42; Wed, 2 Oct 2002 10:36:23 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20021002173623.GSVH18767.rwcrmhc53.attbi.com@blossom.cjclark.org>; Wed, 2 Oct 2002 17:36:23 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.3/8.12.3) with ESMTP id g92HaLWn087456; Wed, 2 Oct 2002 10:36:22 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.3/8.12.3/Submit) id g92HaKhI087455; Wed, 2 Oct 2002 10:36:20 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Wed, 2 Oct 2002 10:36:20 -0700 From: "Crist J. Clark" To: ipfw@freebsd.org, luigi@freebsd.org Subject: ipfw(8), bridge(4), and arp(4) Message-ID: <20021002173620.GA87135@blossom.cjclark.org> Reply-To: cjclark@alum.mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I am seeing some strangeness with ipfw(8) and bridge(4). It looks like ARP is being blocked somewhere for the bridging host. When I enable bridging, everything works fine. When I turn on ipfw(8) in the bridge, # sysctl net.link.ether.bridge_ipfw=1 Things get a little messed up. The funny thing is, machines can communicate freely with one another on opposite sides of the bridge, but the bridge host itself seems to be having some problems. When I try to communicate directly with the bridge host, the ARPs go unanswered. tcpdump(8) on any host, including the bridge host, show the "who-is" messages go out, but there is no response. This seems to be an ARP or at least non-IP problem. Can anyone reproduce the following or something like it: (1) Establish a TCP connection to a bridging host (e.g. ssh or telnet in). (2) On the bridging host, turn on ipfw(8) in the bridge, # sysctl net.link.ether.bridge_ipfw=1 (3) If your arp(8) cache is still fresh, your TCP connection should work fine. (4) On the TCP client, clear the arp(8) entry for the bridge host from the cache, # arp -d bridge-host (5) Does your TCP connection no longer work? (6) Turn off ipfw(8) in the bridge, # sysctl net.link.ether.bridge_ipfw=0 (7) Does the TCP connection snap back to life? I'm wondering if this is a result of some of the changes to ipfw(8) in bridging and filtering at the Ethernet layer. Bug or feature? luigi, is there something, besides code and commit messages, documenting the design of ipfw(8) interaction at the link-layer? I've bumped into this while trying to get IPFilter working in RELENG_4 bridging again. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message