Forgot the top part!
1 Like
I have been visiting this page for a few years now. How did I not notice this link? 
Thank you
New update for Marvell router wrt1900acs v2 !
Firmware version: 2.0.3.201002
Release date: May 1, 2020
- Added support for the Marvell A385 Rev. B0 chip
- General bug fixes
I'm with a WRT3200ACM, and the 04/26 build makes the wifi unusable: some phantom thing clogs up the traffic. If I connect to the router through it's LAN ports the speedtest is fine. I removed all wifi clients (quite a few). Everything was off and the wifi showed 60-100 Mbit traffic (Graphs -> Wireless -> ...). Does anyone experience the same? The router's CPU utilization didn't go over 3-5% though. I cannot understand this. I'll try to revert back to the earlier firmware.
1 Like
Do you have a link?
Being a little more specific: by 04/26 build I meant r13059. Now I reverted back to r12833, and the wifi speed is usable, but something is not quite right: it's still heavily bogged down. I stopped now smbd (this is a pure wifi router, no shares) and also ddns (also don't use it). I also discovered that adblock was errorring, and I force reinstalled it, that wiped the config file and now it's OK. Now a little more detail about this "bog down situation".
- If I hook straight to a LAN port of the router the Ookla speedtest shows 110Mbps, which is actually little more than the 100Mbps my plan supposed to provide. Last night with r13059 the speedtest through wifi was only 2-5 Mbps, which means basically unusable. Now with r12833 it's up to 50 Mbps, but then where does the extra 50-60 Mbps go?
- Well, I'll show real-time graph and statistics graphs of wlan0 and wlan1. These graphs show constant ~25Mbps traffic. Not consistent completely between the aggregated statistics graphs vs the real-time graphs, but they show massive (25 Mbps constant traffic is I'd call massive, especially when I don't have any device which would account for that). The CPU utilization is not high, the system load is low, and although you can see some spikes but those are me mucking around.
- I know what you think: why don't we actually peek into that traffic and see what is that? I couldn't resist to do that.
tcpdump -i wlan0 -l -U -s0 -n -q -c 500ortcpdump -i wlan1 -l -U -s0 -n -q -c 500should have filled the dump file in a blink of an eye if there's 25Mbps traffic. However, the dump lasted several seconds, and it showed completely boring stuff, nothing what I expected that 1.5K packets hauled around. So I'm absolutely dumbfounded. WTF is going on?
Real-time graphs:
Statistic graphs:
Other:
Once more: that massive 25Mbps traffic is in one hand phantom (because even tcpdump couldn't catch anything and CPU is not bogged) but on the other hand real because the speedtest really measures that 50-60Mbps lost bandwidth (if I maybe sum the wlan0 5G and the wlan1 2.4G phantom traffic it comes out to about 50 Mbps) if I compare it to the LAN connection.
Do you know how bad this change is for us with Armada 385? What use cases are relevant? That OpenWRT Dev said in his answer it makes no performance loss, but I doubt that. I mean it just uses half of the CPUs registers now, no? For the FPU unit at least, not sure how important that is I am not a CPU expert. But it sounds significant. What about something like OpenVPN bandwidth?
1 Like
What kind of CLIENT do you have?
As reported 4 days ago, I have experienced the same! My Wifi was unstable and the network speed slow. Reverted to the previous build. Also using a WRT3200ACM.
Interesting, much like the WRT3200ACM a few months ago, it seems Linksys is updating these routers for the first time in over 2 years.
So, really enjoying the DNSCryprt-proxyV2 operation these days, with some exceptions.
Due to the randomization of resolver servers, and the fact that international servers can be used, we are encountering random security alerts from various providers : "suspicious login from (not USA) detected, was this you?".. or random rejections from various content or streaming sites due to region restrictions. "access to context X (USA) is not allowed from (random country)."
Anyone else seeing this? Maybe I need to specify only a set of USA based servers to avoid this? Probably solves the content issue, but not the "suspicious login" if a server outside of my regional area is chosen.
I'm having the same issue at times. Are you running Firefox by any chance. They just started to roll out a version of DNS Cryprt in Firefox 76.0 using Cloudflare. It can be turned off in Firefox preferences, network settings, bottom of the page. Seems like this started when Firefox was updated to 76.0.
1 Like
Thing is will they update the WRT32X v1 or the WRT32XB. As you have pointed out the WRT3200ACM and now the WRT1900ACS v2 has got updates, so hopefully the WRT32X will.
1 Like
Hi Gremlin,
So i have tried what youve said, but not sure of the ifdev config you mentioned in the earlier post. Here is how my client file looks like.
dev ovpnc1
dev-type tun
ns-cert-type server
setenv opt tls-version-min 1.0 or-highest
reneg-sec 604800
sndbuf 0
rcvbuf 0
At he moment only one vpn is working, however I have managed to add ovpnc1 to an instance but it doesnt seem to be receiving any packets
I also get this in policybasedrouting
wan/pppoe-wan/125.235.249.188 ✓
LinodeVPN/opvnc0/172.27.232.29
aws/ovpnc1/0.0.0.0
and I have tried different variations even with your setup with both vpns on one firewall, but this is how i am trying now.
From the changelog, one of the things they have changes is:
From 7338dcaf9cc3996711dee78dac86d52a84056ce6 Mon Sep 17 00:00:00 2001
From: Dmitri Epshtein <dima@marvell.com>
Date: Thu, 13 Jul 2017 12:51:49 +0300
Subject: [PATCH 317/322] a38x: add support for A38x B0
Change-Id: I58f8f19005e9554d15f0fcaff003a6c557f9c115
Signed-off-by: Dmitri Epshtein <dima@marvell.com>
Reviewed-on: http://vgitil04.il.marvell.com:8080/41588
Reviewed-by: Neta Zur Hershkovits <neta@marvell.com>
Tested-by: Neta Zur Hershkovits <neta@marvell.com>
---
arch/arm/mach-mvebu/mvebu-soc-id.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-mvebu/mvebu-soc-id.h b/arch/arm/mach-mvebu/mvebu-soc-id.h
index 5405d49..2f35f4d 100644
--- linux-3.10.70.orig/arch/arm/mach-mvebu/mvebu-soc-id.h
+++ linux-3.10.70/arch/arm/mach-mvebu/mvebu-soc-id.h
@@ -45,6 +45,7 @@
/* Armada A38x Revision */
#define MV88F68xx_Z1_REV 0x0
#define MV88F68xx_A0_REV 0x4
+#define MV88F68xx_B0_REV 0xA
/* Armada KW2 ID */
#define MV88F6510_DEV_ID 0x6510
--
1.9.1
and
From df373de997cf8830eb33d48f0212fb7d2841ce4c Mon Sep 17 00:00:00 2001
From: Dmitri Epshtein <dima@marvell.com>
Date: Thu, 13 Jul 2017 12:53:52 +0300
Subject: [PATCH 318/322] a38x: net_dev: add support for A38x B0
Change-Id: I6343ca5c2febf692a060e3b9d39e2fdbb4383c65
Signed-off-by: Dmitri Epshtein <dima@marvell.com>
Reviewed-on: http://vgitil04.il.marvell.com:8080/41587
Reviewed-by: Neta Zur Hershkovits <neta@marvell.com>
Tested-by: Neta Zur Hershkovits <neta@marvell.com>
---
drivers/net/ethernet/mvebu_net/neta/net_dev/mv_netdev.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/mvebu_net/neta/net_dev/mv_netdev.c b/drivers/net/ethernet/mvebu_net/neta/net_dev/mv_netdev.c
index 879325b..15fbd6d 100644
--- linux-3.10.70.orig/drivers/net/ethernet/mvebu_net/neta/net_dev/mv_netdev.c
+++ linux-3.10.70/drivers/net/ethernet/mvebu_net/neta/net_dev/mv_netdev.c
@@ -4373,10 +4373,11 @@ static int mv_eth_neta_cap_verify(unsigned int neta_cap_bm)
case MV88F6W22_DEV_ID:
case MV88F6W23_DEV_ID:
if (((rev == MV88F68xx_Z1_REV) && (neta_cap_bm == MV_ETH_CAP_BM || neta_cap_bm == 0)) ||
- ((rev == MV88F68xx_A0_REV) && (neta_cap_bm == (MV_ETH_CAP_PNC | MV_ETH_CAP_BM) ||
- neta_cap_bm == MV_ETH_CAP_PNC ||
- neta_cap_bm == MV_ETH_CAP_BM ||
- neta_cap_bm == 0)))
+ (((rev == MV88F68xx_A0_REV) || (rev == MV88F68xx_B0_REV))
+ && (neta_cap_bm == (MV_ETH_CAP_PNC | MV_ETH_CAP_BM) ||
+ neta_cap_bm == MV_ETH_CAP_PNC ||
+ neta_cap_bm == MV_ETH_CAP_BM ||
+ neta_cap_bm == 0)))
return 0;
else
goto err;
--
1.9.1
As for the general bugfixes, still don't know.
Nothing really of interest on the drive's side as the mwlwifi firmware was not updated.
This patch will need to be adopted for kernel 5.4/4.19 and upstreamed for anyone who is going to buy a 1900ACS or 3200ACM this year of 2020. It is akin to releasing a version 1900ACSv2.1 or 3200ACMv1.1
Hi,
I setup mine mostly editing the config files via SSH.
The network interface should be setup as follows in the GUI:
My client file:
client
dev ovpnc1
dev-type tun
proto udp
remote 0.0.0.0 1194
resolv-retry infinite
remote-random
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ping 15
ping-restart 0
ping-timer-rem
reneg-sec 0
comp-lzo no
remote-cert-tls server
auth-user-pass secret
verb 3
pull-filter ignore redirect-gateway
fast-io
cipher AES-256-CBC
auth SHA512
1 Like