[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2e3a12eb-64d7-94c1-f7a0-dc3910459aa4@gmail.com>
Date: Wed, 13 May 2020 09:16:11 -0700
From: Florian Fainelli <f.fainelli@...il.com>
To: DENG Qingfang <dqfext@...il.com>
Cc: netdev <netdev@...r.kernel.org>,
Sean Wang <sean.wang@...iatek.com>,
Andrew Lunn <andrew@...n.ch>,
Vivien Didelot <vivien.didelot@...il.com>,
"David S . Miller" <davem@...emloft.net>,
"moderated list:ARM/Mediatek SoC support"
<linux-mediatek@...ts.infradead.org>,
Russell King <linux@...linux.org.uk>,
Matthias Brugger <matthias.bgg@...il.com>,
René van Dorst <opensource@...rst.com>,
Tom James <tj17@...com>,
Stijn Segers <foss@...atilesystems.org>,
riddlariddla@...mail.com, Szabolcs Hubai <szab.hu@...il.com>,
Paul Fertser <fercerpav@...il.com>
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 <f.fainelli@...il.com> 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:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=54a0ed0df49609f4e3f098f8943e38e389dc2e15
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
correct.
--
Florian
Powered by blists - more mailing lists