* loss of connectivity after enabling vlan_filtering @ 2019-06-29 22:01 vtolkm 2019-06-29 22:49 ` Andrew Lunn 0 siblings, 1 reply; 11+ messages in thread From: vtolkm @ 2019-06-29 22:01 UTC (permalink / raw) To: netdev * 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: loss of connectivity after enabling vlan_filtering 2019-06-29 22:01 loss of connectivity after enabling vlan_filtering vtolkm @ 2019-06-29 22:49 ` Andrew Lunn 2019-06-29 23:04 ` vtolkm 0 siblings, 1 reply; 11+ messages in thread From: Andrew Lunn @ 2019-06-29 22:49 UTC (permalink / raw) To: vtolkm; +Cc: netdev 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: loss of connectivity after enabling vlan_filtering 2019-06-29 22:49 ` Andrew Lunn @ 2019-06-29 23:04 ` vtolkm 2019-06-29 23:11 ` Andrew Lunn 0 siblings, 1 reply; 11+ messages in thread From: vtolkm @ 2019-06-29 23:04 UTC (permalink / raw) To: netdev; +Cc: Andrew Lunn 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/ ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: loss of connectivity after enabling vlan_filtering 2019-06-29 23:04 ` vtolkm @ 2019-06-29 23:11 ` Andrew Lunn 2019-06-29 23:23 ` vtolkm 0 siblings, 1 reply; 11+ messages in thread From: Andrew Lunn @ 2019-06-29 23:11 UTC (permalink / raw) To: vtolkm; +Cc: netdev 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: loss of connectivity after enabling vlan_filtering 2019-06-29 23:11 ` Andrew Lunn @ 2019-06-29 23:23 ` vtolkm 2019-06-30 0:37 ` vtolkm 2019-07-05 17:29 ` Vivien Didelot 0 siblings, 2 replies; 11+ messages in thread From: vtolkm @ 2019-06-29 23:23 UTC (permalink / raw) To: Andrew Lunn; +Cc: netdev 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: loss of connectivity after enabling vlan_filtering 2019-06-29 23:23 ` vtolkm @ 2019-06-30 0:37 ` vtolkm 2019-06-30 1:13 ` vtolkm 2019-07-05 17:29 ` Vivien Didelot 1 sibling, 1 reply; 11+ messages in thread From: vtolkm @ 2019-06-30 0:37 UTC (permalink / raw) To: netdev; +Cc: Andrew Lunn 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: loss of connectivity after enabling vlan_filtering 2019-06-30 0:37 ` vtolkm @ 2019-06-30 1:13 ` vtolkm 2019-06-30 7:46 ` vtolkm 0 siblings, 1 reply; 11+ messages in thread From: vtolkm @ 2019-06-30 1:13 UTC (permalink / raw) To: netdev; +Cc: Andrew Lunn 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: loss of connectivity after enabling vlan_filtering 2019-06-30 1:13 ` vtolkm @ 2019-06-30 7:46 ` vtolkm 0 siblings, 0 replies; 11+ messages in thread From: vtolkm @ 2019-06-30 7:46 UTC (permalink / raw) To: netdev; +Cc: Andrew Lunn 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: loss of connectivity after enabling vlan_filtering 2019-06-29 23:23 ` vtolkm 2019-06-30 0:37 ` vtolkm @ 2019-07-05 17:29 ` Vivien Didelot 2020-01-14 21:33 ` ™֟☻̭҇ Ѽ ҉ ® 1 sibling, 1 reply; 11+ messages in thread From: Vivien Didelot @ 2019-07-05 17:29 UTC (permalink / raw) To: vtolkm; +Cc: Andrew Lunn, netdev 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: loss of connectivity after enabling vlan_filtering 2019-07-05 17:29 ` Vivien Didelot @ 2020-01-14 21:33 ` ™֟☻̭҇ Ѽ ҉ ® 2020-01-15 12:56 ` ™֟☻̭҇ Ѽ ҉ ® 0 siblings, 1 reply; 11+ messages in thread From: ™֟☻̭҇ Ѽ ҉ ® @ 2020-01-14 21:33 UTC (permalink / raw) To: netdev; +Cc: Vivien Didelot, Andrew Lunn 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: loss of connectivity after enabling vlan_filtering 2020-01-14 21:33 ` ™֟☻̭҇ Ѽ ҉ ® @ 2020-01-15 12:56 ` ™֟☻̭҇ Ѽ ҉ ® 0 siblings, 0 replies; 11+ messages in thread From: ™֟☻̭҇ Ѽ ҉ ® @ 2020-01-15 12:56 UTC (permalink / raw) To: netdev; +Cc: Vivien Didelot, Andrew Lunn 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-01-15 12:56 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-29 22:01 loss of connectivity after enabling vlan_filtering vtolkm 2019-06-29 22:49 ` Andrew Lunn 2019-06-29 23:04 ` vtolkm 2019-06-29 23:11 ` Andrew Lunn 2019-06-29 23:23 ` vtolkm 2019-06-30 0:37 ` vtolkm 2019-06-30 1:13 ` vtolkm 2019-06-30 7:46 ` vtolkm 2019-07-05 17:29 ` Vivien Didelot 2020-01-14 21:33 ` ™֟☻̭҇ Ѽ ҉ ® 2020-01-15 12:56 ` ™֟☻̭҇ Ѽ ҉ ®
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).