Date: Fri, 18 Apr 2008 10:26:17 +0100 From: Bruce M Simpson <bms@incunabulum.net> To: FreeBSD-Net mailing list <freebsd-net@freebsd.org> Subject: Strange forwarding issue with tap(4) and if_bridge(4) Message-ID: <48086939.1090403@incunabulum.net>
next in thread | raw e-mail | index | archive | help
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].
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48086939.1090403>