--- 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.
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).
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.
If it's not too much to ask, could you share your firmware file/installer? I managed to make it work using another sysupgrade.itb file I found around here. However, it broke my Wifi about every 10 min after running it. So, I had to revert back. Unfortunately, I don't know to build an installer myself
I also managed to make it work with Dango installer version 0.6.0 but I guess I installed a package, and it broke down again the upnp functionality. I am not sure what happens to the firewall configuration, but I think that changing the ip range from 192.168.1.1 to 192.168.5.1 for example, or maybe just adding the SQM packages, breaks down the upnp functionality.
Goodnight all ! I have two questions about this belkin rt3200 device which I have in the next version which will take place around March 20, will there still be the Qosify package in the integration of the rt3200 or will you still have to use snapshot and finally second question is qosify for those who use it compatible with sfo software offloading? @nbd thanks for all work everybody and i'm very happy for soon next major release
There is no reason to wait for an official release, the snapshots have been rock solid for me. I cannot answer your Qosify question about software offloading.
Whatever is in snapshots now, has a good chance of ending up in the next release. Removal of individual packages from a release would be an individual decision and relatively unlikely.
Hey all. Just got myself the ea8450 and thought it would be easy-peasy to drop in the router replacement for my other older linksys ea6350 v3. I followed the flash guide and all went fine, even did a full backup of my flash just in case. No bricking here.
However, my WAN would not populate an IP from my cable modem. LAN seems to be fine (at least I think). Is something missing out of the box from the dangowrt install method? His last release shows OpenWrt SNAPSHOT r18646-3869ccbcc8.
Wondering if I'm just not enabling some silly little checkbox somewhere that's preventing my router from getting a lease from the modem? As it stands, I can SSH in and visit the webUI just fine, but no internet connection. ;/ I tried to visit some generic guides on OpenWRT but none seem to be applying. I can confirm that I can't ping anything out from the router e.g. google.com. Thanks so much, sorry if it's too trivial to ask here.
Some ISP modems / ISPs only provide IP address for one device identified by MAC. You might test powering off both the router and modem, waiting a few minutes, then powering first the modem and after it has booted, also the router.
I also see this behaviour when I need to reboot my E8450. I was told it was a known problem. There are times I had to cold boot the router (i.e. turn off the power and on again) but there are times a reboot will get the WAN IP back. Sometimes I don't get IPv6.
