linux-kernel - Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26

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]

Message-ID: <6c93d27e-66dc-02a9-f8f9-f349f27dfec6@gmail.com>
Date:   Sun, 27 May 2018 13:35:27 -0700
From:   Florian Fainelli <f.fainelli@...il.com>
To:     Gerhard Wiesinger <lists@...singer.com>,
        Andrew Lunn <andrew@...n.ch>, initramfs@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org
Subject: Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26 -
 systemd-networkd problem

Le 05/27/18 à 12:18, Gerhard Wiesinger a écrit :
> On 27.05.2018 21:01, Gerhard Wiesinger wrote:
>> On 24.05.2018 08:22, Gerhard Wiesinger wrote:
>>> On 24.05.2018 07:29, Gerhard Wiesinger wrote:
>>>> After some analysis with Florian (thnx) we found out that the
>>>> current implementation is broken:
>>>>
>>>> https://patchwork.ozlabs.org/patch/836538/
>>>> https://github.com/torvalds/linux/commit/c499696e7901bda18385ac723b7bd27c3a4af624#diff-a2b6f8d89e18de600e873ac3ac43fa1d
>>>>
>>>>
>>>> Florians comment:
>>>>
>>>> c499696e7901bda18385ac723b7bd27c3a4af624 ("net: dsa: b53: Stop using
>>>> dev->cpu_port incorrectly") since it would result in no longer setting
>>>> the CPU port as tagged for a specific VLAN. Easiest way for you right
>>>> now is to just revert it, but this needs some more thoughts for a
>>>> proper
>>>> upstream change. I will think about it some more.
>>>
>>> Can confirm 4.14.18-200.fc26.armv7hl works, 4.15.x should be broken.
>>>
>>> # Kernel 4.14.x ok
>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/net/dsa/b53?h=v4.14.43
>>>
>>> # Kernel 4.15.x should be NOT ok
>>> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/log/drivers/net/dsa/b53?h=v4.15.18
>>>
>>
>>
> 
> Forgot to mention: What's also strange is that the VLAN ID is very high:
> 
> # 4.14.18-300.fc27.armv7hl, iproute-4.15.0-1.fc28.armv7hl
> ip -d link show eth0.101 | grep "vlan protocol"
>     vlan protocol 802.1Q id 3069279796 <REORDER_HDR>
> ip -d link show eth0.102 | grep "vlan protocol"
>     vlan protocol 802.1Q id 3068673588 <REORDER_HDR>
> 
> On older kernels this looks ok: 4.12.8-200.fc25.armv7hl,
> iproute-4.11.0-1.fc25.armv7hl:
>  ip -d link show eth0.101 | grep "vlan protocol"
>     vlan protocol 802.1Q id 101 <REORDER_HDR>
> ip -d link show eth0.102 | grep "vlan protocol"
>     vlan protocol 802.1Q id 102 <REORDER_HDR>
> 
> Ideas?

That is quite likely a kernel/iproute2 issue, if you configured the
switch through bridge vlan to have the ports in VLAN 101 and VLAN 102
and you do indeed see frames entering eth0 with these VLAN IDs, then
clearly the bridge -> switchdev -> dsa -> b53 part is working just fine
and what you are seeing is some for of kernel header/netlink
incompatibility.
-- 
Florian