Strange forwarding issue with tap(4) and if_bridge(4)

[Bruce M Simpson]

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].