Re: loss of connectivity after enabling vlan_filtering

From: vtolkm@googlemail.com
To: netdev@vger.kernel.org
Cc: Andrew Lunn <andrew@lunn.ch>
Subject: Re: loss of connectivity after enabling vlan_filtering
Date: Sun, 30 Jun 2019 03:13:45 +0200	[thread overview]
Message-ID: <1696f8e8-6b83-32c1-9ee0-ca973d7fd70d@gmail.com> (raw)
In-Reply-To: <aa021a99-accd-75ac-47a4-2c11aa791d3c@gmail.com>

On 30/06/2019 02:37, vtolkm@gmail.com wrote:
> On 30/06/2019 01:23, vtolkm@gmail.com wrote:
>> On 30/06/2019 01:11, Andrew Lunn wrote:
>>> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vtolkm@googlemail.com wrote:
>>>> On 30/06/2019 00:49, Andrew Lunn wrote:
>>>>> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
>>>>>> * DSA MV88E6060
>>>>>> * iproute2 v.5.0.0-2.0
>>>>>> * OpenWRT 19.07 with kernel 4.14.131 armv7l
>>>>> The mv88e6060 driver is very simple. It has no support for VLANs. It
>>>>> does not even have support for offloading bridging between ports to
>>>>> the switch.
>>>>>
>>>>> The data sheet for this device is open. So if you want to hack on the
>>>>> driver, you could do.
>>>>>
>>>>> 	Andrew
>>>> Are you sure? That is a bit confusing after reading
>>>> https://lore.kernel.org/patchwork/patch/575746/
>>> Quoting that patch:
>>>
>>> 	This commit implements the switchdev operations to add, delete
>>> 	and dump VLANs for the Marvell 88E6352 and compatible switch
>>> 	chips.
>>>
>>> Vivien added support for the 6352. That uses the mv88e6xxx driver, not
>>> the mv88e6060. And by compatible switches, he meant those in the 6352
>>> family, so 6172 6176 6240 6352 and probably the 6171 6175 6350 6351.
>>>
>>> 	Andrew
>> A simple soul might infer that mv88e6xxx includes MV88E6060, at least
>> that happened to me apparently (being said simpleton).
>> That may as it be, and pardon my continued ignorance, how is it
>> explained then that a command as
>>
>> # bridge v a dev {bridge} self vid {n} untagged pvid
>>
>> reflects in
>>
>> # bridge v s
>> a/o
>> # bridge mo
>>
>> ?
>>
>> If the commands are not implemented one would expect them to fail in the
>> first place or not reflecting a change at all?
>>
>>
> As stated in the initial message - kernel conf
>
> CONFIG_NET_DSA_MV88E6060=y
> CONFIG_NET_DSA_MV88E6XXX=y
> CONFIG_NET_DSA_MV88E6XXX_GLOBAL2=y
>

Just figured that it is a  Marvell 88E6176-TFJ2. Thus that cannot be the
cause, also considering the that the commands are executing and changes
being reflected.

However, the loss of access to the node is a mystery.

Apparently the filter is doing its job as in isolating access to the
bridge if connecting though an enslaved device.
And yet the bridge is still fully accessible from other devices that or
not enslaved by that bridge. As if the filter is inverted.