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  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:   Wed, 13 May 2020 19:17:46 +0300
From:   Vladimir Oltean <>
To:     Florian Fainelli <>
Cc:     DENG Qingfang <>, netdev <>,
        Sean Wang <>,
        Andrew Lunn <>,
        Vivien Didelot <>,
        "David S . Miller" <>,
        "moderated list:ARM/Mediatek SoC support" 
        Russell King <>,
        Matthias Brugger <>,
        René van Dorst <>,
        Tom James <>,
        Stijn Segers <>,, Szabolcs Hubai <>,
        Paul Fertser <>
Subject: Re: [PATCH net-next] net: dsa: mt7530: set CPU port to fallback mode

On Wed, 13 May 2020 at 18:49, Florian Fainelli <> wrote:
> On 5/13/2020 8:37 AM, DENG Qingfang wrote:
> > Currently, setting a bridge's self PVID to other value and deleting
> > the default VID 1 renders untagged ports of that VLAN unable to talk to
> > the CPU port:
> >
> >       bridge vlan add dev br0 vid 2 pvid untagged self
> >       bridge vlan del dev br0 vid 1 self
> >       bridge vlan add dev sw0p0 vid 2 pvid untagged
> >       bridge vlan del dev sw0p0 vid 1
> >       # br0 cannot send untagged frames out of sw0p0 anymore
> >
> > That is because the CPU port is set to security mode and its PVID is
> > still 1, and untagged frames are dropped due to VLAN member violation.
> >
> > Set the CPU port to fallback mode so untagged frames can pass through.
> How about if the bridge has vlan_filtering=1? The use case you present
> seems to be valid to me, that is, you may create a VLAN just for the
> user ports and not have the CPU port be part of it at all.

What Qingfang is doing is in effect (but not by intention) removing
the front panel port sw0p0 from the membership list of the CPU port's
pvid. What you seem to be thinking of (VLAN of which the CPU is not a
member of) does not seem to be supported in DSA at the moment.

As a fix, there's nothing wrong with the patch actually, I don't even
know how it would work otherwise. DSA doesn't change the pvid of the
CPU port when the pvid of a slave changes, because 4 slave ports could
have 4 different pvids and the CPU port pvid would keep changing.
Fallback mode should only apply on ingress from CPU, so there's no
danger really.


Powered by blists - more mailing lists