>Synopsis: bridge(4) drops broadcast packets to member interface with IP
>from member interface without IP.
>Arrival-Date: Fri May 28 17:30:00 +0000 2010
>Originator: Julian M.N. Bourne
>Release: NetBSD-5 latest & RC1
NetBSD acre 5.0_STABLE NetBSD 5.0_STABLE (XEN3_ACRE) #7: Fri May 28 10:13:23
EDT 2010 [email protected]:/build/usr/src/sys-5-branch/arch/amd64/compile/XEN3_ACRE amd64
When using bridge(4) to bridge interfaces, packets broadcast to the IP-bound
bridge member from a non-IP-bound bridge member interface never arrive at
programs listening for them, even though they can be seen in tcpdump on the
This is serious because it can break router daemons in unusual ways. For
example, with RIPv1 based routed running on the bridging host, the routes to
non-primary interfaces will be set up correctly when routed starts, beacuse the
discovery mechanism causes a directed unicast from the routers on the
non-primary interfaces, which makes everything seem like its working.
But after that, routing updates fall back to broadcasts, which are never
received, resulting in the disabling and finally removal of those routes after
I have not tested as thoroughly for multicast, but it appears to have the same
I have a small program I wrote to allow easy listening and sending of
broadcasts - email if you need it.
Note: this problem occurs for both amd64 and i386 5.0.2 and latest 5 branch on
both real NICs and virtual interfaces.
I have looked into if_bridge.c, performed some tracing and so on and have
verified that the UDP packet is queued to the IP-bound interface by
bridge_broadcast, which makes sense since tcpdump sees it on that interface.
I am looking deeper now, but I could do with some guidance.
Two easy ways to repeat:
(1) With real hardware:
* Two machines host-a and host-b.
* host-a has two NICs, tlp0 and tlp1.
* tlp0 is up and bound to 192.168.0.2.
* tlp1 is up and not bound.
* bridge0 is up and has members tlp0 and tlp1.
* host-b has one NIC, fxp0 bound to 192.168.0.252.
* fxp0 on host-b is connected to tlp1 on host-a (either crossover or via hub).
* bind some program to 0.0.0.0 port 7777 on host-a
* on host a: tcpdump -s0 -tnli tlp0 port 7777
* send a UDP packet to 192.168.0.255 port 7777 from host-b fxp0.
* packet will appear on tcpdump on host-a, but will not reach program.
* now bind on host-b and send from host-a - this time the packet will be
* also, if you connect fxp0 to tlp0 (via crossover or hub), the packet will be
2) With virtual hardware (using xen), same as above except:
* host-a is dom0
* host-b is some domU
* tlp0 is replaced with tap0
* host-b domU is set up with an xvif on bridge0
* fxp0 is instead xennet0 on host0-b
This will give identical behaviour, right down to the assymetry of the
broadcast behaviour (domU will receive OK, dom0 will not).