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 02:37:46 +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 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