Belkin RT3200/Linksys E8450 WiFi AX discussion

No. My E8450 is running with learning enabled for now. Monitoring for issues.

Edit: Previously I tried add the wan port to br-lan and set it up with vid 2, with lan as 1. It’s not stable. I’ll loose IPv6 wan after a while. But that without the recent VLAN patches. So my E8450 is setup with vlan filtering for lan ports and bridge only.

Is it me or OpenWRT on this router, gives you mixed speed?
I tried the cake script, was getting a whopping 3mbps. then I try software AND hardware offloading with IRQ enabled both times (IRQ and cake, fyi). was okayish, getting around 400mbps. now no matter what I do, the speed is always slow. with the cake script or without. IRQ doesn't seem to help, well, not sure if it does at all.

I was testing with the waveform buffer bloat, with cake/sqm it would never go above 80mbps but on a speedtest site it was maxed out at 400mbps. I have a unlimited 1gbps line.

I tried with just packet sheering, IRQ and software offloading and it was around 500mbps. added hardware to that made no difference.

I purchased this router because it was recommended, now I'm starting to think it was £90 waste.

Thoughts?

hi everybody maybe can interested for bricked router :wink:

enjoy

1 Like

How are you hitting 1gbps with cake? Enlighten us. :wink:

1 Like

what is your connexion ? please give precision :wink:

I put below in startup script and testing. Hopefully this will resolve the wifi issue.

echo 0 > /sys/kernel/debug/ieee80211/phy0/aql_enable
echo 0 > /sys/kernel/debug/ieee80211/phy1/aql_enable
2 Likes

Hi @darksky we are already trying to collect "no connectivity" case in this thread no connectiviy issue thread.

Did you try SW and HW offloading with firewall4, only nftables and iptables removed? Think you can't run QoS then though.

1gbps. with the cake script, I get a max of 400/500mbps.

1 Like

is normal cpu max 500 with cake

witouth cake 1gbits

1 Like

Please try this patch

patch
--- a/drivers/net/dsa/mt7530.c
+++ b/drivers/net/dsa/mt7530.c
@@ -1193,7 +1193,7 @@ mt7530_port_bridge_join(struct dsa_switch *ds, int port,
 			   PCR_MATRIX_MASK, PCR_MATRIX(port_bitmap));
 	priv->ports[port].pm |= PCR_MATRIX(port_bitmap);
 
-	mt7530_clear(priv, MT7530_PSC_P(port), SA_DIS);
+	mt7530_rmw(priv, MT7530_PSC_P(port), SA_CNT_EN, MAC_SA_LRN);
 
 	/* Set to fallback mode for independent VLAN learning */
 	mt7530_rmw(priv, MT7530_PCR_P(port), PCR_PORT_VLAN_MASK,
@@ -1300,7 +1300,7 @@ mt7530_port_bridge_leave(struct dsa_switch *ds, int port,
 			   PCR_MATRIX(BIT(MT7530_CPU_PORT)));
 	priv->ports[port].pm = PCR_MATRIX(BIT(MT7530_CPU_PORT));
 
-	mt7530_set(priv, MT7530_PSC_P(port), SA_DIS);
+	mt7530_rmw(priv, MT7530_PSC_P(port), MAC_SA_LRN, SA_CNT_EN);
 
 	/* When a port is removed from the bridge, the port would be set up
 	 * back to the default as is at initial boot which is a VLAN-unaware
@@ -2714,7 +2714,7 @@ mt7530_setup(struct dsa_switch *ds)
 			   PCR_MATRIX_CLR);
 
 		/* Disable learning by default on all ports */
-		mt7530_set(priv, MT7530_PSC_P(i), SA_DIS);
+		mt7530_rmw(priv, MT7530_PSC_P(i), MAC_SA_LRN, SA_CNT_EN);
 
 		if (dsa_is_cpu_port(ds, i)) {
 			ret = mt753x_cpu_port_enable(ds, i);
@@ -2887,7 +2887,7 @@ mt7531_setup(struct dsa_switch *ds)
 			   PCR_MATRIX_CLR);
 
 		/* Disable learning by default on all ports */
-		mt7530_set(priv, MT7530_PSC_P(i), SA_DIS);
+		mt7530_rmw(priv, MT7530_PSC_P(i), MAC_SA_LRN, SA_CNT_EN);
 
 		mt7530_set(priv, MT7531_DBG_CNT(i), MT7531_DIS_CLR);
 
--- a/drivers/net/dsa/mt7530.h
+++ b/drivers/net/dsa/mt7530.h
@@ -294,6 +294,8 @@ enum mt7530_port_mode {
 
 /* Register for port security control */
 #define MT7530_PSC_P(x)			(0x200c + ((x) * 0x100))
+#define  MAC_SA_LRN			GENMASK(19, 8)
+#define  SA_CNT_EN			BIT(5)
 #define  SA_DIS				BIT(4)
 
 /* Register for port vlan control */

Instead of setting SA_DIS, this enables address learning counter SA_CNT_EN and sets the limit MAC_SA_LRN to 0.

How did you get 1gbps with cake above, then?

Isn’t this effectively does the same thing?

Edit: Forgot to add that I think the issue is likely with the CPU port. When I tried to upload to router, only the LAN ports and the CPU port is involved. The LAN ports being bridged will have learning enabled, while the CPU port is disabled. One of the LAN port is at 10mbps, one at 1000mbps while the other two is disconnected. This resulted in the client to bridge direction sped stuck at 10mbps.

In any case, I’m not convinced that the switch should disable address learning on its own. It is purpose built for such a task.

Yes. Just in another way, in case the SA_DIS bit is bugged.

Standalone switch ports should have address learning disabled.
As for the CPU port, refer to this discussion for the reason why assisted learning is required.

May I know the reason why? The switch needs to know how to route frames coming in from the stand-alone port and whether frames could be sent out from it based on the MAC-addresses that it can reach. Either the switch ARL table is auto-learned or it’s maintained by the CPU. Since it’s already built to learn, why disable it?

CPU ports is a VLAN aware switch should be VLAN tagged. Not sure why the discussion is discussing non tagged CPU port. AFAIK, CPU will have problem sending to more than 1 VLAN if it’s not tagged.

From my tests, I haven't been able to get more than ~500-600 mbps with Cake (Irqbalance, packet steering,etc.). I can, however, saturate a 1gbps cable connection (1gbps download, 50 mbps upload) with fq_codel though (using sqm).

1 Like

Ok, so just for a sanity check I did a clean install. Then, I installed the miniupnpd package (iptable), and updated the up range setting as you suggested. However, it didn’t work on my Nintendo Switch or PC. When I try using my verizon gateway and enable upnp, it does work on both devices so at least I can get a reference.

Have you successfully used this feature on your RT3200? If so, could you please share your config? I appreciate the help!

The concept of DSA is to register switch ports as native Linux netdev interfaces. As Linux don't perform address learning on standalone (not bridged) interfaces, the switch should not, either.

The standalone ports don't work like that. Frames received from standalone ports should always be forwarded to the CPU, and frames to be sent out of a standalone port is controlled by DSA TX tag which indicates the destination port. No MAC learning/lookup should be involved.

As I mentioned above, the destination port is indicated by DSA TX tag. VLAN lookup is not required.

If you still have questions, feel free to ask DSA maintainers.

I don't follow. My understanding of how 802.3 work is that learning is inherent in the protocol. It is either done by the netdev or the kernel, but it has to know. Typically both does it. When the kernel wants to send a frame out, it needs to know how where to send it to, and it learns the destination via ARP and stores it somewhere, and let it age. Unless the kernel sends out ARP for every frame (which will kill performance) it learns and store in its ARL/FDB table. When the netdev receives a frame, the ARL/FDB tables gets updated/created.

My understanding is that if the a switch port is configured to only forward to the CPU port for incoming frames, and no other ports, it doesn't matter whether learning is on or off. But in this case, disabling it for the mt7530/1 switch seems to have an effect on thruput.

It would seem to me (I most likely would be wrong ;-P) that DSA is still new, and likely many scenarios will need to be worked out. But a non-VLAN tagged port is impossible to reliably send data to more than 1 VLAN, as there's nothing in a frame to indicate which VLAN to send it to. The only piece of information is from the port's PVID. So if the switch supports VLAN, the CPU port have to be VLAN Tagged, unless the switch is only supporting 1 VLAN, in which case, is the same as no VLAN.

Now, coming back to this, I think I may want to re-look into the mt7530/1 code. This could be the reason why my IPv6 traffic is not stable when I configured the E8450 with more than 1 VLAN for the bridge, as recommended in the OpenWrt user guide.

It seems I have another difference from the default config, option external_iface 'wan' is uncommented. This and the above int_addr value are my only differences to the default upnpd config.

3 Likes