netdev - Re: loss of connectivity after enabling vlan

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:   Sun, 30 Jun 2019 09:46:00 +0200
From:   vtolkm@...glemail.com
To:     netdev@...r.kernel.org
Cc:     Andrew Lunn <andrew@...n.ch>
Subject: Re: loss of connectivity after enabling vlan_filtering


On 30/06/2019 03:13, vtolkm@...il.com wrote:
> On 30/06/2019 02:37, vtolkm@...il.com wrote:
>> On 30/06/2019 01:23, vtolkm@...il.com wrote:
>>> On 30/06/2019 01:11, Andrew Lunn wrote:
>>>> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vtolkm@...glemail.com wrote:
>>>>> On 30/06/2019 00:49, Andrew Lunn wrote:
>>>>>> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@...glemail.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.
>

The node's kernel log is showing during boot time repeated entries:

mv88e6085 f1072004.mdio-mii:10 lan{n}: configuring for phy/gmii link mode
mv88e6085 f1072004.mdio-mii:10: p3: hw VLAN 1 already used by br-{n}

Could there be a correlation with the described issue?

Is there way to debug the issue otherwise?