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:   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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ