loss of connectivity after enabling vlan_filtering

loss of connectivity after enabling vlan_filtering

[vtolkm]

* DSA MV88E6060
* iproute2 v.5.0.0-2.0
* OpenWRT 19.07 with kernel 4.14.131 armv7l
_______

after

# bridge v a dev {bridge} self vid {n} untagged pvid

or with the device enslaved in the br

# bridge v a dev {device} vid {n} untagged pvid

I am hitting a roadblock when executing

# sysctl -w /sys/class/net/{bridge}/bridge/vlan_filtering=1

there is immediate loss of connectivity with the node until

# sysctl -w /sys/class/net/{bridge}/bridge/vlan_filtering=0

Since writing here I apparently trust that above is unexpected and I
cannot figure out what is (going) wrong.

Tried some variation (enabling VID on the client when appropriate) but
having met the same outcome.

# bridge v a dev {bridge} self vid {n} untagged
# bridge v a dev {bridge} self vid {n} pvid
# bridge v a dev {bridge} self vid {n}

# bridge v s

reflects any such change.

# ip -d l sh type bridge

br-mgt: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state
UP mode DEFAULT group default qlen 1000
    link/ether 1e:8e:c2:3c:b8:35 brd ff:ff:ff:ff:ff:ff promiscuity 0
    bridge forward_delay 200 hello_time 200 max_age 2000 ageing_time
30000 stp_state 0 priority 32767 vlan_filtering 0 vlan_protocol 802.1Q
bridge_id 7fff.1E:8E:C2:3C:B8:35 designated_root 7fff.1E:8E:C2:3C:B8:35
root_port 0 root_path_cost 0 topology_change 0 topology_change_detected
0 hello_timer    0.00 tcn_timer    0.00 topology_change_timer    0.00
gc_timer  168.58 vlan_default_pvid 1 vlan_stats_enabled 0 group_fwd_mask
0 group_address 01:80:c2:00:00:00 mcast_snooping 0 mcast_router 1
mcast_query_use_ifaddr 0 mcast_querier 0 mcast_hash_elasticity 4
mcast_hash_max 512 mcast_last_member_count 2 mcast_startup_query_count 2
mcast_last_member_interval 100 mcast_membership_interval 26000
mcast_querier_interval 25500 mcast_query_interval 12500
mcast_query_response_interval 1000 mcast_startup_query_interval 3125
mcast_stats_enabled 0 mcast_igmp_version 2 mcast_mld_version 1
nf_call_iptables 0 nf_call_ip6tables 0 nf_call_arptables 0 addrgenmode
stable_secret numtxqueues 1 numrxqueues 1 gso_max_size 65536
gso_max_segs 65535

______________________

* kernel conf
---
CONFIG_NETFILTER=y
CONFIG_NETFILTER_ADVANCED=y
CONFIG_BRIDGE_NETFILTER=m
CONFIG_NETFILTER_INGRESS=y
CONFIG_NETFILTER_NETLINK=m
CONFIG_NETFILTER_FAMILY_BRIDGE=y
CONFIG_NETFILTER_FAMILY_ARP=y
# CONFIG_NETFILTER_NETLINK_ACCT is not set
CONFIG_NETFILTER_NETLINK_QUEUE=m
CONFIG_NETFILTER_NETLINK_LOG=m
# CONFIG_NETFILTER_NETLINK_GLUE_CT is not set
CONFIG_IP_NF_MATCH_RPFILTER=m
CONFIG_IP_NF_FILTER=m
CONFIG_IP_NF_ARPFILTER=m
CONFIG_IP6_NF_MATCH_RPFILTER=m
CONFIG_IP6_NF_FILTER=m
CONFIG_BRIDGE_EBT_T_FILTER=m
CONFIG_ATM_BR2684_IPFILTER=y
CONFIG_BRIDGE_VLAN_FILTERING=y
CONFIG_HAVE_NET_DSA=y
CONFIG_NET_DSA=y
CONFIG_NET_DSA_TAG_DSA=y
CONFIG_NET_DSA_TAG_EDSA=y
CONFIG_NET_DSA_TAG_TRAILER=y
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
# CONFIG_NET_DSA_BCM_SF2 is not set
# CONFIG_NET_DSA_LOOP is not set
# CONFIG_NET_DSA_MT7530 is not set
CONFIG_NET_DSA_MV88E6060=y
CONFIG_NET_DSA_MV88E6XXX=y
CONFIG_NET_DSA_MV88E6XXX_GLOBAL2=y
# CONFIG_NET_DSA_QCA8K is not set
# CONFIG_NET_DSA_SMSC_LAN9303_I2C is not set
# CONFIG_NET_DSA_SMSC_LAN9303_MDIO is not set
# CONFIG_HNS_DSAF is not set
CONFIG_PPP_FILTER=y
CONFIG_IPPP_FILTER=y

Re: loss of connectivity after enabling vlan_filtering

[Andrew Lunn]

On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
> * DSA MV88E6060
> * iproute2 v.5.0.0-2.0
> * OpenWRT 19.07 with kernel 4.14.131 armv7l

The mv88e6060 driver is very simple. It has no support for VLANs. It
does not even have support for offloading bridging between ports to
the switch.

The data sheet for this device is open. So if you want to hack on the
driver, you could do.

	Andrew

Re: loss of connectivity after enabling vlan_filtering

[vtolkm]

On 30/06/2019 00:49, Andrew Lunn wrote:
> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
>> * DSA MV88E6060
>> * iproute2 v.5.0.0-2.0
>> * OpenWRT 19.07 with kernel 4.14.131 armv7l
> The mv88e6060 driver is very simple. It has no support for VLANs. It
> does not even have support for offloading bridging between ports to
> the switch.
>
> The data sheet for this device is open. So if you want to hack on the
> driver, you could do.
>
> 	Andrew

Are you sure? That is a bit confusing after reading
https://lore.kernel.org/patchwork/patch/575746/

Re: loss of connectivity after enabling vlan_filtering

[Andrew Lunn]

On Sun, Jun 30, 2019 at 01:04:50AM +0200, vtolkm@googlemail.com wrote:
> 
> On 30/06/2019 00:49, Andrew Lunn wrote:
> > On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
> >> * DSA MV88E6060
> >> * iproute2 v.5.0.0-2.0
> >> * OpenWRT 19.07 with kernel 4.14.131 armv7l
> > The mv88e6060 driver is very simple. It has no support for VLANs. It
> > does not even have support for offloading bridging between ports to
> > the switch.
> >
> > The data sheet for this device is open. So if you want to hack on the
> > driver, you could do.
> >
> > 	Andrew
> 
> Are you sure? That is a bit confusing after reading
> https://lore.kernel.org/patchwork/patch/575746/

Quoting that patch:

	This commit implements the switchdev operations to add, delete
	and dump VLANs for the Marvell 88E6352 and compatible switch
	chips.

Vivien added support for the 6352. That uses the mv88e6xxx driver, not
the mv88e6060. And by compatible switches, he meant those in the 6352
family, so 6172 6176 6240 6352 and probably the 6171 6175 6350 6351.

	Andrew

Re: loss of connectivity after enabling vlan_filtering

[vtolkm]

On 30/06/2019 01:11, Andrew Lunn wrote:
> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vtolkm@googlemail.com wrote:
>> On 30/06/2019 00:49, Andrew Lunn wrote:
>>> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
>>>> * DSA MV88E6060
>>>> * iproute2 v.5.0.0-2.0
>>>> * OpenWRT 19.07 with kernel 4.14.131 armv7l
>>> The mv88e6060 driver is very simple. It has no support for VLANs. It
>>> does not even have support for offloading bridging between ports to
>>> the switch.
>>>
>>> The data sheet for this device is open. So if you want to hack on the
>>> driver, you could do.
>>>
>>> 	Andrew
>> Are you sure? That is a bit confusing after reading
>> https://lore.kernel.org/patchwork/patch/575746/
> Quoting that patch:
>
> 	This commit implements the switchdev operations to add, delete
> 	and dump VLANs for the Marvell 88E6352 and compatible switch
> 	chips.
>
> Vivien added support for the 6352. That uses the mv88e6xxx driver, not
> the mv88e6060. And by compatible switches, he meant those in the 6352
> family, so 6172 6176 6240 6352 and probably the 6171 6175 6350 6351.
>
> 	Andrew

A simple soul might infer that mv88e6xxx includes MV88E6060, at least
that happened to me apparently (being said simpleton).
That may as it be, and pardon my continued ignorance, how is it
explained then that a command as

# bridge v a dev {bridge} self vid {n} untagged pvid

reflects in

# bridge v s
a/o
# bridge mo

?

If the commands are not implemented one would expect them to fail in the
first place or not reflecting a change at all?

Re: loss of connectivity after enabling vlan_filtering

[vtolkm]

On 30/06/2019 01:23, vtolkm@gmail.com wrote:
> On 30/06/2019 01:11, Andrew Lunn wrote:
>> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vtolkm@googlemail.com wrote:
>>> On 30/06/2019 00:49, Andrew Lunn wrote:
>>>> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
>>>>> * DSA MV88E6060
>>>>> * iproute2 v.5.0.0-2.0
>>>>> * OpenWRT 19.07 with kernel 4.14.131 armv7l
>>>> The mv88e6060 driver is very simple. It has no support for VLANs. It
>>>> does not even have support for offloading bridging between ports to
>>>> the switch.
>>>>
>>>> The data sheet for this device is open. So if you want to hack on the
>>>> driver, you could do.
>>>>
>>>> 	Andrew
>>> Are you sure? That is a bit confusing after reading
>>> https://lore.kernel.org/patchwork/patch/575746/
>> Quoting that patch:
>>
>> 	This commit implements the switchdev operations to add, delete
>> 	and dump VLANs for the Marvell 88E6352 and compatible switch
>> 	chips.
>>
>> Vivien added support for the 6352. That uses the mv88e6xxx driver, not
>> the mv88e6060. And by compatible switches, he meant those in the 6352
>> family, so 6172 6176 6240 6352 and probably the 6171 6175 6350 6351.
>>
>> 	Andrew
> A simple soul might infer that mv88e6xxx includes MV88E6060, at least
> that happened to me apparently (being said simpleton).
> That may as it be, and pardon my continued ignorance, how is it
> explained then that a command as
>
> # bridge v a dev {bridge} self vid {n} untagged pvid
>
> reflects in
>
> # bridge v s
> a/o
> # bridge mo
>
> ?
>
> If the commands are not implemented one would expect them to fail in the
> first place or not reflecting a change at all?
>
>

As stated in the initial message - kernel conf

CONFIG_NET_DSA_MV88E6060=y
CONFIG_NET_DSA_MV88E6XXX=y
CONFIG_NET_DSA_MV88E6XXX_GLOBAL2=y

Re: loss of connectivity after enabling vlan_filtering

[vtolkm]

On 30/06/2019 02:37, vtolkm@gmail.com wrote:
> On 30/06/2019 01:23, vtolkm@gmail.com wrote:
>> On 30/06/2019 01:11, Andrew Lunn wrote:
>>> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vtolkm@googlemail.com wrote:
>>>> On 30/06/2019 00:49, Andrew Lunn wrote:
>>>>> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
>>>>>> * DSA MV88E6060
>>>>>> * iproute2 v.5.0.0-2.0
>>>>>> * OpenWRT 19.07 with kernel 4.14.131 armv7l
>>>>> The mv88e6060 driver is very simple. It has no support for VLANs. It
>>>>> does not even have support for offloading bridging between ports to
>>>>> the switch.
>>>>>
>>>>> The data sheet for this device is open. So if you want to hack on the
>>>>> driver, you could do.
>>>>>
>>>>> 	Andrew
>>>> Are you sure? That is a bit confusing after reading
>>>> https://lore.kernel.org/patchwork/patch/575746/
>>> Quoting that patch:
>>>
>>> 	This commit implements the switchdev operations to add, delete
>>> 	and dump VLANs for the Marvell 88E6352 and compatible switch
>>> 	chips.
>>>
>>> Vivien added support for the 6352. That uses the mv88e6xxx driver, not
>>> the mv88e6060. And by compatible switches, he meant those in the 6352
>>> family, so 6172 6176 6240 6352 and probably the 6171 6175 6350 6351.
>>>
>>> 	Andrew
>> A simple soul might infer that mv88e6xxx includes MV88E6060, at least
>> that happened to me apparently (being said simpleton).
>> That may as it be, and pardon my continued ignorance, how is it
>> explained then that a command as
>>
>> # bridge v a dev {bridge} self vid {n} untagged pvid
>>
>> reflects in
>>
>> # bridge v s
>> a/o
>> # bridge mo
>>
>> ?
>>
>> If the commands are not implemented one would expect them to fail in the
>> first place or not reflecting a change at all?
>>
>>
> As stated in the initial message - kernel conf
>
> CONFIG_NET_DSA_MV88E6060=y
> CONFIG_NET_DSA_MV88E6XXX=y
> CONFIG_NET_DSA_MV88E6XXX_GLOBAL2=y
>

Just figured that it is a  Marvell 88E6176-TFJ2. Thus that cannot be the
cause, also considering the that the commands are executing and changes
being reflected.

However, the loss of access to the node is a mystery.

Apparently the filter is doing its job as in isolating access to the
bridge if connecting though an enslaved device.
And yet the bridge is still fully accessible from other devices that or
not enslaved by that bridge. As if the filter is inverted.

Re: loss of connectivity after enabling vlan_filtering

[vtolkm]

On 30/06/2019 03:13, vtolkm@gmail.com wrote:
> On 30/06/2019 02:37, vtolkm@gmail.com wrote:
>> On 30/06/2019 01:23, vtolkm@gmail.com wrote:
>>> On 30/06/2019 01:11, Andrew Lunn wrote:
>>>> On Sun, Jun 30, 2019 at 01:04:50AM +0200, vtolkm@googlemail.com wrote:
>>>>> On 30/06/2019 00:49, Andrew Lunn wrote:
>>>>>> On Sun, Jun 30, 2019 at 12:01:38AM +0200, vtolkm@googlemail.com wrote:
>>>>>>> * DSA MV88E6060
>>>>>>> * iproute2 v.5.0.0-2.0
>>>>>>> * OpenWRT 19.07 with kernel 4.14.131 armv7l
>>>>>> The mv88e6060 driver is very simple. It has no support for VLANs. It
>>>>>> does not even have support for offloading bridging between ports to
>>>>>> the switch.
>>>>>>
>>>>>> The data sheet for this device is open. So if you want to hack on the
>>>>>> driver, you could do.
>>>>>>
>>>>>> 	Andrew
>>>>> Are you sure? That is a bit confusing after reading
>>>>> https://lore.kernel.org/patchwork/patch/575746/
>>>> Quoting that patch:
>>>>
>>>> 	This commit implements the switchdev operations to add, delete
>>>> 	and dump VLANs for the Marvell 88E6352 and compatible switch
>>>> 	chips.
>>>>
>>>> Vivien added support for the 6352. That uses the mv88e6xxx driver, not
>>>> the mv88e6060. And by compatible switches, he meant those in the 6352
>>>> family, so 6172 6176 6240 6352 and probably the 6171 6175 6350 6351.
>>>>
>>>> 	Andrew
>>> A simple soul might infer that mv88e6xxx includes MV88E6060, at least
>>> that happened to me apparently (being said simpleton).
>>> That may as it be, and pardon my continued ignorance, how is it
>>> explained then that a command as
>>>
>>> # bridge v a dev {bridge} self vid {n} untagged pvid
>>>
>>> reflects in
>>>
>>> # bridge v s
>>> a/o
>>> # bridge mo
>>>
>>> ?
>>>
>>> If the commands are not implemented one would expect them to fail in the
>>> first place or not reflecting a change at all?
>>>
>>>
>> As stated in the initial message - kernel conf
>>
>> CONFIG_NET_DSA_MV88E6060=y
>> CONFIG_NET_DSA_MV88E6XXX=y
>> CONFIG_NET_DSA_MV88E6XXX_GLOBAL2=y
>>
> Just figured that it is a  Marvell 88E6176-TFJ2. Thus that cannot be the
> cause, also considering the that the commands are executing and changes
> being reflected.
>
> However, the loss of access to the node is a mystery.
>
> Apparently the filter is doing its job as in isolating access to the
> bridge if connecting though an enslaved device.
> And yet the bridge is still fully accessible from other devices that or
> not enslaved by that bridge. As if the filter is inverted.
>

The node's kernel log is showing during boot time repeated entries:

mv88e6085 f1072004.mdio-mii:10 lan{n}: configuring for phy/gmii link mode
mv88e6085 f1072004.mdio-mii:10: p3: hw VLAN 1 already used by br-{n}

Could there be a correlation with the described issue?

Is there way to debug the issue otherwise?

Re: loss of connectivity after enabling vlan_filtering

[Vivien Didelot]

On Sun, 30 Jun 2019 01:23:02 +0200, vtolkm@googlemail.com wrote:
> A simple soul might infer that mv88e6xxx includes MV88E6060, at least
> that happened to me apparently (being said simpleton).

I agree that is confusing, that is why I don't like the 'xxx' naming
convention in general, found in many drivers. I'd prefer to stick with a
reference model, or product category, like soho in this case. But it was
initially written like this, so no reason to change its name now. I still
plan to merge mv88e6060 into mv88e6xxx, but it is unfortunately low priority
because I still don't have a platform with a 88E6060 on it.

Thanks,

	Vivien

Re: loss of connectivity after enabling vlan_filtering

[™֟☻̭҇ Ѽ ҉ ®]

On 05/07/2019 17:29, Vivien Didelot wrote:
> On Sun, 30 Jun 2019 01:23:02 +0200, vtolkm@googlemail.com wrote:
>> A simple soul might infer that mv88e6xxx includes MV88E6060, at least
>> that happened to me apparently (being said simpleton).
> I agree that is confusing, that is why I don't like the 'xxx' naming
> convention in general, found in many drivers. I'd prefer to stick with a
> reference model, or product category, like soho in this case. But it was
> initially written like this, so no reason to change its name now. I still
> plan to merge mv88e6060 into mv88e6xxx, but it is unfortunately low priority
> because I still don't have a platform with a 88E6060 on it.
>
> Thanks,
>
> 	Vivien

At long last discovered (accidentality) what causes the loss of 
connectivity when enabling vlan_filtering, the node being dual-core and 
each core providing a port facing the switchdev:

cpu0 - eht0 [RGMII] <--- > switchdev port 6
cpu1 - eth1 [RGMII] <--- > switchdev port 5

If only one of the CPU ports is connected to the respective switchdev 
port connectivity to the node gets severed when enabling vlan_filtering.
With both CPU ports connected to the respective switchdev ports 
connectivity remains uninterrupted to the node when enabling 
vlan_filtering.

Re: loss of connectivity after enabling vlan_filtering

[™֟☻̭҇ Ѽ ҉ ®]

On 14/01/2020 21:33, ™֟☻̭҇ Ѽ ҉ ® wrote:
> On 05/07/2019 17:29, Vivien Didelot wrote:
>> On Sun, 30 Jun 2019 01:23:02 +0200, vtolkm@googlemail.com wrote:
>>> A simple soul might infer that mv88e6xxx includes MV88E6060, at least
>>> that happened to me apparently (being said simpleton).
>> I agree that is confusing, that is why I don't like the 'xxx' naming
>> convention in general, found in many drivers. I'd prefer to stick with a
>> reference model, or product category, like soho in this case. But it was
>> initially written like this, so no reason to change its name now. I 
>> still
>> plan to merge mv88e6060 into mv88e6xxx, but it is unfortunately low 
>> priority
>> because I still don't have a platform with a 88E6060 on it.
>>
>> Thanks,
>>
>>     Vivien
>
> At long last discovered (accidentality) what causes the loss of 
> connectivity when enabling vlan_filtering, the node being dual-core 
> and each core providing a port facing the switchdev:
>
> cpu0 - eht0 [RGMII] <--- > switchdev port 6
> cpu1 - eth1 [RGMII] <--- > switchdev port 5
>
> If only one of the CPU ports is connected to the respective switchdev 
> port connectivity to the node gets severed when enabling vlan_filtering.
> With both CPU ports connected to the respective switchdev ports 
> connectivity remains uninterrupted to the node when enabling 
> vlan_filtering.

The WIP patch at the downstream distro that remedies the issue for the 
particular device (dsa-multi-cpu) is accessible here:

https://gitlab.labs.nic.cz/turris/turris-build/commit/b440de75ba0f4a8dbfb530fcae2a821f26cde2a8