From owner-freebsd-net@FreeBSD.ORG Fri Apr 18 09:26:19 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 969A3106564A for ; Fri, 18 Apr 2008 09:26:19 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 4FC458FC18 for ; Fri, 18 Apr 2008 09:26:19 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id E506CCCA0F for ; Fri, 18 Apr 2008 05:26:18 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Fri, 18 Apr 2008 05:26:18 -0400 X-Sasl-enc: skd3P3BCMd2gV40uJxVXP3PEGFP7yB9L3SD8n1oyTjZi 1208510778 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 631F0115B3 for ; Fri, 18 Apr 2008 05:26:18 -0400 (EDT) Message-ID: <48086939.1090403@incunabulum.net> Date: Fri, 18 Apr 2008 10:26:17 +0100 From: Bruce M Simpson User-Agent: Thunderbird 2.0.0.12 (X11/20080405) MIME-Version: 1.0 To: FreeBSD-Net mailing list X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Strange forwarding issue with tap(4) and if_bridge(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Apr 2008 09:26:19 -0000 Hi, I noticed a strange issue with tap(4) and if_bridge(4) where the bridge seems not to be forwarding frames. 6.3-RELEASE, btw. I have this setup where I use the two to bootstrap QEMU virtual machines. Up until now I've been using dhcpd for this. This has only ever worked right for me if I run dhcpd on the bridge interface. However I tried doing it on a second tap, and it worked OK for me. qemu -------- /dev/tap0 ---- tap0 ---------- bridge0 -------- tap1 ----- [bpf] ----- dhcpcd ------------> DHCP discovery broadcasts <------------- DHCP unicast replies OK If I run dhcpd on another tap interface, this works OK, but obviously only if I open the matching character device. dhcpd of course uses bpf for injection, not the character device. HOWEVER: If I try to run my own BOOTP server in userland, on the character device, what happens is this: If I tcpdump, I see the broadcast DHCP discover messages on the tap OK. bpf also sees the unicast replies my code generates. But if_bridge does not forward my traffic, even though the unicast addresses appear to be correct. qemu -------- /dev/tap0 ---- tap0 ---------- bridge0 -------- tap1 ----- /dev/tap1 ----- my_bootpd ------------> DHCP discovery broadcasts X <------------- BOOTP unicast replies NOT OK The BOOTP replies (written to /dev/tap1) do not appear on bridge0 or tap0. They do however appear on tap1. In the first setup, the DHCP replies appear on all interfaces in the bridge, including the bridge. What if anything could I be doing wrong? tcpdump and wireshark report that the BOOTP replies I am generating are well formed. The write semantics I use are identical to those of the QEMU client at the other end. I've ruled out pfil/firewall filters. Now, as tap1 has been added to a bridge, it is in promiscuous mode -- and because bpf shows the userland-generated frames being sent, I believe the check I added for the destination address in if_tap.c can be ruled out. The problem occurs even if I add static entries to the bridge's address cache and disable all learning. Both RSTP and STP are disabled. Thanks for any help you can provide. cheers BMS [P.S. I have noticed that in order to get frames from /dev/tapX, non-blocking reads are necessary. My code is single threaded, I use select() to block it].