NetBSD Problem Report #48104
From www@NetBSD.org Mon Aug 5 00:54:08 2013
Return-Path: <www@NetBSD.org>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id 9BB0C70F20
for <gnats-bugs@gnats.NetBSD.org>; Mon, 5 Aug 2013 00:54:08 +0000 (UTC)
Message-Id: <20130805005407.0DC1C70F21@mollari.NetBSD.org>
Date: Mon, 5 Aug 2013 00:54:07 +0000 (UTC)
From: lloyd@must-have-coffee.gen.nz
Reply-To: lloyd@must-have-coffee.gen.nz
To: gnats-bugs@NetBSD.org
Subject: Incorrect forwarding of broadcast packets by bridge(4)
X-Send-Pr-Version: www-1.0
>Number: 48104
>Category: kern
>Synopsis: Incorrect forwarding of broadcast packets by bridge(4)
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: kern-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Mon Aug 05 00:55:00 +0000 2013
>Closed-Date: Sun May 01 05:54:19 +0000 2016
>Last-Modified: Sun May 01 05:54:19 +0000 2016
>Originator: Lloyd Parkes
>Release: NetBSD 6.1
>Organization:
Must Have Coffee
>Environment:
NetBSD netboot 6.1 NetBSD 6.1 (GENERIC) #8: Mon Aug 5 12:07:00 NZST 2013 lloyd@castigate.must-have-coffee.gen.nz:/Volumes/ramdisk/build-6net/obj.i386/sys/arch/i386/compile/GENERIC i386
>Description:
When a broadcast packet is received on a bridge(4) port, it is send out all the other ports, but it is never passed up the network stack of those ports as an input packet. This is at odds with how unicast packets are handled.
>How-To-Repeat:
I have two LANs connected by a router. The first LAN has the addresses 10.0.1.0/24 and 2002:cb61:d534:3::/64 and it is the desktop LAN in my house. The second LAN is for testing this problem and it has the two addresses 10.0.240.0/24 and 2002:cb61:d534:2000::/64.
I have two computers. The first is my desktop called Castigate and it has a single interface on my desktop LAN. The second is my test system and it has five ethernet interfaces called ste0, ste1, ste2, ste3, and ex0. ex0 connected to my desktop LAN and I use it to keep my monitoring traffic off the test LAN. ste0 is connected to an unconfigured router port in order to brink the link up. ste3 is connected to the test LAN. ste1 and ste2 and not connected to anything. The test system also runs bridge0 which contains ste0 and ste3. The following configures my test system.
ifconfig bridge0 create
ifconfig ste0 inet6 2002:cb61:d534:2000:234:78ff:fe00:1
ifconfig ste3 inet6 2002:cb61:d534:2000:234:78ff:fe00:4
brconfig bridge0 add ste0
brconfig bridge0 add ste3
ifconfig bridge0 up
ifconfig ste0 inet 10.0.240.1 netmask 255.255.255.0
ifconfig ste3 inet 10.0.240.4 netmask 255.255.255.0
On Castigate run "ping6 -c 10 2002:cb61:d534:2000:234:78ff:fe00:1" and "ping -c 10 10.0.240.1". Note that both commands report a 100% packet loss. tcpdump running on ste0 shows the ARP/NDP packets that are ostensibly being lost, so we know that the packets are being passed by the bridge.
On Castigate run "ping6 -c 10 2002:cb61:d534:2000:234:78ff:fe00:4" and "ping -c 10 10.0.240.4". Note that we get 0% packet loss because we are now pinging the interfaces directly connected to the router.
>Fix:
Index: sys/net/if_bridge.c
===================================================================
RCS file: /vol/src/rsync-src/src/sys/net/if_bridge.c,v
retrieving revision 1.74
diff -u -r1.74 if_bridge.c
--- sys/net/if_bridge.c 19 Nov 2011 22:51:25 -0000 1.74
+++ sys/net/if_bridge.c 5 Aug 2013 00:05:32 -0000
@@ -1633,6 +1633,13 @@
}
bridge_enqueue(sc, dst_if, mc, 1);
+ mc = m_copym(m, 0, M_COPYALL, M_DONTWAIT);
+ if (mc == NULL) {
+ sc->sc_if.if_oerrors++;
+ continue;
+ }
+ mc->m_pkthdr.rcvif = dst_if;
+ (*dst_if->if_input)(dst_if, mc);
}
if (used == 0)
m_freem(m);
Index: sys/net/if_ethersubr.c
===================================================================
The following works for me. The change to if_bridge.c gets the packets copied to all the other bridge ports and the change to if_ethersubr.c prevents packets that have already been broadcast from being rebroadcast.
RCS file: /vol/src/rsync-src/src/sys/net/if_ethersubr.c,v
retrieving revision 1.188.8.3
diff -u -r1.188.8.3 if_ethersubr.c
--- sys/net/if_ethersubr.c 31 Oct 2012 16:07:46 -0000 1.188.8.3
+++ sys/net/if_ethersubr.c 4 Aug 2013 06:53:32 -0000
@@ -703,7 +703,8 @@
* will always return the original packet if we need to
* process it locally.
*/
- if (ifp->if_bridge) {
+ if (ifp->if_bridge && (m->m_flags & M_LINK2) == 0) {
+ m->m_flags |= M_LINK2;
/* clear M_PROMISC, in case the packets comes from a vlan */
m->m_flags &= ~M_PROMISC;
m = bridge_input(ifp, m);
>Release-Note:
>Audit-Trail:
From: dieter roelants <dieter.NetBSD@pandora.be>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/48104: Incorrect forwarding of broadcast packets by bridge(4)
Date: Mon, 28 Oct 2013 17:12:10 +0100
--089e0149ccdec187cd04e9cf5cd7
Content-Type: text/plain; charset=UTF-8
Hi Lloyd
On Mon, Aug 5, 2013 at 2:55 AM, <lloyd@must-have-coffee.gen.nz> wrote:
>
> The following works for me. The change to if_bridge.c gets the packets
> copied to all the other bridge ports and the change to if_ethersubr.c
> prevents packets that have already been broadcast from being rebroadcast.
>
I forgot about it but I had applied your patch on a system running as Xen
dom-0 and it made it panic upon starting the first (ipv6-enabled) dom-U.
The panic message was:
"m_copydata: m = NULL, len = 67502046"
and it appeared right after the following message
"xvif1i0: discarding oversize frame (len = 67502088)".
The backtrace looked like this:
vpanic
printf_nolog
m_copydata at netbsd:m_copy_data+0xbb
xennetback_if_softstart_copy+0x30b
softint_thread+0x5a
(I scribbled it down on a piece of paper at the time, so there may be typos
in there...)
kind regards
dieter
--089e0149ccdec187cd04e9cf5cd7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra">Hi Lloyd<br></div><div clas=
s=3D"gmail_extra"><br><div class=3D"gmail_quote">On Mon, Aug 5, 2013 at 2:5=
5 AM, <span dir=3D"ltr"><<a href=3D"mailto:lloyd@must-have-coffee.gen.n=
z" target=3D"_blank">lloyd@must-have-coffee.gen.nz</a>></span> wrote:<br=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
The following works for me. The change to if_bridge.c gets the packets copi=
ed to all the other bridge ports and the change to if_ethersubr.c prevents =
packets that have already been broadcast from being rebroadcast.<br></block=
quote>
</div><br></div><div class=3D"gmail_extra">I forgot about it but I had appl=
ied your patch on a system running as Xen dom-0 and it made it panic upon s=
tarting the first (ipv6-enabled) dom-U. The panic message was:<br>"m_c=
opydata: m =3D NULL, len =3D 67502046"<br>
and it appeared right after the following message<br>"xvif1i0: discard=
ing oversize frame (len =3D 67502088)".<br>The backtrace looked like t=
his:<br><br></div><div class=3D"gmail_extra">vpanic<br></div><div class=3D"=
gmail_extra">
printf_nolog<br></div><div class=3D"gmail_extra">m_copydata at netbsd:m_cop=
y_data+0xbb<br></div><div class=3D"gmail_extra">xennetback_if_softstart_cop=
y+0x30b<br></div><div class=3D"gmail_extra">softint_thread+0x5a<br><br></di=
v>
<div class=3D"gmail_extra">(I scribbled it down on a piece of paper at the =
time, so there may be typos in there...)<br><br></div><div class=3D"gmail_e=
xtra">kind regards<br>dieter<br></div></div>
--089e0149ccdec187cd04e9cf5cd7--
From: Lloyd Parkes <lloyd@must-have-coffee.gen.nz>
To: gnats-bugs@NetBSD.org,
dieter roelants <dieter.NetBSD@pandora.be>
Cc: kern-bug-people@netbsd.org,
gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org
Subject: Re: kern/48104: Incorrect forwarding of broadcast packets by bridge(4)
Date: Tue, 29 Oct 2013 10:27:58 +1300
Thanks for the bug report on my bug report.
I didn=92t test xennet with my patch because my test machine really =
couldn=92t cope with Xen.
I now have a spare machine that can run Xen and have my quad port =
network card plugged in to it, so I should be able to run a more =
complete set of tests in the next day or two.
Cheers,
Lloyd=
From: dieter roelants <dieter.NetBSD@pandora.be>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: kern/48104: Incorrect forwarding of broadcast packets by bridge(4)
Date: Thu, 31 Oct 2013 16:48:59 +0100
--047d7bdc9c525ad0b504ea0b63c9
Content-Type: text/plain; charset=UTF-8
I can now no longer reproduce this panic but I don't know why. If I screwed
up then, it must have been something in the config, because I applied the
same patch file as last time.
On Mon, Oct 28, 2013 at 5:12 PM, dieter roelants
<dieter.NetBSD@pandora.be>wrote:
>
>
> I forgot about it but I had applied your patch on a system running as Xen
> dom-0 and it made it panic upon starting the first (ipv6-enabled) dom-U.
> The panic message was:
> "m_copydata: m = NULL, len = 67502046"
> and it appeared right after the following message
> "xvif1i0: discarding oversize frame (len = 67502088)".
> The backtrace looked like this:
>
> vpanic
> printf_nolog
> m_copydata at netbsd:m_copy_data+0xbb
> xennetback_if_softstart_copy+0x30b
> softint_thread+0x5a
>
> (I scribbled it down on a piece of paper at the time, so there may be
> typos in there...)
>
> kind regards
> dieter
>
--047d7bdc9c525ad0b504ea0b63c9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div>I can now no longer reproduce this panic bu=
t I don't know why. If I screwed up then, it must have been something i=
n the config, because I applied the same patch file as last time.<br><br><b=
r>
<div><div class=3D"gmail_extra"><div class=3D"gmail_quote">
On Mon, Oct 28, 2013 at 5:12 PM, dieter roelants <span dir=3D"ltr"><<a h=
ref=3D"mailto:dieter.NetBSD@pandora.be" target=3D"_blank">dieter.NetBSD@pan=
dora.be</a>></span> wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div class=3D"gmail_extra">I forgot about it but I had=
applied your patch on a system running as Xen dom-0 and it made it panic u=
pon starting the first (ipv6-enabled) dom-U. The panic message was:<br>&quo=
t;m_copydata: m =3D NULL, len =3D 67502046"<br>
and it appeared right after the following message<br>"xvif1i0: discard=
ing oversize frame (len =3D 67502088)".<br>The backtrace looked like t=
his:<br><br></div><div class=3D"gmail_extra">vpanic<br></div><div class=3D"=
gmail_extra">
printf_nolog<br></div><div class=3D"gmail_extra">m_copydata at netbsd:m_cop=
y_data+0xbb<br></div><div class=3D"gmail_extra">xennetback_if_softstart_cop=
y+0x30b<br></div><div class=3D"gmail_extra">softint_thread+0x5a<br><br></di=
v>
<div class=3D"gmail_extra">(I scribbled it down on a piece of paper at the =
time, so there may be typos in there...)<br><br></div><div>kind regards<spa=
n><font color=3D"#888888"><br>dieter</font></span> <br></div></div></blockq=
uote>
</div><br></div></div></div>
--047d7bdc9c525ad0b504ea0b63c9--
From: Lloyd Parkes <lloyd@must-have-coffee.gen.nz>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/48104: Incorrect forwarding of broadcast packets by bridge(4)
Date: Fri, 21 Feb 2014 13:32:39 +1300
I have finally tested a version of my fix for this problem that I think =
is suitable for general use. If someone could review and commit this =
patch it would be appreciated. I have tested this with multiple physical =
and Xen interfaces.
This patch changes the bridge driver so that it hooks the struct ifnet =
if_input field rather than tapping the bridged packet out of =
ether_input(). This allows the bridge to call ether_input() repeatedly =
(if necessary) without having to worry about a recursive packet storm.
My diff is at http://home.must-have-coffee.gen.nz/lloyd/bridge.diff.
Cheers,
Lloyd
From: "Ryota Ozaki" <ozaki-r@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/48104 CVS commit: src/sys/net
Date: Tue, 17 Jun 2014 10:39:46 +0000
Module Name: src
Committed By: ozaki-r
Date: Tue Jun 17 10:39:46 UTC 2014
Modified Files:
src/sys/net: bridgestp.c if_bridge.c if_bridgevar.h if_ethersubr.c
Log Message:
Restructure ether_input and bridge_input
The network stack of NetBSD is well organized and
layered. A packet reception is processed from a
lower layer to an upper layer one by one. However,
ether_input and bridge_input are not structured so.
bridge_input is called inside ether_input.
The new structure replaces ifnet#if_input of a bridge
member with bridge_input when the member is attached.
So a packet goes straight on a packet reception via
a bridge, bridge_input => ether_input => ip_input.
The change is part of a patch of Lloyd Parkes submitted
in PR 48104. Unlike the patch, the change doesn't
intend to change the behavior of the packet processing.
Another patch will fix PR 48104.
To generate a diff of this commit:
cvs rdiff -u -r1.14 -r1.15 src/sys/net/bridgestp.c
cvs rdiff -u -r1.80 -r1.81 src/sys/net/if_bridge.c
cvs rdiff -u -r1.17 -r1.18 src/sys/net/if_bridgevar.h
cvs rdiff -u -r1.200 -r1.201 src/sys/net/if_ethersubr.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Ryota Ozaki" <ozaki-r@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/48104 CVS commit: src/sys/net
Date: Wed, 18 Jun 2014 10:51:03 +0000
Module Name: src
Committed By: ozaki-r
Date: Wed Jun 18 10:51:03 UTC 2014
Modified Files:
src/sys/net: if_bridge.c
Log Message:
Restructure bridge_input and bridge_broadcast
There are two changes:
- Assemble the places calling pktq_enqueue (bridge_forward)
for unicast and {b,m}cast frames into one
- Receive {b,m}cast frames in bridge_broadcast, not in
bridge_input
The changes make the code clear and readable. bridge_input
now doesn't need to take care of {b,m}cast frames;
bridge_forward and bridge_broadcast have the responsibility.
The changes are based on a patch of Lloyd Parkes submitted
in PR 48104, but don't fix its issue yet.
To generate a diff of this commit:
cvs rdiff -u -r1.82 -r1.83 src/sys/net/if_bridge.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Ryota Ozaki" <ozaki-r@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/48104 CVS commit: src/tests/net/if_bridge
Date: Tue, 9 Jun 2015 00:39:53 +0000
Module Name: src
Committed By: ozaki-r
Date: Tue Jun 9 00:39:53 UTC 2015
Modified Files:
src/tests/net/if_bridge: t_bridge.sh
Log Message:
Add tests for bridge members with an IP address
The tests include checks for PR#48104 which is not fixed yet.
Note that one test unexpectedly fails for some reason
(unrelated to PR#48104). We have to fix it somehow.
To generate a diff of this commit:
cvs rdiff -u -r1.7 -r1.8 src/tests/net/if_bridge/t_bridge.sh
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "Ryota Ozaki" <ozaki-r@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/48104 CVS commit: src/sys/net
Date: Thu, 23 Jul 2015 10:52:34 +0000
Module Name: src
Committed By: ozaki-r
Date: Thu Jul 23 10:52:34 UTC 2015
Modified Files:
src/sys/net: if_bridge.c
Log Message:
Fix PR 48104
So far bridge cannot receive frames via a member interface when the frames
come from another member interface. So when we assign an IP address to
a member interface, hosts connected to another member interface cannot
ping to the IP address. That behavior isn't expected. See PR 48104 for
more realistic examples of this issue.
The change does:
- drop M_PROMISC before ether_input, which allows a bridge member interface
to receive a frame coming from another bridge member interface
- receive broadcast/multicast frames via all bridge member interfaces,
which is required to receive IPv6 multicast packets destined to a
multicast group belonging to a bridge member interface that is different
from a packet arrival interface
roy@ helped testing of the fix, thanks!
To generate a diff of this commit:
cvs rdiff -u -r1.99 -r1.100 src/sys/net/if_bridge.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->feedback
State-Changed-By: ozaki-r@NetBSD.org
State-Changed-When: Thu, 23 Jul 2015 11:10:57 +0000
State-Changed-Why:
Fix committed to -current. Could you try -current?
From: "Ryota Ozaki" <ozaki-r@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/48104 CVS commit: src/tests/net/if_bridge
Date: Thu, 23 Jul 2015 11:05:34 +0000
Module Name: src
Committed By: ozaki-r
Date: Thu Jul 23 11:05:34 UTC 2015
Modified Files:
src/tests/net/if_bridge: t_bridge.sh
Log Message:
Reflect a fix for bridge
Due to PR 48104, some tests of ping/ping6 were failed but the tests now
should be successful. So reverse atf_check.
Bonus: the fix for PR 48104 also fixes another uknown failure.
To generate a diff of this commit:
cvs rdiff -u -r1.9 -r1.10 src/tests/net/if_bridge/t_bridge.sh
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: feedback->closed
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Sun, 01 May 2016 05:54:19 +0000
State-Changed-Why:
feedback timeout
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home