B53 DSA switch problem on Banana Pi-R1 on Fedora 26

B53 DSA switch problem on Banana Pi-R1 on Fedora 26

[Gerhard Wiesinger]

Hello,

I'm trying to get B53 DSA switch working on the Banana Pi-R1 on Fedora 
26 to run (I will upgrade to Fedora 27 and Fedora 28 when networking 
works again). Previously the switch was configured with swconfig without 
any problems.

Kernel: 4.16.7-100.fc26.armv7hl

b53_common: found switch: BCM53125, rev 4

I see all interfaces: lan1 to lan4 and wan.

i get the following error messages:

# master and self, same results

bridge vlan add dev lan1 vid 101 pvid untagged self
RTNETLINK answers: Operation not supported
bridge vlan add dev lan2 vid 101 pvid untagged self
RTNETLINK answers: Operation not supported
bridge vlan add dev lan3 vid 101 pvid untagged self
RTNETLINK answers: Operation not supported
bridge vlan add dev lan4 vid 101 pvid untagged self
RTNETLINK answers: Operation not supported

# No quite sure here regarding CPU interface and VLAN, because this 
changed with some patches, also from dsa.txt

bridge vlan add dev eth0 vid 101 self
RTNETLINK answers: Operation not supported

Planned network structure will be as with 4.7.x kernels:

br0 <=> eth0.101 <=> eth0 (vlan 101 tagged) <=> lan 1-lan4 (vlan 101 
untagged pvid)

br1 <=> eth0.102 <=> eth0 (vlan 102 tagged) <=> wan (vlan 102 untagged pvid)

I think the rest of the config is clear after some research now, but I 
provide details if that one worked well.

If necessary I can provide full commands & logs and further details.

Thank you.

Any ideas?

Ciao,

Gerhard

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

[Florian Fainelli]

Hi,

On 05/22/2018 12:11 PM, Gerhard Wiesinger wrote:
> Hello,
> 
> I'm trying to get B53 DSA switch working on the Banana Pi-R1 on Fedora
> 26 to run (I will upgrade to Fedora 27 and Fedora 28 when networking
> works again). Previously the switch was configured with swconfig without
> any problems.
> 
> Kernel: 4.16.7-100.fc26.armv7hl
> 
> b53_common: found switch: BCM53125, rev 4
> 
> I see all interfaces: lan1 to lan4 and wan.
> 
> i get the following error messages:
> 
> # master and self, same results
> 
> bridge vlan add dev lan1 vid 101 pvid untagged self
> RTNETLINK answers: Operation not supported
> bridge vlan add dev lan2 vid 101 pvid untagged self
> RTNETLINK answers: Operation not supported
> bridge vlan add dev lan3 vid 101 pvid untagged self
> RTNETLINK answers: Operation not supported
> bridge vlan add dev lan4 vid 101 pvid untagged self
> RTNETLINK answers: Operation not supported
> 
> # No quite sure here regarding CPU interface and VLAN, because this
> changed with some patches, also from dsa.txt
> 
> bridge vlan add dev eth0 vid 101 self
> RTNETLINK answers: Operation not supported

That won't work, eth0 is the master DSA device, if you need to create a
VLAN on top it would be with vconfig and/or ip link

> 
> Planned network structure will be as with 4.7.x kernels:
> 
> br0 <=> eth0.101 <=> eth0 (vlan 101 tagged) <=> lan 1-lan4 (vlan 101
> untagged pvid)
> 
> br1 <=> eth0.102 <=> eth0 (vlan 102 tagged) <=> wan (vlan 102 untagged
> pvid)
> 
> I think the rest of the config is clear after some research now, but I
> provide details if that one worked well.
> 
> If necessary I can provide full commands & logs and further details.
> 
> Thank you.
> 
> Any ideas?

Do you have CONFIG_BRIDGE_VLAN_FILTERING=y enabled in your kernel?

> 
> Ciao,
> 
> Gerhard
> 
> 


-- 
Florian

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

[Andrew Lunn]

> Planned network structure will be as with 4.7.x kernels:
> 
> br0 <=> eth0.101 <=> eth0 (vlan 101 tagged) <=> lan 1-lan4 (vlan 101
> untagged pvid)
> 
> br1 <=> eth0.102 <=> eth0 (vlan 102 tagged) <=> wan (vlan 102 untagged pvid)

Do you even need these vlans?

Are you doing this for port separation? To keep lan1-4 traffic
separate from wan? DSA does that by default, no vlan needed.

So you can just do

ip link add name br0 type bridge
ip link set dev br0 up
ip link set dev lan1 master br0
ip link set dev lan2 master br0
ip link set dev lan3 master br0
ip link set dev lan4 master br0

and use interface wan directly, no bridge needed.

    Andrew

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

[Florian Fainelli]

On 05/22/2018 01:16 PM, Andrew Lunn wrote:
>> Planned network structure will be as with 4.7.x kernels:
>>
>> br0 <=> eth0.101 <=> eth0 (vlan 101 tagged) <=> lan 1-lan4 (vlan 101
>> untagged pvid)
>>
>> br1 <=> eth0.102 <=> eth0 (vlan 102 tagged) <=> wan (vlan 102 untagged pvid)
> 
> Do you even need these vlans?

Yes, remember, b53 does not currently turn on Broadcom tags, so the only
way to segregate traffic is to have VLANs for that.

> 
> Are you doing this for port separation? To keep lan1-4 traffic
> separate from wan? DSA does that by default, no vlan needed.
> 
> So you can just do
> 
> ip link add name br0 type bridge
> ip link set dev br0 up
> ip link set dev lan1 master br0
> ip link set dev lan2 master br0
> ip link set dev lan3 master br0
> ip link set dev lan4 master br0
> 
> and use interface wan directly, no bridge needed.

That would work once Broadcom tags are turned on which requires turning
on managed mode, which requires work that I have not been able to get
done :)
-- 
Florian

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

[Andrew Lunn]

On Tue, May 22, 2018 at 01:42:40PM -0700, Florian Fainelli wrote:
> On 05/22/2018 01:16 PM, Andrew Lunn wrote:
> >> Planned network structure will be as with 4.7.x kernels:
> >>
> >> br0 <=> eth0.101 <=> eth0 (vlan 101 tagged) <=> lan 1-lan4 (vlan 101
> >> untagged pvid)
> >>
> >> br1 <=> eth0.102 <=> eth0 (vlan 102 tagged) <=> wan (vlan 102 untagged pvid)
> > 
> > Do you even need these vlans?
> 
> Yes, remember, b53 does not currently turn on Broadcom tags, so the only
> way to segregate traffic is to have VLANs for that.

Ah, i didn't remember that.

    Andrew

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

[Gerhard Wiesinger]

On 22.05.2018 22:42, Florian Fainelli wrote:
> On 05/22/2018 01:16 PM, Andrew Lunn wrote:
>>> Planned network structure will be as with 4.7.x kernels:
>>>
>>> br0 <=> eth0.101 <=> eth0 (vlan 101 tagged) <=> lan 1-lan4 (vlan 101
>>> untagged pvid)
>>>
>>> br1 <=> eth0.102 <=> eth0 (vlan 102 tagged) <=> wan (vlan 102 untagged pvid)
>> Do you even need these vlans?
> Yes, remember, b53 does not currently turn on Broadcom tags, so the only
> way to segregate traffic is to have VLANs for that.
>
>> Are you doing this for port separation? To keep lan1-4 traffic
>> separate from wan? DSA does that by default, no vlan needed.
>>
>> So you can just do
>>
>> ip link add name br0 type bridge
>> ip link set dev br0 up
>> ip link set dev lan1 master br0
>> ip link set dev lan2 master br0
>> ip link set dev lan3 master br0
>> ip link set dev lan4 master br0
>>
>> and use interface wan directly, no bridge needed.
> That would work once Broadcom tags are turned on which requires turning
> on managed mode, which requires work that I have not been able to get
> done :)

Setup with swconfig:

#!/usr/bin/bash


INTERFACE=eth0

# Delete all IP addresses and get link up
ip addr flush dev ${INTERFACE}
ip link set ${INTERFACE} up

# Lamobo R1 aka BPi R1 Routerboard
#
# Speaker | LAN1 | LAN2 | LAN3 | LAN4 || LAN5 | HDMI
# SW-Port |  P2  |  P1  |  P0  |  P4  ||  P3  |
# VLAN    |  11  |  12  |  13  |  14  ||ALL(t)|
#
# Switch-Port P8 - ALL(t) boards internal CPU Port

# Setup switch
swconfig dev ${INTERFACE} set reset 1
swconfig dev ${INTERFACE} set enable_vlan 1
swconfig dev ${INTERFACE} vlan 101 set ports '3 8t'
swconfig dev ${INTERFACE} vlan 102 set ports '4 0 1 2 8t'
swconfig dev ${INTERFACE} set apply 1

How to achieve this setup CURRENTLY with DSA?

And in the future (time plan)?

Thank you.

Ciao,
Gerhard

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

[Florian Fainelli]

On 05/22/2018 09:49 PM, Gerhard Wiesinger wrote:
> On 22.05.2018 22:42, Florian Fainelli wrote:
>> On 05/22/2018 01:16 PM, Andrew Lunn wrote:
>>>> Planned network structure will be as with 4.7.x kernels:
>>>>
>>>> br0 <=> eth0.101 <=> eth0 (vlan 101 tagged) <=> lan 1-lan4 (vlan 101
>>>> untagged pvid)
>>>>
>>>> br1 <=> eth0.102 <=> eth0 (vlan 102 tagged) <=> wan (vlan 102
>>>> untagged pvid)
>>> Do you even need these vlans?
>> Yes, remember, b53 does not currently turn on Broadcom tags, so the only
>> way to segregate traffic is to have VLANs for that.
>>
>>> Are you doing this for port separation? To keep lan1-4 traffic
>>> separate from wan? DSA does that by default, no vlan needed.
>>>
>>> So you can just do
>>>
>>> ip link add name br0 type bridge
>>> ip link set dev br0 up
>>> ip link set dev lan1 master br0
>>> ip link set dev lan2 master br0
>>> ip link set dev lan3 master br0
>>> ip link set dev lan4 master br0
>>>
>>> and use interface wan directly, no bridge needed.
>> That would work once Broadcom tags are turned on which requires turning
>> on managed mode, which requires work that I have not been able to get
>> done :)
> 
> Setup with swconfig:
> 
> #!/usr/bin/bash
> 
> 
> INTERFACE=eth0
> 
> # Delete all IP addresses and get link up
> ip addr flush dev ${INTERFACE}
> ip link set ${INTERFACE} up
> 
> # Lamobo R1 aka BPi R1 Routerboard
> #
> # Speaker | LAN1 | LAN2 | LAN3 | LAN4 || LAN5 | HDMI
> # SW-Port |  P2  |  P1  |  P0  |  P4  ||  P3  |
> # VLAN    |  11  |  12  |  13  |  14  ||ALL(t)|
> #
> # Switch-Port P8 - ALL(t) boards internal CPU Port
> 
> # Setup switch
> swconfig dev ${INTERFACE} set reset 1
> swconfig dev ${INTERFACE} set enable_vlan 1
> swconfig dev ${INTERFACE} vlan 101 set ports '3 8t'
> swconfig dev ${INTERFACE} vlan 102 set ports '4 0 1 2 8t'
> swconfig dev ${INTERFACE} set apply 1
> 
> How to achieve this setup CURRENTLY with DSA?

Your first email had the right programming sequence, but you did not
answer whether you have CONFIG_BRIDGE_VLAN_FILTERING enabled or not,
which is likely your problem.

> 
> And in the future (time plan)?

If you don't care about multicast then you can use those patches:

https://github.com/ffainelli/linux/commit/de055bf5f34e9806463ab2793e0852f5dfc380df

and you have to change the part of drivers/net/dsa/b53/b53_common.c that
returns DSA_TAG_PROTO_NONE for 53125:


diff --git a/drivers/net/dsa/b53/b53_common.c
b/drivers/net/dsa/b53/b53_common.c
index 9f561fe505cb..3c64f026a8ce 100644
--- a/drivers/net/dsa/b53/b53_common.c
+++ b/drivers/net/dsa/b53/b53_common.c
@@ -1557,7 +1557,7 @@ enum dsa_tag_protocol b53_get_tag_protocol(struct
dsa_switch *ds, int port)
         * mode to be turned on which means we need to specifically
manage ARL
         * misses on multicast addresses (TBD).
         */
-       if (is5325(dev) || is5365(dev) || is539x(dev) || is531x5(dev) ||
+       if (is5325(dev) || is5365(dev) || is539x(dev) ||
            !b53_can_enable_brcm_tags(ds, port))
                return DSA_TAG_PROTO_NONE;


That would bring Broadcom tags to the 53125 switch and you would be able
to use the configuration lines from Andrew in that case.
-- 
Florian

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

[Florian Fainelli]

On 05/23/2018 08:28 AM, Florian Fainelli wrote:
> 
> 
> On 05/22/2018 09:49 PM, Gerhard Wiesinger wrote:
>> On 22.05.2018 22:42, Florian Fainelli wrote:
>>> On 05/22/2018 01:16 PM, Andrew Lunn wrote:
>>>>> Planned network structure will be as with 4.7.x kernels:
>>>>>
>>>>> br0 <=> eth0.101 <=> eth0 (vlan 101 tagged) <=> lan 1-lan4 (vlan 101
>>>>> untagged pvid)
>>>>>
>>>>> br1 <=> eth0.102 <=> eth0 (vlan 102 tagged) <=> wan (vlan 102
>>>>> untagged pvid)
>>>> Do you even need these vlans?
>>> Yes, remember, b53 does not currently turn on Broadcom tags, so the only
>>> way to segregate traffic is to have VLANs for that.
>>>
>>>> Are you doing this for port separation? To keep lan1-4 traffic
>>>> separate from wan? DSA does that by default, no vlan needed.
>>>>
>>>> So you can just do
>>>>
>>>> ip link add name br0 type bridge
>>>> ip link set dev br0 up
>>>> ip link set dev lan1 master br0
>>>> ip link set dev lan2 master br0
>>>> ip link set dev lan3 master br0
>>>> ip link set dev lan4 master br0
>>>>
>>>> and use interface wan directly, no bridge needed.
>>> That would work once Broadcom tags are turned on which requires turning
>>> on managed mode, which requires work that I have not been able to get
>>> done :)
>>
>> Setup with swconfig:
>>
>> #!/usr/bin/bash
>>
>>
>> INTERFACE=eth0
>>
>> # Delete all IP addresses and get link up
>> ip addr flush dev ${INTERFACE}
>> ip link set ${INTERFACE} up
>>
>> # Lamobo R1 aka BPi R1 Routerboard
>> #
>> # Speaker | LAN1 | LAN2 | LAN3 | LAN4 || LAN5 | HDMI
>> # SW-Port |  P2  |  P1  |  P0  |  P4  ||  P3  |
>> # VLAN    |  11  |  12  |  13  |  14  ||ALL(t)|
>> #
>> # Switch-Port P8 - ALL(t) boards internal CPU Port
>>
>> # Setup switch
>> swconfig dev ${INTERFACE} set reset 1
>> swconfig dev ${INTERFACE} set enable_vlan 1
>> swconfig dev ${INTERFACE} vlan 101 set ports '3 8t'
>> swconfig dev ${INTERFACE} vlan 102 set ports '4 0 1 2 8t'
>> swconfig dev ${INTERFACE} set apply 1
>>
>> How to achieve this setup CURRENTLY with DSA?
> 
> Your first email had the right programming sequence, but you did not
> answer whether you have CONFIG_BRIDGE_VLAN_FILTERING enabled or not,
> which is likely your problem.

Here are some reference configurations that should work:

https://github.com/armbian/build/issues/511#issuecomment-320473246
-- 
Florian

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

[Gerhard Wiesinger]

On 23.05.2018 17:50, Florian Fainelli wrote:
>
> On 05/23/2018 08:28 AM, Florian Fainelli wrote:
>>
>> On 05/22/2018 09:49 PM, Gerhard Wiesinger wrote:
>>> On 22.05.2018 22:42, Florian Fainelli wrote:
>>>> On 05/22/2018 01:16 PM, Andrew Lunn wrote:
>>>>>> Planned network structure will be as with 4.7.x kernels:
>>>>>>
>>>>>> br0 <=> eth0.101 <=> eth0 (vlan 101 tagged) <=> lan 1-lan4 (vlan 101
>>>>>> untagged pvid)
>>>>>>
>>>>>> br1 <=> eth0.102 <=> eth0 (vlan 102 tagged) <=> wan (vlan 102
>>>>>> untagged pvid)
>>>>> Do you even need these vlans?
>>>> Yes, remember, b53 does not currently turn on Broadcom tags, so the only
>>>> way to segregate traffic is to have VLANs for that.
>>>>
>>>>> Are you doing this for port separation? To keep lan1-4 traffic
>>>>> separate from wan? DSA does that by default, no vlan needed.
>>>>>
>>>>> So you can just do
>>>>>
>>>>> ip link add name br0 type bridge
>>>>> ip link set dev br0 up
>>>>> ip link set dev lan1 master br0
>>>>> ip link set dev lan2 master br0
>>>>> ip link set dev lan3 master br0
>>>>> ip link set dev lan4 master br0
>>>>>
>>>>> and use interface wan directly, no bridge needed.
>>>> That would work once Broadcom tags are turned on which requires turning
>>>> on managed mode, which requires work that I have not been able to get
>>>> done :)
>>> Setup with swconfig:
>>>
>>> #!/usr/bin/bash
>>>
>>>
>>> INTERFACE=eth0
>>>
>>> # Delete all IP addresses and get link up
>>> ip addr flush dev ${INTERFACE}
>>> ip link set ${INTERFACE} up
>>>
>>> # Lamobo R1 aka BPi R1 Routerboard
>>> #
>>> # Speaker | LAN1 | LAN2 | LAN3 | LAN4 || LAN5 | HDMI
>>> # SW-Port |  P2  |  P1  |  P0  |  P4  ||  P3  |
>>> # VLAN    |  11  |  12  |  13  |  14  ||ALL(t)|
>>> #
>>> # Switch-Port P8 - ALL(t) boards internal CPU Port
>>>
>>> # Setup switch
>>> swconfig dev ${INTERFACE} set reset 1
>>> swconfig dev ${INTERFACE} set enable_vlan 1
>>> swconfig dev ${INTERFACE} vlan 101 set ports '3 8t'
>>> swconfig dev ${INTERFACE} vlan 102 set ports '4 0 1 2 8t'
>>> swconfig dev ${INTERFACE} set apply 1
>>>
>>> How to achieve this setup CURRENTLY with DSA?
>> Your first email had the right programming sequence, but you did not
>> answer whether you have CONFIG_BRIDGE_VLAN_FILTERING enabled or not,
>> which is likely your problem.
> Here are some reference configurations that should work:
>
> https://github.com/armbian/build/issues/511#issuecomment-320473246

I know, some comments are from me but none of them worked, therefore on 
LKML :-)

/boot/config-4.16.7-100.fc26.armv7hl:CONFIG_BRIDGE_VLAN_FILTERING=y

so this can't be the issue, any further ideas?

On my 2nd Banana Pi-R1 still on Fedora 25 with kernel 
4.12.8-200.fc25.armv7hl the commands still work well, but I wanted to 
test the upgrade on another one.

/boot/config-4.12.8-200.fc25.armv7hl:CONFIG_BRIDGE_VLAN_FILTERING=y

Thnx.

Ciao,

Gerhard

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

[Florian Fainelli]

On 05/23/2018 10:29 AM, Gerhard Wiesinger wrote:
> On 23.05.2018 17:50, Florian Fainelli wrote:
>>
>> On 05/23/2018 08:28 AM, Florian Fainelli wrote:
>>>
>>> On 05/22/2018 09:49 PM, Gerhard Wiesinger wrote:
>>>> On 22.05.2018 22:42, Florian Fainelli wrote:
>>>>> On 05/22/2018 01:16 PM, Andrew Lunn wrote:
>>>>>>> Planned network structure will be as with 4.7.x kernels:
>>>>>>>
>>>>>>> br0 <=> eth0.101 <=> eth0 (vlan 101 tagged) <=> lan 1-lan4 (vlan 101
>>>>>>> untagged pvid)
>>>>>>>
>>>>>>> br1 <=> eth0.102 <=> eth0 (vlan 102 tagged) <=> wan (vlan 102
>>>>>>> untagged pvid)
>>>>>> Do you even need these vlans?
>>>>> Yes, remember, b53 does not currently turn on Broadcom tags, so the
>>>>> only
>>>>> way to segregate traffic is to have VLANs for that.
>>>>>
>>>>>> Are you doing this for port separation? To keep lan1-4 traffic
>>>>>> separate from wan? DSA does that by default, no vlan needed.
>>>>>>
>>>>>> So you can just do
>>>>>>
>>>>>> ip link add name br0 type bridge
>>>>>> ip link set dev br0 up
>>>>>> ip link set dev lan1 master br0
>>>>>> ip link set dev lan2 master br0
>>>>>> ip link set dev lan3 master br0
>>>>>> ip link set dev lan4 master br0
>>>>>>
>>>>>> and use interface wan directly, no bridge needed.
>>>>> That would work once Broadcom tags are turned on which requires
>>>>> turning
>>>>> on managed mode, which requires work that I have not been able to get
>>>>> done :)
>>>> Setup with swconfig:
>>>>
>>>> #!/usr/bin/bash
>>>>
>>>>
>>>> INTERFACE=eth0
>>>>
>>>> # Delete all IP addresses and get link up
>>>> ip addr flush dev ${INTERFACE}
>>>> ip link set ${INTERFACE} up
>>>>
>>>> # Lamobo R1 aka BPi R1 Routerboard
>>>> #
>>>> # Speaker | LAN1 | LAN2 | LAN3 | LAN4 || LAN5 | HDMI
>>>> # SW-Port |  P2  |  P1  |  P0  |  P4  ||  P3  |
>>>> # VLAN    |  11  |  12  |  13  |  14  ||ALL(t)|
>>>> #
>>>> # Switch-Port P8 - ALL(t) boards internal CPU Port
>>>>
>>>> # Setup switch
>>>> swconfig dev ${INTERFACE} set reset 1
>>>> swconfig dev ${INTERFACE} set enable_vlan 1
>>>> swconfig dev ${INTERFACE} vlan 101 set ports '3 8t'
>>>> swconfig dev ${INTERFACE} vlan 102 set ports '4 0 1 2 8t'
>>>> swconfig dev ${INTERFACE} set apply 1
>>>>
>>>> How to achieve this setup CURRENTLY with DSA?
>>> Your first email had the right programming sequence, but you did not
>>> answer whether you have CONFIG_BRIDGE_VLAN_FILTERING enabled or not,
>>> which is likely your problem.
>> Here are some reference configurations that should work:
>>
>> https://github.com/armbian/build/issues/511#issuecomment-320473246
> 
> I know, some comments are from me but none of them worked, therefore on
> LKML :-)

I see, maybe you could have started there, that would have saved me a
trip to github to find out the thread.

> 
> /boot/config-4.16.7-100.fc26.armv7hl:CONFIG_BRIDGE_VLAN_FILTERING=y
> 
> so this can't be the issue, any further ideas?

Yes, remove the "self" from your bridge vlan commands, I don't see that
being necessary.

> 
> On my 2nd Banana Pi-R1 still on Fedora 25 with kernel
> 4.12.8-200.fc25.armv7hl the commands still work well, but I wanted to
> test the upgrade on another one.
> 
> /boot/config-4.12.8-200.fc25.armv7hl:CONFIG_BRIDGE_VLAN_FILTERING=y

Is using an upstream or compiled by yourself kernel an option at all? I
have no clue what is in a distribution kernel.
-- 
Florian

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

[Gerhard Wiesinger]

On 23.05.2018 19:47, Florian Fainelli wrote:
> On 05/23/2018 10:29 AM, Gerhard Wiesinger wrote:
>> On 23.05.2018 17:50, Florian Fainelli wrote:
>>> On 05/23/2018 08:28 AM, Florian Fainelli wrote:
>>>> On 05/22/2018 09:49 PM, Gerhard Wiesinger wrote:
>>>>> On 22.05.2018 22:42, Florian Fainelli wrote:
>>>>>> On 05/22/2018 01:16 PM, Andrew Lunn wrote:
>>>>>>>> Planned network structure will be as with 4.7.x kernels:
>>>>>>>>
>>>>>>>> br0 <=> eth0.101 <=> eth0 (vlan 101 tagged) <=> lan 1-lan4 (vlan 101
>>>>>>>> untagged pvid)
>>>>>>>>
>>>>>>>> br1 <=> eth0.102 <=> eth0 (vlan 102 tagged) <=> wan (vlan 102
>>>>>>>> untagged pvid)
>>>>>>> Do you even need these vlans?
>>>>>> Yes, remember, b53 does not currently turn on Broadcom tags, so the
>>>>>> only
>>>>>> way to segregate traffic is to have VLANs for that.
>>>>>>
>>>>>>> Are you doing this for port separation? To keep lan1-4 traffic
>>>>>>> separate from wan? DSA does that by default, no vlan needed.
>>>>>>>
>>>>>>> So you can just do
>>>>>>>
>>>>>>> ip link add name br0 type bridge
>>>>>>> ip link set dev br0 up
>>>>>>> ip link set dev lan1 master br0
>>>>>>> ip link set dev lan2 master br0
>>>>>>> ip link set dev lan3 master br0
>>>>>>> ip link set dev lan4 master br0
>>>>>>>
>>>>>>> and use interface wan directly, no bridge needed.
>>>>>> That would work once Broadcom tags are turned on which requires
>>>>>> turning
>>>>>> on managed mode, which requires work that I have not been able to get
>>>>>> done :)
>>>>> Setup with swconfig:
>>>>>
>>>>> #!/usr/bin/bash
>>>>>
>>>>>
>>>>> INTERFACE=eth0
>>>>>
>>>>> # Delete all IP addresses and get link up
>>>>> ip addr flush dev ${INTERFACE}
>>>>> ip link set ${INTERFACE} up
>>>>>
>>>>> # Lamobo R1 aka BPi R1 Routerboard
>>>>> #
>>>>> # Speaker | LAN1 | LAN2 | LAN3 | LAN4 || LAN5 | HDMI
>>>>> # SW-Port |  P2  |  P1  |  P0  |  P4  ||  P3  |
>>>>> # VLAN    |  11  |  12  |  13  |  14  ||ALL(t)|
>>>>> #
>>>>> # Switch-Port P8 - ALL(t) boards internal CPU Port
>>>>>
>>>>> # Setup switch
>>>>> swconfig dev ${INTERFACE} set reset 1
>>>>> swconfig dev ${INTERFACE} set enable_vlan 1
>>>>> swconfig dev ${INTERFACE} vlan 101 set ports '3 8t'
>>>>> swconfig dev ${INTERFACE} vlan 102 set ports '4 0 1 2 8t'
>>>>> swconfig dev ${INTERFACE} set apply 1
>>>>>
>>>>> How to achieve this setup CURRENTLY with DSA?
>>>> Your first email had the right programming sequence, but you did not
>>>> answer whether you have CONFIG_BRIDGE_VLAN_FILTERING enabled or not,
>>>> which is likely your problem.
>>> Here are some reference configurations that should work:
>>>
>>> https://github.com/armbian/build/issues/511#issuecomment-320473246
>> I know, some comments are from me but none of them worked, therefore on
>> LKML :-)
> I see, maybe you could have started there, that would have saved me a
> trip to github to find out the thread.
>
>> /boot/config-4.16.7-100.fc26.armv7hl:CONFIG_BRIDGE_VLAN_FILTERING=y
>>
>> so this can't be the issue, any further ideas?
> Yes, remove the "self" from your bridge vlan commands, I don't see that
> being necessary.

Same:
[root@bpi ~]# bridge vlan add dev lan1 vid 101 pvid untagged self
RTNETLINK answers: Operation not supported
[root@bpi ~]# bridge vlan add dev lan1 vid 101 pvid untagged
RTNETLINK answers: Operation not supported
[root@bpi ~]# bridge vlan add dev lan1 vid 101
RTNETLINK answers: Operation not supported

Any ideas how to debug further?

>
>> On my 2nd Banana Pi-R1 still on Fedora 25 with kernel
>> 4.12.8-200.fc25.armv7hl the commands still work well, but I wanted to
>> test the upgrade on another one.
>>
>> /boot/config-4.12.8-200.fc25.armv7hl:CONFIG_BRIDGE_VLAN_FILTERING=y
> Is using an upstream or compiled by yourself kernel an option at all? I
> have no clue what is in a distribution kernel.

Typically the Fedora kernels work fine (long term experience since 
Fedora Core 1 from 2004 :-) ). I had some custom patches in there in the 
past for external RTC and b53_switch.kernel_4.5+.patch, but otherwise no 
topics. Therefore with upstream DSA support that should be fine then.


Infos can be found here:

https://koji.fedoraproject.org/koji/packageinfo?packageID=8

https://koji.fedoraproject.org/koji/buildinfo?buildID=1078638


Ciao,

Gerhard

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

[Florian Fainelli]

On 05/23/2018 11:11 AM, Gerhard Wiesinger wrote:
> On 23.05.2018 19:47, Florian Fainelli wrote:
>> On 05/23/2018 10:29 AM, Gerhard Wiesinger wrote:
>>> On 23.05.2018 17:50, Florian Fainelli wrote:
>>>> On 05/23/2018 08:28 AM, Florian Fainelli wrote:
>>>>> On 05/22/2018 09:49 PM, Gerhard Wiesinger wrote:
>>>>>> On 22.05.2018 22:42, Florian Fainelli wrote:
>>>>>>> On 05/22/2018 01:16 PM, Andrew Lunn wrote:
>>>>>>>>> Planned network structure will be as with 4.7.x kernels:
>>>>>>>>>
>>>>>>>>> br0 <=> eth0.101 <=> eth0 (vlan 101 tagged) <=> lan 1-lan4
>>>>>>>>> (vlan 101
>>>>>>>>> untagged pvid)
>>>>>>>>>
>>>>>>>>> br1 <=> eth0.102 <=> eth0 (vlan 102 tagged) <=> wan (vlan 102
>>>>>>>>> untagged pvid)
>>>>>>>> Do you even need these vlans?
>>>>>>> Yes, remember, b53 does not currently turn on Broadcom tags, so the
>>>>>>> only
>>>>>>> way to segregate traffic is to have VLANs for that.
>>>>>>>
>>>>>>>> Are you doing this for port separation? To keep lan1-4 traffic
>>>>>>>> separate from wan? DSA does that by default, no vlan needed.
>>>>>>>>
>>>>>>>> So you can just do
>>>>>>>>
>>>>>>>> ip link add name br0 type bridge
>>>>>>>> ip link set dev br0 up
>>>>>>>> ip link set dev lan1 master br0
>>>>>>>> ip link set dev lan2 master br0
>>>>>>>> ip link set dev lan3 master br0
>>>>>>>> ip link set dev lan4 master br0
>>>>>>>>
>>>>>>>> and use interface wan directly, no bridge needed.
>>>>>>> That would work once Broadcom tags are turned on which requires
>>>>>>> turning
>>>>>>> on managed mode, which requires work that I have not been able to
>>>>>>> get
>>>>>>> done :)
>>>>>> Setup with swconfig:
>>>>>>
>>>>>> #!/usr/bin/bash
>>>>>>
>>>>>>
>>>>>> INTERFACE=eth0
>>>>>>
>>>>>> # Delete all IP addresses and get link up
>>>>>> ip addr flush dev ${INTERFACE}
>>>>>> ip link set ${INTERFACE} up
>>>>>>
>>>>>> # Lamobo R1 aka BPi R1 Routerboard
>>>>>> #
>>>>>> # Speaker | LAN1 | LAN2 | LAN3 | LAN4 || LAN5 | HDMI
>>>>>> # SW-Port |  P2  |  P1  |  P0  |  P4  ||  P3  |
>>>>>> # VLAN    |  11  |  12  |  13  |  14  ||ALL(t)|
>>>>>> #
>>>>>> # Switch-Port P8 - ALL(t) boards internal CPU Port
>>>>>>
>>>>>> # Setup switch
>>>>>> swconfig dev ${INTERFACE} set reset 1
>>>>>> swconfig dev ${INTERFACE} set enable_vlan 1
>>>>>> swconfig dev ${INTERFACE} vlan 101 set ports '3 8t'
>>>>>> swconfig dev ${INTERFACE} vlan 102 set ports '4 0 1 2 8t'
>>>>>> swconfig dev ${INTERFACE} set apply 1
>>>>>>
>>>>>> How to achieve this setup CURRENTLY with DSA?
>>>>> Your first email had the right programming sequence, but you did not
>>>>> answer whether you have CONFIG_BRIDGE_VLAN_FILTERING enabled or not,
>>>>> which is likely your problem.
>>>> Here are some reference configurations that should work:
>>>>
>>>> https://github.com/armbian/build/issues/511#issuecomment-320473246
>>> I know, some comments are from me but none of them worked, therefore on
>>> LKML :-)
>> I see, maybe you could have started there, that would have saved me a
>> trip to github to find out the thread.
>>
>>> /boot/config-4.16.7-100.fc26.armv7hl:CONFIG_BRIDGE_VLAN_FILTERING=y
>>>
>>> so this can't be the issue, any further ideas?
>> Yes, remove the "self" from your bridge vlan commands, I don't see that
>> being necessary.
> 
> Same:
> [root@bpi ~]# bridge vlan add dev lan1 vid 101 pvid untagged self
> RTNETLINK answers: Operation not supported
> [root@bpi ~]# bridge vlan add dev lan1 vid 101 pvid untagged
> RTNETLINK answers: Operation not supported
> [root@bpi ~]# bridge vlan add dev lan1 vid 101
> RTNETLINK answers: Operation not supported
> 
> Any ideas how to debug further?

Not particularly no, you would have to trace through the code where this
is failing, strace might give a first level of clue.

> 
>>
>>> On my 2nd Banana Pi-R1 still on Fedora 25 with kernel
>>> 4.12.8-200.fc25.armv7hl the commands still work well, but I wanted to
>>> test the upgrade on another one.
>>>
>>> /boot/config-4.12.8-200.fc25.armv7hl:CONFIG_BRIDGE_VLAN_FILTERING=y
>> Is using an upstream or compiled by yourself kernel an option at all? I
>> have no clue what is in a distribution kernel.
> 
> Typically the Fedora kernels work fine (long term experience since
> Fedora Core 1 from 2004 :-) ). I had some custom patches in there in the
> past for external RTC and b53_switch.kernel_4.5+.patch, but otherwise no
> topics. Therefore with upstream DSA support that should be fine then.
> 
> 
> Infos can be found here:
> 
> https://koji.fedoraproject.org/koji/packageinfo?packageID=8
> 
> https://koji.fedoraproject.org/koji/buildinfo?buildID=1078638
> 
> 
> Ciao,
> 
> Gerhard
> 
> 


-- 
Florian

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

[Gerhard Wiesinger]

On 23.05.2018 17:28, Florian Fainelli wrote:
>
>> And in the future (time plan)?
> If you don't care about multicast then you can use those patches:
>
> https://github.com/ffainelli/linux/commit/de055bf5f34e9806463ab2793e0852f5dfc380df
>
> and you have to change the part of drivers/net/dsa/b53/b53_common.c that
> returns DSA_TAG_PROTO_NONE for 53125:
>
>
> diff --git a/drivers/net/dsa/b53/b53_common.c
> b/drivers/net/dsa/b53/b53_common.c
> index 9f561fe505cb..3c64f026a8ce 100644
> --- a/drivers/net/dsa/b53/b53_common.c
> +++ b/drivers/net/dsa/b53/b53_common.c
> @@ -1557,7 +1557,7 @@ enum dsa_tag_protocol b53_get_tag_protocol(struct
> dsa_switch *ds, int port)
>           * mode to be turned on which means we need to specifically
> manage ARL
>           * misses on multicast addresses (TBD).
>           */
> -       if (is5325(dev) || is5365(dev) || is539x(dev) || is531x5(dev) ||
> +       if (is5325(dev) || is5365(dev) || is539x(dev) ||
>              !b53_can_enable_brcm_tags(ds, port))
>                  return DSA_TAG_PROTO_NONE;
>
>
> That would bring Broadcom tags to the 53125 switch and you would be able
> to use the configuration lines from Andrew in that case.

What's the plan here regarding these 2 config option mode (how do you 
call them?)?

I mean, will this be a breaking change in the future where config has to 
be done in a different way then?

Or will it be configurable via module parameters or /proc or /sys 
filesystem options?


Thank you.

Ciao,

Gerhard

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

[Florian Fainelli]

On 05/23/2018 10:35 AM, Gerhard Wiesinger wrote:
> On 23.05.2018 17:28, Florian Fainelli wrote:
>>
>>> And in the future (time plan)?
>> If you don't care about multicast then you can use those patches:
>>
>> https://github.com/ffainelli/linux/commit/de055bf5f34e9806463ab2793e0852f5dfc380df
>>
>>
>> and you have to change the part of drivers/net/dsa/b53/b53_common.c that
>> returns DSA_TAG_PROTO_NONE for 53125:
>>
>>
>> diff --git a/drivers/net/dsa/b53/b53_common.c
>> b/drivers/net/dsa/b53/b53_common.c
>> index 9f561fe505cb..3c64f026a8ce 100644
>> --- a/drivers/net/dsa/b53/b53_common.c
>> +++ b/drivers/net/dsa/b53/b53_common.c
>> @@ -1557,7 +1557,7 @@ enum dsa_tag_protocol b53_get_tag_protocol(struct
>> dsa_switch *ds, int port)
>>           * mode to be turned on which means we need to specifically
>> manage ARL
>>           * misses on multicast addresses (TBD).
>>           */
>> -       if (is5325(dev) || is5365(dev) || is539x(dev) || is531x5(dev) ||
>> +       if (is5325(dev) || is5365(dev) || is539x(dev) ||
>>              !b53_can_enable_brcm_tags(ds, port))
>>                  return DSA_TAG_PROTO_NONE;
>>
>>
>> That would bring Broadcom tags to the 53125 switch and you would be able
>> to use the configuration lines from Andrew in that case.
> 
> What's the plan here regarding these 2 config option mode (how do you
> call them?)?

Broadcom tags is the underlying feature that provides per-port
information about the packets going in and out. Turning on Broadcom tags
requires turning on managed mode which means that the host now has to
manage how MAC addresses are programmed into the switch, it's not rocket
science, but I don't have a good test framework to automate the testing
of those changes yet. If you are willing to help in the testing, I can
certainly give you patches to try.

> 
> I mean, will this be a breaking change in the future where config has to
> be done in a different way then?

When Broadcom tags are enabled the switch gets usable the way Andrew
expressed it, the only difference that makes on your configuration if
you want e.g: VLAN 101 to be for port 1-4 and VLAN 102 to be for port 5,
is that you no longer create an eth0.101 and eth0.102, but you create
br0.101 and br0.102.

> 
> Or will it be configurable via module parameters or /proc or /sys
> filesystem options?

We might be able to expose a sysfs attribute which shows the type of
tagging being enabled by a particular switch, that way scripts can
detect which variant: configuring the host controller or the bridge is
required. Would that be acceptable?
-- 
Florian

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

[Gerhard Wiesinger]

On 23.05.2018 19:55, Florian Fainelli wrote:
> On 05/23/2018 10:35 AM, Gerhard Wiesinger wrote:
>> On 23.05.2018 17:28, Florian Fainelli wrote:
>>>> And in the future (time plan)?
>>> If you don't care about multicast then you can use those patches:
>>>
>>> https://github.com/ffainelli/linux/commit/de055bf5f34e9806463ab2793e0852f5dfc380df
>>>
>>>
>>> and you have to change the part of drivers/net/dsa/b53/b53_common.c that
>>> returns DSA_TAG_PROTO_NONE for 53125:
>>>
>>>
>>> diff --git a/drivers/net/dsa/b53/b53_common.c
>>> b/drivers/net/dsa/b53/b53_common.c
>>> index 9f561fe505cb..3c64f026a8ce 100644
>>> --- a/drivers/net/dsa/b53/b53_common.c
>>> +++ b/drivers/net/dsa/b53/b53_common.c
>>> @@ -1557,7 +1557,7 @@ enum dsa_tag_protocol b53_get_tag_protocol(struct
>>> dsa_switch *ds, int port)
>>>            * mode to be turned on which means we need to specifically
>>> manage ARL
>>>            * misses on multicast addresses (TBD).
>>>            */
>>> -       if (is5325(dev) || is5365(dev) || is539x(dev) || is531x5(dev) ||
>>> +       if (is5325(dev) || is5365(dev) || is539x(dev) ||
>>>               !b53_can_enable_brcm_tags(ds, port))
>>>                   return DSA_TAG_PROTO_NONE;
>>>
>>>
>>> That would bring Broadcom tags to the 53125 switch and you would be able
>>> to use the configuration lines from Andrew in that case.
>> What's the plan here regarding these 2 config option mode (how do you
>> call them?)?
> Broadcom tags is the underlying feature that provides per-port
> information about the packets going in and out. Turning on Broadcom tags
> requires turning on managed mode which means that the host now has to
> manage how MAC addresses are programmed into the switch, it's not rocket
> science, but I don't have a good test framework to automate the testing
> of those changes yet. If you are willing to help in the testing, I can
> certainly give you patches to try.

Yes, patches are welcome.

>> I mean, will this be a breaking change in the future where config has to
>> be done in a different way then?
> When Broadcom tags are enabled the switch gets usable the way Andrew
> expressed it, the only difference that makes on your configuration if
> you want e.g: VLAN 101 to be for port 1-4 and VLAN 102 to be for port 5,
> is that you no longer create an eth0.101 and eth0.102, but you create
> br0.101 and br0.102.

I think documentation (dsa.txt) should provide more examples.

>
>> Or will it be configurable via module parameters or /proc or /sys
>> filesystem options?
> We might be able to expose a sysfs attribute which shows the type of
> tagging being enabled by a particular switch, that way scripts can
> detect which variant: configuring the host controller or the bridge is
> required. Would that be acceptable?

Yes, acceptable for me. But what's the long term concept for DSA (and 
also other implementations)?

- "old" mode variant, mode can only be read

- "new" mode variant, mode can only be read

- mode settable/configurable by the user, mode can be read


In general:

OK, thank you for your explainations.


I think DSA (at least with b53) had secveral topics. implementation 
bugs, missing documentation, lack of distribution support (e.g. 
systemd), etc. which were not understood by the users.

So everything which clarifies the topics for DSA in the future is welcome.

BTW: systemd-networkd support for DSA #7478

https://github.com/systemd/systemd/issues/7478


Ciao,

Gerhard

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

[Florian Fainelli]

On 05/23/2018 11:27 AM, Gerhard Wiesinger wrote:
> On 23.05.2018 19:55, Florian Fainelli wrote:
>> On 05/23/2018 10:35 AM, Gerhard Wiesinger wrote:
>>> On 23.05.2018 17:28, Florian Fainelli wrote:
>>>>> And in the future (time plan)?
>>>> If you don't care about multicast then you can use those patches:
>>>>
>>>> https://github.com/ffainelli/linux/commit/de055bf5f34e9806463ab2793e0852f5dfc380df
>>>>
>>>>
>>>>
>>>> and you have to change the part of drivers/net/dsa/b53/b53_common.c
>>>> that
>>>> returns DSA_TAG_PROTO_NONE for 53125:
>>>>
>>>>
>>>> diff --git a/drivers/net/dsa/b53/b53_common.c
>>>> b/drivers/net/dsa/b53/b53_common.c
>>>> index 9f561fe505cb..3c64f026a8ce 100644
>>>> --- a/drivers/net/dsa/b53/b53_common.c
>>>> +++ b/drivers/net/dsa/b53/b53_common.c
>>>> @@ -1557,7 +1557,7 @@ enum dsa_tag_protocol b53_get_tag_protocol(struct
>>>> dsa_switch *ds, int port)
>>>>            * mode to be turned on which means we need to specifically
>>>> manage ARL
>>>>            * misses on multicast addresses (TBD).
>>>>            */
>>>> -       if (is5325(dev) || is5365(dev) || is539x(dev) ||
>>>> is531x5(dev) ||
>>>> +       if (is5325(dev) || is5365(dev) || is539x(dev) ||
>>>>               !b53_can_enable_brcm_tags(ds, port))
>>>>                   return DSA_TAG_PROTO_NONE;
>>>>
>>>>
>>>> That would bring Broadcom tags to the 53125 switch and you would be
>>>> able
>>>> to use the configuration lines from Andrew in that case.
>>> What's the plan here regarding these 2 config option mode (how do you
>>> call them?)?
>> Broadcom tags is the underlying feature that provides per-port
>> information about the packets going in and out. Turning on Broadcom tags
>> requires turning on managed mode which means that the host now has to
>> manage how MAC addresses are programmed into the switch, it's not rocket
>> science, but I don't have a good test framework to automate the testing
>> of those changes yet. If you are willing to help in the testing, I can
>> certainly give you patches to try.
> 
> Yes, patches are welcome.

I gave you the two things that would be required to have Broadcom tags
working already, feel free to givem them a try. Make sure your kernel
also has that patch:

8cad443eacf661796a740903a75cb8944c675b4e ("net: stmmac: Fix reception of
Broadcom switches tags")

> 
>>> I mean, will this be a breaking change in the future where config has to
>>> be done in a different way then?
>> When Broadcom tags are enabled the switch gets usable the way Andrew
>> expressed it, the only difference that makes on your configuration if
>> you want e.g: VLAN 101 to be for port 1-4 and VLAN 102 to be for port 5,
>> is that you no longer create an eth0.101 and eth0.102, but you create
>> br0.101 and br0.102.
> 
> I think documentation (dsa.txt) should provide more examples.

Fair enough.

> 
>>
>>> Or will it be configurable via module parameters or /proc or /sys
>>> filesystem options?
>> We might be able to expose a sysfs attribute which shows the type of
>> tagging being enabled by a particular switch, that way scripts can
>> detect which variant: configuring the host controller or the bridge is
>> required. Would that be acceptable?
> 
> Yes, acceptable for me. But what's the long term concept for DSA (and
> also other implementations)?
> 
> - "old" mode variant, mode can only be read
> 
> - "new" mode variant, mode can only be read
> 
> - mode settable/configurable by the user, mode can be read

Having tags enabled is a "superior" mode of operation so it should
always be enabled when possible and working, using DSA_TAG_PROTO_NONE
creates unfortunate confusion because the switch becomes "dumb" so that
is not to be maintained in the future.

The plan is to bring Broadcom tags at some point into b53, for all
generation of the switches, that requires time that I do not have right
now, but which I will hopefully have at some point. There is not
necessarily a plan to avoid breaking user-space because, see below, this
is really niche hardware.

> 
> 
> In general:
> 
> OK, thank you for your explainations.
> 
> 
> I think DSA (at least with b53) had secveral topics. implementation
> bugs, missing documentation, lack of distribution support (e.g.
> systemd), etc. which were not understood by the users.

Yes, that is entirely fair enough, the concepts are pretty simple, but
they are sometimes hard to communicate clearly.

> 
> So everything which clarifies the topics for DSA in the future is welcome.
> 
> BTW: systemd-networkd support for DSA #7478
> 
> https://github.com/systemd/systemd/issues/7478

Well, you have to understand where this is coming from, people don't run
mainline distributions on the routers that typically have support for
DSA, they use Buildroot, Yocto, OpenWrt, whatever, and they know their
platform and that this platform requires Tender Love and Care to work as
they expect it to behave, because that's what embedded is all about.
--
Florian

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

[Gerhard Wiesinger]

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.

Ciao,
Gerhard

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

[Gerhard Wiesinger]

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

Ciao,
Gerhard

Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26 - systemd-networkd problem

[Gerhard Wiesinger]

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 
>

Kernel 4.14.18-300.fc27.armv7hl works well so far, even with FC28 
update. Florian send me a patch to try for 4.16.x

I got the  commands below to work with manual script commands.
Afterwards I wrote systemd-networkd config where I've a strage problem 
when IPv6 sends a multicast broadcast from another machine to the bridge 
this will be sent back via the network interface, but with the source 
MAC of the bridge of the other machine. dmesg from the other machine:
[117768.330444] br0: received packet on lan0 with own address as source 
address (addr:a0:36:9f:ab:cd:ef, vlan:0)
[117768.334887] br0: received packet on lan0 with own address as source 
address (addr:a0:36:9f:ab:cd:ef, vlan:0)
[117768.339281] br0: received packet on lan0 with own address as source 
address (addr:a0:36:9f:ab:cd:ef, vlan:0)

And: If I just enter this command after e.g. a systemd-network restart 
everything is fine forever:
# Not OK (dmesg message above is triggered on a remote computer, whole 
switching network gets unstable, ssh terminals close, packet loss, etc.)
systemctl restart systemd-networkd
# OK again when this command is entered
bridge vlan add dev wan vid 102 pvid untagged

brctl show, ip link, bridge vlan, bridge link commands, etc. look all 
the same, also /sys/class/net/br0/bridge, /sys/class/net/br1/bridge settings

Systemd config correct?
Any ideas?

Thank you.

Ciao,
Gerhard

brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.665da2abcdef       no              eth0.101
                                                         lan1
                                                         lan2
                                                         lan3
                                                         lan4
br1             8000.9a4557abcdef      no              eth0.102
                                                         wan


bridge vlan show
port    vlan ids
lan2     101 PVID Egress Untagged

lan3     101 PVID Egress Untagged

lan4     101 PVID Egress Untagged

wan      102 PVID Egress Untagged

lan1     101 PVID Egress Untagged

br1     None
br0     None
eth0.102        None
eth0.101        None

================================================================================================================================================================

OK: manual scripts

================================================================================================================================================================

ip link add link eth0 name eth0.101 type vlan id 101
ip link set eth0.101 up
ip link add link eth0 name eth0.102 type vlan id 102
ip link set eth0.102 up
ip link add br0 type bridge
ip link set dev br0 type bridge stp_state 0
ip link set lan1 master br0
bridge vlan add dev lan1 vid 101 pvid untagged
ip link set lan1 up
ip link set lan2 master br0
bridge vlan add dev lan2 vid 101 pvid untagged
ip link set lan2 up
ip link set lan3 master br0
bridge vlan add dev lan3 vid 101 pvid untagged
ip link set lan3 up
ip link set lan4 master br0
bridge vlan add dev lan4 vid 101 pvid untagged
ip link set lan4 up
ip link set eth0.101 master br0
ip link set eth0.101 up
ip link set br0 up
ip link add br1 type bridge
ip link set dev br1 type bridge stp_state 0
ip link set wan master br1
bridge vlan add dev wan vid 102 pvid untagged
ip link set wan up
ip link set eth0.102 master br1
ip link set eth0.102 up
ip link set br1 up
ip addr flush dev br0
ip addr add 192.168.0.250/24 dev br0
ip route del default via 192.168.0.1 dev br0
ip route add default via 192.168.0.1 dev br0
ip addr flush dev br1
ip addr add 192.168.1.1/24 dev br1


================================================================================================================================================================

NOK: after a multicast packet is received

================================================================================================================================================================

================================================================================
= /etc/systemd/network/40-autogen-eth0.101.netdev
================================================================================
[NetDev]
Name=eth0.101
Kind=vlan

[VLAN]
Id=101
================================================================================
= /etc/systemd/network/40-autogen-eth0.102.netdev
================================================================================
[NetDev]
Name=eth0.102
Kind=vlan

[VLAN]
Id=102
================================================================================
= /etc/systemd/network/40-autogen-eth0.network
================================================================================
[Match]
Name=eth0

[Network]
VLAN=eth0.101
VLAN=eth0.102
================================================================================
= /etc/systemd/network/50-autogen-br0.netdev
================================================================================
[NetDev]
Name=br0
Kind=bridge

[Bridge]
DefaultPVID=none
VLANFiltering=false
STP=false
================================================================================
= /etc/systemd/network/50-autogen-br1.netdev
================================================================================
[NetDev]
Name=br1
Kind=bridge

[Bridge]
DefaultPVID=none
VLANFiltering=false
STP=false
================================================================================
= /etc/systemd/network/60-autogen-br0-eth0.101.network
================================================================================
[Match]
Name=eth0.101

[Network]
Bridge=br0
================================================================================
= /etc/systemd/network/60-autogen-br0-lan1.network
================================================================================
[Match]
Name=lan1

[Network]
Bridge=br0

[BridgeVLAN]
VLAN=101
EgressUntagged=101
PVID=101
================================================================================
= /etc/systemd/network/60-autogen-br0-lan2.network
================================================================================
[Match]
Name=lan2

[Network]
Bridge=br0

[BridgeVLAN]
VLAN=101
EgressUntagged=101
PVID=101
================================================================================
= /etc/systemd/network/60-autogen-br0-lan3.network
================================================================================
[Match]
Name=lan3

[Network]
Bridge=br0

[BridgeVLAN]
VLAN=101
EgressUntagged=101
PVID=101
================================================================================
= /etc/systemd/network/60-autogen-br0-lan4.network
================================================================================
[Match]
Name=lan4

[Network]
Bridge=br0

[BridgeVLAN]
VLAN=101
EgressUntagged=101
PVID=101
================================================================================
= /etc/systemd/network/60-autogen-br1-eth0.102.network
================================================================================
[Match]
Name=eth0.102

[Network]
Bridge=br1
================================================================================
= /etc/systemd/network/60-autogen-br1-wan.network
================================================================================
[Match]
Name=wan

[Network]
Bridge=br1

[BridgeVLAN]
VLAN=102
EgressUntagged=102
PVID=102
================================================================================
= /etc/systemd/network/61-autogen-br0.network
================================================================================
[Match]
Name=br0

[Network]
Address=192.168.0.250/24
Gateway=192.168.0.1
DNS=192.168.0.1
Domains=intern
================================================================================
= /etc/systemd/network/61-autogen-br1.network
================================================================================
[Match]
Name=br1

[Network]
Address=192.168.1.1/24

Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26 - systemd-networkd problem

[Gerhard Wiesinger]

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?

Thank you.

Ciao,
Gerhard

Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26 - systemd-networkd problem

[Florian Fainelli]

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

Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26 - systemd-networkd problem

[Gerhard Wiesinger]

On 27.05.2018 22:35, Florian Fainelli wrote:
> 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.

Yes, sniffing on eth0 shows the correct VLAN IDs, e.g. 101.

Yes, my guess is that tools are wrong and have random values on 2 calls 
in different values (e.g. alsopromiscuity ) , see below ....

Who can fix it?

BTW: On FC27 same issue with same kernel version, but guess older 
iproute version.

Ciao,

Gerhard


ip -d link show eth0.101

13: eth0.101@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc 
noqueue master br0 state UP mode DEFAULT group default qlen 1000
     link/ether 02:18:09:ab:cd:ef brd ff:ff:ff:ff:ff:ff promiscuity 
3068661300
     vlan protocol 802.1Q id 3068661300 <REORDER_HDR>
     bridge_slave state forwarding priority 32 cost 4 hairpin off guard 
off root_block off fastleave off learning on flood on port_id 0x8005 
port_no 0x5 designa
ted_port 3068661300 designated_cost 3068661300 designated_bridge 
8000.66:5d:a2:ab:cd:ef designated_root 8000.66:5d:a2:ab:cd:ef 
hold_timer    0.00 message_age_tim
er    0.00 forward_delay_timer    0.00 topology_change_ack 3068661300 
config_pending 3068661300 proxy_arp off proxy_arp_wifi off mcast_router 
3068661300 mcast_
fast_leave off mcast_flood on vlan_tunnel off addrgenmode eui64 
numtxqueues 3068661300 numrxqueues 3068661300 gso_max_size 3068661300 
gso_max_segs 3068661300

ip -d link show eth0.101
13: eth0.101@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc 
noqueue master br0 state UP mode DEFAULT group default qlen 1000
     link/ether 02:18:09:ab:cd:ef brd ff:ff:ff:ff:ff:ff promiscuity 
3068735028
     vlan protocol 802.1Q id 3068735028 <REORDER_HDR>
     bridge_slave state forwarding priority 32 cost 4 hairpin off guard 
off root_block off fastleave off learning on flood on port_id 0x8005 
port_no 0x5 designa
ted_port 3068735028 designated_cost 3068735028 designated_bridge 
8000.66:5d:ab:cd:ef designated_root 8000.66:5d:a2:ab:cd:ef hold_timer    
0.00 message_age_tim
er    0.00 forward_delay_timer    0.00 topology_change_ack 3068735028 
config_pending 3068735028 proxy_arp off proxy_arp_wifi off mcast_router 
3068735028 mcast_
fast_leave off mcast_flood on vlan_tunnel off addrgenmode eui64 
numtxqueues 3068735028 numrxqueues 3068735028 gso_max_size 3068735028 
gso_max_segs 3068735028

Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26 - systemd-networkd problem

[Florian Fainelli]

Le 05/27/18 à 12:01, Gerhard Wiesinger a écrit :
> 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
>>
> 
> Kernel 4.14.18-300.fc27.armv7hl works well so far, even with FC28
> update. Florian send me a patch to try for 4.16.x

So does my patch make 4.16 work correctly for you now? If so, can I just
submit it and copy you?

> 
> I got the  commands below to work with manual script commands.
> Afterwards I wrote systemd-networkd config where I've a strage problem
> when IPv6 sends a multicast broadcast from another machine to the bridge
> this will be sent back via the network interface, but with the source
> MAC of the bridge of the other machine. dmesg from the other machine:
> [117768.330444] br0: received packet on lan0 with own address as source
> address (addr:a0:36:9f:ab:cd:ef, vlan:0)
> [117768.334887] br0: received packet on lan0 with own address as source
> address (addr:a0:36:9f:ab:cd:ef, vlan:0)
> [117768.339281] br0: received packet on lan0 with own address as source
> address (addr:a0:36:9f:ab:cd:ef, vlan:0)
> 
> And: If I just enter this command after e.g. a systemd-network restart
> everything is fine forever:
> # Not OK (dmesg message above is triggered on a remote computer, whole
> switching network gets unstable, ssh terminals close, packet loss, etc.)
> systemctl restart systemd-networkd
> # OK again when this command is entered
> bridge vlan add dev wan vid 102 pvid untagged
> 
> brctl show, ip link, bridge vlan, bridge link commands, etc. look all
> the same, also /sys/class/net/br0/bridge, /sys/class/net/br1/bridge
> settings
> 
> Systemd config correct?
> Any ideas?

You should not have eth0.101 and eth0.102 to be enslaved in a bridge at
all, this is what is causing the bridge to be confused. Remember what I
wrote to you before, with the current b53 driver that does not have any
tagging enabled the lanX interfaces and brX interfaces are only used for
control and should not be used for passing any data. The only network
device that will be passing data is eth0, which is why we need to set-up
VLAN interfaces to pop/push the VLAN id accordingly.

I have no idea why manual vs. systemd does not work but you can most
certainly troubleshoot that by comparing the bridge/ip outputs.

> 
> Thank you.
> 
> Ciao,
> Gerhard
> 
> brctl show
> bridge name     bridge id               STP enabled     interfaces
> br0             8000.665da2abcdef       no              eth0.101
>                                                         lan1
>                                                         lan2
>                                                         lan3
>                                                         lan4
> br1             8000.9a4557abcdef      no              eth0.102
>                                                         wan
> 
> 
> bridge vlan show
> port    vlan ids
> lan2     101 PVID Egress Untagged
> 
> lan3     101 PVID Egress Untagged
> 
> lan4     101 PVID Egress Untagged
> 
> wan      102 PVID Egress Untagged
> 
> lan1     101 PVID Egress Untagged
> 
> br1     None
> br0     None
> eth0.102        None
> eth0.101        None
> 
> ================================================================================================================================================================
> 
> 
> OK: manual scripts
> 
> ================================================================================================================================================================
> 
> 
> ip link add link eth0 name eth0.101 type vlan id 101
> ip link set eth0.101 up
> ip link add link eth0 name eth0.102 type vlan id 102
> ip link set eth0.102 up
> ip link add br0 type bridge
> ip link set dev br0 type bridge stp_state 0
> ip link set lan1 master br0
> bridge vlan add dev lan1 vid 101 pvid untagged
> ip link set lan1 up
> ip link set lan2 master br0
> bridge vlan add dev lan2 vid 101 pvid untagged
> ip link set lan2 up
> ip link set lan3 master br0
> bridge vlan add dev lan3 vid 101 pvid untagged
> ip link set lan3 up
> ip link set lan4 master br0
> bridge vlan add dev lan4 vid 101 pvid untagged
> ip link set lan4 up
> ip link set eth0.101 master br0
> ip link set eth0.101 up
> ip link set br0 up
> ip link add br1 type bridge
> ip link set dev br1 type bridge stp_state 0
> ip link set wan master br1
> bridge vlan add dev wan vid 102 pvid untagged
> ip link set wan up
> ip link set eth0.102 master br1
> ip link set eth0.102 up
> ip link set br1 up
> ip addr flush dev br0
> ip addr add 192.168.0.250/24 dev br0
> ip route del default via 192.168.0.1 dev br0
> ip route add default via 192.168.0.1 dev br0
> ip addr flush dev br1
> ip addr add 192.168.1.1/24 dev br1
> 
> 
> ================================================================================================================================================================
> 
> 
> NOK: after a multicast packet is received
> 
> ================================================================================================================================================================
> 
> 
> ================================================================================
> 
> = /etc/systemd/network/40-autogen-eth0.101.netdev
> ================================================================================
> 
> [NetDev]
> Name=eth0.101
> Kind=vlan
> 
> [VLAN]
> Id=101
> ================================================================================
> 
> = /etc/systemd/network/40-autogen-eth0.102.netdev
> ================================================================================
> 
> [NetDev]
> Name=eth0.102
> Kind=vlan
> 
> [VLAN]
> Id=102
> ================================================================================
> 
> = /etc/systemd/network/40-autogen-eth0.network
> ================================================================================
> 
> [Match]
> Name=eth0
> 
> [Network]
> VLAN=eth0.101
> VLAN=eth0.102
> ================================================================================
> 
> = /etc/systemd/network/50-autogen-br0.netdev
> ================================================================================
> 
> [NetDev]
> Name=br0
> Kind=bridge
> 
> [Bridge]
> DefaultPVID=none
> VLANFiltering=false
> STP=false
> ================================================================================
> 
> = /etc/systemd/network/50-autogen-br1.netdev
> ================================================================================
> 
> [NetDev]
> Name=br1
> Kind=bridge
> 
> [Bridge]
> DefaultPVID=none
> VLANFiltering=false
> STP=false
> ================================================================================
> 
> = /etc/systemd/network/60-autogen-br0-eth0.101.network
> ================================================================================
> 
> [Match]
> Name=eth0.101
> 
> [Network]
> Bridge=br0
> ================================================================================
> 
> = /etc/systemd/network/60-autogen-br0-lan1.network
> ================================================================================
> 
> [Match]
> Name=lan1
> 
> [Network]
> Bridge=br0
> 
> [BridgeVLAN]
> VLAN=101
> EgressUntagged=101
> PVID=101
> ================================================================================
> 
> = /etc/systemd/network/60-autogen-br0-lan2.network
> ================================================================================
> 
> [Match]
> Name=lan2
> 
> [Network]
> Bridge=br0
> 
> [BridgeVLAN]
> VLAN=101
> EgressUntagged=101
> PVID=101
> ================================================================================
> 
> = /etc/systemd/network/60-autogen-br0-lan3.network
> ================================================================================
> 
> [Match]
> Name=lan3
> 
> [Network]
> Bridge=br0
> 
> [BridgeVLAN]
> VLAN=101
> EgressUntagged=101
> PVID=101
> ================================================================================
> 
> = /etc/systemd/network/60-autogen-br0-lan4.network
> ================================================================================
> 
> [Match]
> Name=lan4
> 
> [Network]
> Bridge=br0
> 
> [BridgeVLAN]
> VLAN=101
> EgressUntagged=101
> PVID=101
> ================================================================================
> 
> = /etc/systemd/network/60-autogen-br1-eth0.102.network
> ================================================================================
> 
> [Match]
> Name=eth0.102
> 
> [Network]
> Bridge=br1
> ================================================================================
> 
> = /etc/systemd/network/60-autogen-br1-wan.network
> ================================================================================
> 
> [Match]
> Name=wan
> 
> [Network]
> Bridge=br1
> 
> [BridgeVLAN]
> VLAN=102
> EgressUntagged=102
> PVID=102
> ================================================================================
> 
> = /etc/systemd/network/61-autogen-br0.network
> ================================================================================
> 
> [Match]
> Name=br0
> 
> [Network]
> Address=192.168.0.250/24
> Gateway=192.168.0.1
> DNS=192.168.0.1
> Domains=intern
> ================================================================================
> 
> = /etc/systemd/network/61-autogen-br1.network
> ================================================================================
> 
> [Match]
> Name=br1
> 
> [Network]
> Address=192.168.1.1/24
> 


-- 
Florian

Re: B53 DSA switch problem on Banana Pi-R1 on Fedora 26 - systemd-networkd problem

[Gerhard Wiesinger]

On 27.05.2018 22:31, Florian Fainelli wrote:
> Le 05/27/18 à 12:01, Gerhard Wiesinger a écrit :
>> 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
>>>
>> Kernel 4.14.18-300.fc27.armv7hl works well so far, even with FC28
>> update. Florian send me a patch to try for 4.16.x
> So does my patch make 4.16 work correctly for you now? If so, can I just
> submit it and copy you?
>
>> I got the  commands below to work with manual script commands.
>> Afterwards I wrote systemd-networkd config where I've a strage problem
>> when IPv6 sends a multicast broadcast from another machine to the bridge
>> this will be sent back via the network interface, but with the source
>> MAC of the bridge of the other machine. dmesg from the other machine:
>> [117768.330444] br0: received packet on lan0 with own address as source
>> address (addr:a0:36:9f:ab:cd:ef, vlan:0)
>> [117768.334887] br0: received packet on lan0 with own address as source
>> address (addr:a0:36:9f:ab:cd:ef, vlan:0)
>> [117768.339281] br0: received packet on lan0 with own address as source
>> address (addr:a0:36:9f:ab:cd:ef, vlan:0)
>>
>> And: If I just enter this command after e.g. a systemd-network restart
>> everything is fine forever:
>> # Not OK (dmesg message above is triggered on a remote computer, whole
>> switching network gets unstable, ssh terminals close, packet loss, etc.)
>> systemctl restart systemd-networkd
>> # OK again when this command is entered
>> bridge vlan add dev wan vid 102 pvid untagged
>>
>> brctl show, ip link, bridge vlan, bridge link commands, etc. look all
>> the same, also /sys/class/net/br0/bridge, /sys/class/net/br1/bridge
>> settings
>>
>> Systemd config correct?
>> Any ideas?
> You should not have eth0.101 and eth0.102 to be enslaved in a bridge at
> all, this is what is causing the bridge to be confused. Remember what I
> wrote to you before, with the current b53 driver that does not have any
> tagging enabled the lanX interfaces and brX interfaces are only used for
> control and should not be used for passing any data. The only network
> device that will be passing data is eth0, which is why we need to set-up
> VLAN interfaces to pop/push the VLAN id accordingly.
>
> I have no idea why manual vs. systemd does not work but you can most
> certainly troubleshoot that by comparing the bridge/ip outputs.

So is that then the correct structure?

br1
- lan1 (with VID 101)
- lan2 (with VID 101)
- lan3 (with VID 101)
- lan4 (with VID 101)

brlan
- eth0.101
- wlan0 (currently not active, could be optimized without bridge but for 
future comfort)

br2
- wan (with VID 102) (could be optimized without bridge but for future 
comfort)
- future1

brwan
- eth0.102 (could be optimized without bridge but for future comfort)
- future2

Ad systemd vs. manual config: As I said I didn't find any difference in 
the bridge/ip outputs. As they are broken (see other message) maybe 
something else is broken, too.

Thnx.

Ciao,
Gerhard