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 09:16:11 -0700
From:   Florian Fainelli <>
To:     DENG Qingfang <>
Cc:     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 5/13/2020 8:56 AM, DENG Qingfang wrote:
> Hi Florian
> On Wed, May 13, 2020 at 11:46 PM 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.
> I forgot to mention that this is ONLY for vlan_filtering=1
> `bridge vlan` simply won't do anything if VLAN filtering is disabled.

It depends now as of this patch:

and sorry I misunderstood your use case, you are changing the default
VLAN for the CPU port through the bridge's master device and you still
want it to be in the same VLAN membership as sw0p0, so yes that looks

Powered by blists - more mailing lists