lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 15 Oct 2015 04:52:50 +0200
From:	Andrew Lunn <andrew@...n.ch>
To:	Vivien Didelot <vivien.didelot@...oirfairelinux.com>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	kernel@...oirfairelinux.com,
	"David S. Miller" <davem@...emloft.net>,
	Guenter Roeck <linux@...ck-us.net>,
	Florian Fainelli <f.fainelli@...il.com>,
	Neil Armstrong <narmstrong@...libre.com>
Subject: Re: [PATCH net-next 0/4] net: dsa: mv88e6xxx: fix hardware bridging

On Wed, Oct 14, 2015 at 09:28:55PM -0400, Vivien Didelot wrote:
> On Oct. Thursday 15 (42) 12:46 AM, Andrew Lunn wrote:
> > On Sun, Oct 11, 2015 at 06:08:34PM -0400, Vivien Didelot wrote:
> > > DSA and its drivers currently hook the NETDEV_CHANGEUPPER net_device event in
> > > order to configure the VLAN map of every port.
> > > 
> > > This VLAN map is a feature of these switch chips to hardcode and restrict which
> > > output ports a given input port can egress frames to.
> > > 
> > > A Linux bridge is a simple untagged VLAN propagated by the bridge code itself.
> > > With a proper 802.1Q support, a driver does not need this hook anymore, and
> > > will simply program the related VLAN object.
> > > 
> > > This patchset improves the hardware bridging code in the mv88e6xxx driver with
> > > a strict 802.1Q mode.
> > 
> > Hi Vivien
> > 
> > I just tested this as part of net-next/master, and found a problem....
> > 
> > If i do:
> > 
> > ip link set lan0 up
> > ip addr add 192.168.10.2/24 dev lan0
> > 
> > It will not ping. Looking in sys/kernel/debug/dsa0/stats i see
> > broadcast packets, probably ARP, being received at the port.
> > But they are not being forwarded out the CPU port.
> > 
> > If however i do
> > 
> > brctl addbr br0
> > brctl addif br0 lan0
> > ip addr add 192.168.10.2/24 dev br0
> > ip link set br0 up
> > 
> > i can ping.
> > 
> > So it looks like we are too restrictive by default. You should be able
> > to use interfaces as they are, without a bridge.
> 
> Correct, if the ports are not in a VLAN by default, they cannot talk.

Hi Vivien 

This is a regression. Ports of the switch should work like normal
Linux interfaces. And up until now, they did. This patchset changed
that.

As Florian pointed out, these interfaces are separated from each
other. So you need something like a bridge per port by default, which
then gets removed and replaced when a port is added to a Linux bridge.

We also need to take care of VLANs. When the port is not a member of a
linux bridge, i expect all VLAN tagged frames to be received, as well
as untagged frames. This is normal Linux behaviour. But i never got
around to testing this with DSA.

       Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ