Re: [PATCH net] net: dsa: mv88e6xxx: fix port VLAN maps
On 01/28/2016 08:18 PM, Andrew Lunn wrote:
> On Thu, Jan 28, 2016 at 04:54:37PM -0500, Vivien Didelot wrote:
>> Currently the port based VLAN maps should be configured to allow every
>> port to egress frames on all other ports, except themselves.
>>
>> The debugfs interface shows that they are misconfigured. For instance, a
>> 7-port switch has the following content in the related register 0x06:
>>
>> GLOBAL GLOBAL2 SERDES 0123456
>> ...
>> 6: 1fa41f0f 4 7f 7e 7d 7c 7b 7a 79
>> ...
>>
>> This means that port 3 is allowed to talk to port 2-6, but cannot talk
>> to ports 0 and 1. With this fix, port 3 can correctly talk to all ports
>> except 3 itself:
>>
>> GLOBAL GLOBAL2 SERDES 0123456
>> ...
>> 6: 1fa41f0f 4 7e 7d 7b 77 6f 5f 3f
>> ...
>>
>> Fixes: ede8098d0fef ("net: dsa: mv88e6xxx: bridges do not need an FID")
>> Reported-by: Kevin Smith
>> Signed-off-by: Vivien Didelot
> Reviewed-by: Andrew Lunn
Tested-by: Kevin Smith
Re: [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map control
Hi Vivien,
On 02/26/2016 12:16 PM, Vivien Didelot wrote:
> + /* allow CPU port or DSA link(s) to send frames to every port */
> + if (dsa_is_cpu_port(ds, port) || dsa_is_dsa_port(ds, port)) {
> + output_ports = mask;
> + } else {
Is this always correct? Are there situations where a CPU or neighboring
switch should not be allowed to access another port? (e.g. Figure 6 or 7
in the 88E6352 functional specification).
Thanks,
Kevin
Re: [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map control
Hi Vivien, Andrew, On 02/26/2016 03:37 PM, Vivien Didelot wrote: > Here, 5 is the CPU port and 6 is a DSA port. > > After joining ports 0, 1, 2 in the same bridge, we end up with: > > Port 0 1 2 3 4 5 6 >0 - * * - - * * >1 * - * - - * * >2 * * - - - * * >3 - - - - - * * >4 - - - - - * * >5 * * * * * - * >6 * * * * * * - The case I am concerned about is if the switch connected over DSA in this example has a WAN port on it, which can legitimately route to the CPU on port 5 but should not route to the LAN ports 0, 1, and 2. Does this VLAN allow direct communication between the WAN and LAN? Or is this prevented by DSA or some other mechanism? Thanks, Kevin
Re: [PATCH net-next 7/9] net: dsa: mv88e6xxx: restore VLANTable map control
Hi Andrew, On 02/26/2016 04:35 PM, Andrew Lunn wrote: > On Fri, Feb 26, 2016 at 10:12:28PM +0000, Kevin Smith wrote: >> Hi Vivien, Andrew, >> >> On 02/26/2016 03:37 PM, Vivien Didelot wrote: >>> Here, 5 is the CPU port and 6 is a DSA port. >>> >>> After joining ports 0, 1, 2 in the same bridge, we end up with: >>> >>> Port 0 1 2 3 4 5 6 >>> 0 - * * - - * * >>> 1 * - * - - * * >>> 2 * * - - - * * >>> 3 - - - - - * * >>> 4 - - - - - * * >>> 5 * * * * * - * >>> 6 * * * * * * - >> The case I am concerned about is if the switch connected over DSA in >> this example has a WAN port on it, which can legitimately route to the >> CPU on port 5 but should not route to the LAN ports 0, 1, and 2. Does >> this VLAN allow direct communication between the WAN and LAN? Or is >> this prevented by DSA or some other mechanism? > A typical WIFI access point with a connection to a cable modem. > > So in linux you have interfaces like > > lan0, lan1, lan2, lan3, wan0 > > DSA provides you these interface. And by default they are all > separated. There is no path between them. You can consider them as > being separate physical ethernet cards, just like all other interfaces > in linux. > > What you would typically do is: > > brctl addbr br0 > brctl addif br0 lan0 > brctl addif br0 lan1 > brctl addif br0 lan2 > brctl addif br0 lan3 > > to create a bridge between the lan ports. The linux kernel will then > push this bridge configuration down into the hardware, so the switch > can forward frames between these ports. > > The wan port is not part of the bridge, so there is no L2 path to the > WAN port. You need to do IP routing on the CPU. > > Linux takes the stance that switch ports interfaces should act just > like any other linux interface and you configure them in the normal > linux way. > > Andrew Thanks for the explanation. I am a bit befuddled by the combination of all the possible configurations of the switch and how they interact with Linux. :) I think I understand what is happening now. Kevin
[no subject]
unsubscribe
