NetBSD Problem Report #43379

From www@NetBSD.org  Fri May 28 17:29:53 2010
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id D424463B874
	for <gnats-bugs@gnats.NetBSD.org>; Fri, 28 May 2010 17:29:53 +0000 (UTC)
Message-Id: <20100528172953.986C763B873@www.NetBSD.org>
Date: Fri, 28 May 2010 17:29:53 +0000 (UTC)
From: julian.bourne@gmail.com
Reply-To: julian.bourne@gmail.com
To: gnats-bugs@NetBSD.org
Subject: bridge(4) drops broadcast packets to member interface with IP from member interface without IP.
X-Send-Pr-Version: www-1.0

>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:

Home	PR Database Search