NetBSD Problem Report #18035

Received: (qmail 25241 invoked by uid 605); 22 Aug 2002 09:53:40 -0000
Message-Id: <200208220953.g7M9ral01101@night-porter.duskware.de>
Date: Thu, 22 Aug 2002 11:53:36 +0200 (MEST)
From: Martin Husemann <martin@duskware.de>
Sender: gnats-bugs-owner@netbsd.org
Reply-To: martin@duskware.de
To: gnats-bugs@gnats.netbsd.org
Subject: bridge does not work with three interfaces
X-Send-Pr-Version: 3.95

>Number:         18035
>Category:       kern
>Synopsis:       bridge does not work with !IFF_SIMPLEX interfaces
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Aug 22 09:54:00 +0000 2002
>Closed-Date:    
>Last-Modified:  Fri Aug 15 15:35:00 +0000 2014
>Originator:     Martin Husemann
>Release:        NetBSD 1.6F
>Organization:
>Environment:
System: NetBSD night-porter.duskware.de 1.6F NetBSD 1.6F (PORTER) #2: Thu Aug 22 08:03:57 MEST 2002 martin@night-porter.duskware.de:/usr/src/sys/arch/i386/compile/PORTER i386
Architecture: i386
Machine: i386
>Description:

I use a SparcLX with quad fast ethernet card (4 x hme) as router for my
home network. Recently I ran out of switch ports, so I thought I'd make use
of the hme1 - hme3 upto now unused on that machine.

Via a crossover cable I connected one machine each to hme1 and hme2. I 
verified this connection works.

I then tried to bridge hme0, hme1 and hme2 together. When I ran into trouble
(see below) I thought this would be caused by all hmes having the same
ethernet address, so I hacked that - and it turns out it is not related.

So my config now is:

hme0: flags=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        address: 08:00:20:19:54:5f
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
        inet 192.168.150.10 netmask 0xffffff00 broadcast 192.168.150.255
hme1: flags=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        address: 08:00:20:19:54:60
        media: Ethernet autoselect (100baseTX full-duplex)
        status: active
hme2: flags=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
        address: 08:00:20:19:54:61
        media: Ethernet autoselect (10baseT)
        status: active
bridge0: flags=41<UP,RUNNING> mtu 1500

brconfig -a shows the problem:
bridge0: flags=41<UP,RUNNING>
        Configuration:
                priority 32768 hellotime 2 fwddelay 15 maxage 20
        Interfaces:
                hme2 flags=3<LEARNING,DISCOVER>
                        port 5 priority 128
                hme1 flags=3<LEARNING,DISCOVER>
                        port 4 priority 128
                hme0 flags=3<LEARNING,DISCOVER>
                        port 3 priority 128
        Address cache (max cache: 100, timeout: 1200):
                08:00:2b:81:62:5e hme2 776 flags=0<>
                08:00:20:99:fc:91 hme2 623 flags=0<>
                00:00:c0:87:5f:f2 hme0 599 flags=0<>
                00:c0:ee:51:6c:4d hme2 590 flags=0<>
                00:e0:29:09:b0:e7 hme2 590 flags=0<>

Note there is only a single peer connected to hme2 - the cache entries are
bogus. And the bridge does not work at all (i.e. I can't ping accross the
bridge, sometimes pings from the bridge to one side work, but not always -
this may be related to arp timeouts)

Using only hme0 and hme1 works (this is after "brconfig bridge0 delete hme2 flush"
and some network activity):

bridge0: flags=41<UP,RUNNING>
        Configuration:
                priority 32768 hellotime 2 fwddelay 15 maxage 20
        Interfaces:
                hme1 flags=3<LEARNING,DISCOVER>
                        port 4 priority 128
                hme0 flags=3<LEARNING,DISCOVER>
                        port 3 priority 128
        Address cache (max cache: 100, timeout: 1200):
                00:c0:ee:51:6c:4d hme1 1179 flags=0<>
                00:e0:29:09:b0:e7 hme0 1176 flags=0<>
                00:00:c0:87:5f:f2 hme0 1170 flags=0<>
                08:00:20:99:fc:91 hme0 1169 flags=0<>

And now the bridge works just fine, i.e. the peer behind hme1 is reachable 
from all hosts behind hme0.

>How-To-Repeat:

s/a

>Fix:
n/a
>Release-Note:
>Audit-Trail:

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@gnats.netbsd.org
Cc:  
Subject: Re: kern/18035: bridge does not work with three interfaces
Date: Sat, 24 Aug 2002 21:07:39 +0200

 Further analysis shows: it's not three vs. two interface that makes the
 bridge fail for me, but specifically the hme driver when using 10baseT
 media:

 See above for ifconfig output:
 > hme0: flags=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
 >         media: Ethernet autoselect (100baseTX full-duplex)
 > hme1: flags=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
 >         media: Ethernet autoselect (100baseTX full-duplex)
 > hme2: flags=8b63<UP,BROADCAST,NOTRAILERS,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500
 >         media: Ethernet autoselect (10baseT)

 Adding hme2 in 100baseTX mode does not make the bridge fail!

 I added debug code and it turns out the "cach corruption" occurs in function
 bridge_rtupdate, after looking up the ethernet address with bridge_rtnode_lookup
 there is an unconditional assignment

    brt->brt_ifp = dst_if;

 at line 1493 of syssrc/net/if_bridge.c. In my case brt->brt_ifp points to hme0
 and dst_if points to hme2.

 So it seems the hme chip (or driver?) (despite having IFF_SIMPLEX set) seems
 to listen to its own transmissions, but only in 10baseT mode.

 There have been problems reported with hme interfaces and IPv6 neighbourhood
 duplicate address detection which pointed to the same effect. Should the
 hme driver just remove IFF_SIMPLEX when running with 10baseT media?

 Martin

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.ORG
Cc:  
Subject: Re: kern/18035 bridge does not work with !IFF_SIMPLEX interfaces
Date: Thu, 9 Jan 2003 22:54:27 +0100

 For the record, here is how the story continued:

 The hme chip seems to be SIMPLEX only in full-duplex mode. This solved the
 problem for me, since I was able to force 10baseT full-duplex on the one
 hme running not at 100baseTX.

 I have changed the hme driver to remove IFF_SIMPLEX in half-duplex modes.

 The main problem is still there: if_bridge.c does not even try to work with
 !SIMPLEX devices. Fixing that would ... not be trivial, it seems.

 I'd suggest to suspend this PR (or move it to "analyzed" and assign it to
 a volunteer prepared to fix the bridge code).

 Martin
From: der Mouse <mouse@Rodents-Montreal.ORG>
To: tech-net@NetBSD.org
Cc: 
Subject: Re: kern/18035 IFF_SIMPLEX vs bridge(4)
Date: Wed, 13 Aug 2008 04:59:40 -0400 (EDT)

 >> This causes the bridge to end up with the sending MAC address learnt
 >> on vr0 rather than the interface it really is on.
 > If anyone fixes it, please close PR kern/18035 (which is slightly
 > unrelated, but still open due to this bug).

 Oho!  Yes, vr0 is running at "Ethernet autoselect (10baseT)", so it is
 probably more generic than just hme.  I should see if I can find
 something to speed-adapt so vr0 can run at 100 even though the device
 it's connected to insists on 10, to see if that "fixes it".

 I'm sending a bcc of this to the PR.  To anyone reading this via the
 PR, my problem was very similar - a bridge learning a MAC on the wrong
 interface.  My tests indicate that it is related to broadcast packets,
 which is hardly surprising.  (Maybe "broadcast or multicast"; I didn't
 even try to test multicast.)

 I think "bridge doesn't learn MACs from broadcast packets" is a
 reasonable approximation to a fix.  I can justify doing this on work
 time, since the case that's breaking for me is a work setup, which
 means it's likely going to happen sometime Thursday 2008-08-14.

 Any thoughts on whether it would be better to do "bridge doesn't learn
 MACs from broadcast or multicast packets"?

 /~\ The ASCII				der Mouse
 \ / Ribbon Campaign
  X  Against HTML		mouse@rodents-montreal.org
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From: der Mouse <mouse@Rodents-Montreal.ORG>
To: tech-net@netbsd.org
Cc: 
Subject: Re: kern/18035 IFF_SIMPLEX vs bridge(4)
Date: Fri, 15 Aug 2008 00:03:26 -0400 (EDT)

 > I think "bridge doesn't learn MACs from broadcast packets" is a
 > reasonable approximation to a fix.

 It is.  I tried that and, while I still see the ARP request duplicated
 when tcpdumping vr0, I no longer see bridge1 learning MAC addresses on
 the wrong interface.

 The patch I got this effect with is almost ludicrously simple:

 --- /dev/fd/4	Tue Dec  9 16:18:08 2003
 +++ /dev/fd/5	Tue Dec  9 16:18:08 2003
 @@ -1360,10 +1360,12 @@
  	/*
  	 * If the interface is learning, and the source
  	 * address is valid and not multicast, record
 -	 * the address.
 +	 * the address.  But don't do this if the destination
 +	 * is broadcast; such packets are looped back too often.
  	 */
  	if ((bif->bif_flags & IFBIF_LEARNING) != 0 &&
  	    ETHER_IS_MULTICAST(eh->ether_shost) == 0 &&
 +	    memcmp(etherbroadcastaddr,eh->ether_dhost,sizeof(etherbroadcastaddr)) &&
  	    (eh->ether_shost[0] == 0 &&
  	     eh->ether_shost[1] == 0 &&
  	     eh->ether_shost[2] == 0 &&

 I'm sending a bcc of this mail, too, to the PR, so's to ensure the
 patch is there for anyone who wants it.  (The above is relative to
 stock 4.0 source, if_bridge.c,v 1.46.)

 /~\ The ASCII				der Mouse
 \ / Ribbon Campaign
  X  Against HTML		mouse@rodents-montreal.org
 / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

From: Christoph Badura <bad@bsd.de>
To: tech-net@netbsd.org
Cc: der Mouse <mouse@Rodents-Montreal.ORG>
Subject: Re: kern/18035 IFF_SIMPLEX vs bridge(4)
Date: Tue, 26 Aug 2008 23:16:05 +0200

 On Fri, Aug 15, 2008 at 12:03:26AM -0400, der Mouse wrote:
 > > I think "bridge doesn't learn MACs from broadcast packets" is a
 > > reasonable approximation to a fix.

 > It is.  I tried that and, while I still see the ARP request duplicated
 > when tcpdumping vr0, I no longer see bridge1 learning MAC addresses on
 > the wrong interface.
 > 
 > The patch I got this effect with is almost ludicrously simple:
 > 
 > @@ -1360,10 +1360,12 @@
 >  	/*
 >  	 * If the interface is learning, and the source
 >  	 * address is valid and not multicast, record
 > -	 * the address.
 > +	 * the address.  But don't do this if the destination
 > +	 * is broadcast; such packets are looped back too often.
 >  	 */
 >  	if ((bif->bif_flags & IFBIF_LEARNING) != 0 &&
 >  	    ETHER_IS_MULTICAST(eh->ether_shost) == 0 &&
 > +	    memcmp(etherbroadcastaddr,eh->ether_dhost,sizeof(etherbroadcastaddr)) &&
 >  	    (eh->ether_shost[0] == 0 &&
 >  	     eh->ether_shost[1] == 0 &&
 >  	     eh->ether_shost[2] == 0 &&

 You should be using ETHER_IS_MULTICAST(eh->ether_dhost) instead of memcmp().
 That is the standard way.

 I'm wondering whether the 's' in ether_shost in the original code is a typo.
 's' and 'd' are next to each other on US keyboards.
 AFAIK no protocols send ethernet packets with a multicast source address.
 And if the ETHER_IS_MULTICAST() check is supposed to ensure that no multicast
 addresses are put into the bridge routing table, the check should better be
 moved inside bridge_rtupdate().

 --chris

From: "Ryota Ozaki" <ozaki-r@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/18035 CVS commit: src/sys/net
Date: Fri, 15 Aug 2014 15:32:24 +0000

 Module Name:	src
 Committed By:	ozaki-r
 Date:		Fri Aug 15 15:32:24 UTC 2014

 Modified Files:
 	src/sys/net: if_bridge.c

 Log Message:
 bridge: reject non-IFF_SIMPLEX interfaces

 bridge does not work with !IFF_SIMPLEX interfaces (PR/18035);
 the bug is not yet fixed. Until it gets fixed, we should
 reject non-IFF_SIMPLEX interfaces.

 Discussed with pooka@


 To generate a diff of this commit:
 cvs rdiff -u -r1.90 -r1.91 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.

>Unformatted:

Home	PR Database Search