kern/43379: bridge(4) drops broadcast packets to member interface with IP from member interface without IP.

[julian.bourne%gmail.com@localhost]

>Number:         43379
>Category:       kern
>Synopsis:       bridge(4) drops broadcast packets to member interface with IP 
>from member interface without IP.
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri May 28 17:30:00 +0000 2010
>Originator:     Julian M.N. Bourne
>Release:        NetBSD-5 latest & RC1
>Organization:
>Environment:
NetBSD acre 5.0_STABLE NetBSD 5.0_STABLE (XEN3_ACRE) #7: Fri May 28 10:13:23 
EDT 2010  toor@..:/build/usr/src/sys-5-branch/arch/amd64/compile/XEN3_ACRE amd64
>Description:
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 
IP-bound interface.

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 
some minutes.

I have not tested as thoroughly for multicast, but it appears to have the same 
problem.

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.

Thanks,

-J.


>How-To-Repeat:
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 
received.

* also, if you connect fxp0 to tlp0 (via crossover or hub), the packet will be 
received.

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



>Fix: