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:   Tue, 20 Aug 2019 04:04:43 -0400
From:   Vivien Didelot <vivien.didelot@...il.com>
To:     Vladimir Oltean <olteanv@...il.com>
Cc:     f.fainelli@...il.com, andrew@...n.ch, idosch@...sch.org,
        roopa@...ulusnetworks.com, nikolay@...ulusnetworks.com,
        davem@...emloft.net, netdev@...r.kernel.org,
        Vladimir Oltean <olteanv@...il.com>
Subject: Re: [PATCH net-next 0/6] Dynamic toggling of vlan_filtering for
 SJA1105 DSA

On Tue, 20 Aug 2019 02:59:56 +0300, Vladimir Oltean <olteanv@...il.com> wrote:
> This patchset addresses a few limitations in DSA and the bridge core
> that made it impossible for this sequence of commands to work:
> 
>   ip link add name br0 type bridge
>   ip link set dev swp2 master br0
>   echo 1 > /sys/class/net/br0/bridge/vlan_filtering
> 
> Only this sequence was previously working:
> 
>   ip link add name br0 type bridge vlan_filtering 1
>   ip link set dev swp2 master br0

This is not quite true, these sequences of commands do "work". What I see
though is that with the first sequence, the PVID 1 won't be programmed in
the hardware. But the second sequence does program the hardware.

But following bridge members will be correctly programmed with the VLAN
though. The sequence below programs the hardware with VLAN 1 for swp3 as
well as CPU and DSA ports, but not for swp2:

    ip link add name br0 type bridge
    ip link set dev swp2 master br0
    echo 1 > /sys/class/net/br0/bridge/vlan_filtering
    ip link set dev swp3 master br0

This is unfortunately also true for any 802.1Q VLANs. For example, only VID
43 is programmed with the following sequence, but not VID 1 and VID 42:

    ip link add name br0 type bridge
    ip link set dev swp2 master br0
    bridge vlan add dev swp2 vid 42
    echo 1 > /sys/class/net/br0/bridge/vlan_filtering
    bridge vlan add dev swp2 vid 43

So I understand that because VLANs are not propagated by DSA to the hardware
when VLAN filtering is disabled, a port may not be programmed with its
bridge's default PVID, and this is causing a problem for tag_8021q.

Please reword so that we understand better what is the issue being fixed here.

> 
> On SJA1105, the situation is further complicated by the fact that
> toggling vlan_filtering is causing a switch reset. However, the hardware
> state restoration logic is already there in the driver. It is a matter
> of the layers above which need a few fixups.
> 
> Also see this discussion thread:
> https://www.spinics.net/lists/netdev/msg581042.html
> 
> Patch 1/6 is not functionally related but also related to dsa_8021q
> handling of VLANs and this is a good opportunity to bring up the subject
> for discussion.

So please send 1/6 as a separate patch and bring up the discussion there.


Thanks,

	Vivien

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ