Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds

For those having issues with clicking unsaved changes producing Error 404, If you have a Adblocker installed in your browser please add your router IP to the whitelist, even with the fix that i thought would work, i only just noticed that 2 of the 3 web browsers i test with do not have Adblocker extensions installed whilst the one producing Error 404 did.

How do I revert to an openwrt version?

Noted. I'll focus on getting the most out within the limitations.

So using a clean laptop with Linux and windows on it freshly installed I tested Firefox Chrome(Chromium) Edge and internet explorer.

Firefox/Edge/IE all ran fast and snappy without issues, however Chrome and Chromium ran sluggish and constantly error 404.

Neither browser had adblockers enabled or installed or if they was installed out the box I removed them. So the issue with LUCI and the error 404 issue is down to chrome it would seem and nothing else.

Must add that the router was stocked, factory reset with the 60/60/60 then OpenWRT cleanly installed again and configure from scratch.

1 Like

Hello at all!
First thx @davidc502 for these builds, great stuff!

Today I updated my system after a very long time, idk exactly the build I was on I only checked kernel and it was 4.14 :smiley:
Ok, now my problem:
I use my wrt1900acs as openvpn client and I got about 100 mbps download speed, of which I was very happy.
Now after the update (I didn't change my config at all) I only get like 40 mbps at best :frowning:
I already read a comment where one user said some hw crypto engine changed and one should use option engine 'devcrypto' in ovpn client config, which I did but it made no difference.
Can you help me get back to my great 100mbps again?
Can I maybe deactivate some services/processes that maybe take up too much of cpu?
My knowledge here is limited, but I'm grateful for any suggestion or test I could run to figure out why the performance dropped.

@solidus1983 - Good info and thank you for all your hard work on the ATMaterial theme. Been using it without issues on my WRT3200ACM via the latest release of Firefox.

I do not use the Edge browser, but you may want to keep an eye on the current "Edge Beta" and future Edge releases as they are now based on Chromium. Thanks again.

@trohn_javolta

So, if you go to advanced reboot, select the previous build, and boot over to it. Please do a speedtest, and then boot back over to the new build and test again.

Just want to be sure of the differences here. IDK, perhaps you did a speedtest just prior to the upgrade?

Best Regards,

David

Ooops, sry I can't do that :confused:
I always keep ofw on one partition and lede/openwrt on the other partition.
So prior installing the new build, I booted to linksys ofw and flashed your latest build.
After that I restored the list of packages I backed up before and then I restored the backup I made prior via webif. I folllowed this tut:

Because I read multiple times, that one should never choose "write new firmware" via backup/firmware update menu and keep the current config.
Was that completely wrong?

...But I still have backup.tgz archive from old build, could I somehow figure the build out from that?

Adopting something like this, written for the nbg6817, should be much easier (yes, the actual implementation would differ, adapted to Linksys devices):

@trohn_javolta

I briefly looked it over, and appears okay, so I don't think anything is wrong.

There have been tons of changes since 4.14, so it would be impossible to say this change is what is lending to a slower speed. So, I guess through trial and error, have you tried other locations to help determine if you are getting better speeds from one location vs another location?

Who do you use for your VPN access?

Ok, that's a bummer :confused:
I use torguard.
May I send you my ovpn client config and log? Or can i run some openssl cryptotest for comparison?

hold up there is a new build out ?

Nope, not yet. This Saturday unless needed sooner?

I use Torguard as well, and right now I'm able to connect, but nothing is going through the tunnel. Torguard is in preparation and transitioning to TLS 1.3, but don't think that is causing issues with your set up.

Can you share your VPN config please. Once I get mine going I'll see if I can do some tests.

Wed Aug 21 19:49:56 2019 us=177200 TLS_ERROR: BIO read tls_read_plaintext error
Wed Aug 21 19:49:56 2019 us=177246 TLS Error: TLS object -> incoming plaintext read error
Wed Aug 21 19:49:56 2019 us=177288 TLS Error: TLS handshake failed
Wed Aug 21 19:49:56 2019 us=177506 TCP/UDP: Closing socket
Wed Aug 21 19:49:56 2019 us=177584 SIGUSR1[soft,tls-error] received, process restarting
Wed Aug 21 19:49:56 2019 us=177645 Restart pause, 40 second(s)

@trohn_javolta

Okay... My issue was an old certificate. Once I downloaded the new certificate it works again.

Please try this location on port 1912 atl.east.usa.torguardvpnaccess.com

Other sites like Chicago I'm getting 40mbps down, but with Atlanta I'm getting 60mbps down. See if your speeds are any different with Atlanta.

EDIT

I'm getting the exact same speed out of my PC with the torguard client.

Had the same cert error, I recently changed to the new cert.
Trying with the same port and server speed is even worse:

root@hc2:~# speedtest-cli
Retrieving speedtest.net configuration...
Testing from QuadraNet (104.223.94.58)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Speedtest.net (Atlanta, GA) [0.81 km]: 127.472 ms
Testing download speed................................................................................
Download: 26.03 Mbit/s
Testing upload speed....................................................................................................
Upload: 16.92 Mbit/s

I normally use port 80 and server nl.torguardvpnaccess.com without tls_auth and SHA1.
Could you try again using port 80, SHA1 and without tls_auth?
And the results you get, is this with Wrt1900acs? Does it max. out your bandwith or what's your normal bandwith?
Mine is currently 200 Mbps down 20 up. And as I said, before the update I got 80-100 Mbps down. No idea how it could drop like this..

Here's my current client conf:

config openvpn 'torguard'
	option client '1'
	option dev 'tun0'
	option proto 'udp'
	option resolv_retry 'infinite'
	option nobind '1'
	option persist_key '1'
	option persist_tun '1'
	option ca '**********************'
	option route_nopull '1'
	option remote_cert_tls 'server'
	option cipher 'AES-128-CBC'
	option compress 'lzo'
	option verb '3'
	option fast_io '1'
	option auth_user_pass '********************'
	option remote_random '0'
	option auth 'SHA256'
	option reneg_sec '0'
	list remote 'atl.east.usa.torguardvpnaccess.com 1912'
	option sndbuf '393216'
	option rcvbuf '393216'
	option fragment '0'
	option mssfix '0'
	option mute_replay_warnings '1'
	option auth_nocache '1'
	option enabled '1'
	option log '/tmp/openvpnclient.log'
	option engine 'devcrypto'
	option tls_auth '*******************'

And here is the clientlog. The push-options errors are because of my vpnserver I think, but they were also there before.

Thu Aug 22 12:31:13 2019 OpenVPN 2.4.7 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
Thu Aug 22 12:31:13 2019 library versions: OpenSSL 1.1.1c  28 May 2019, LZO 2.10
Thu Aug 22 12:31:13 2019 Initializing OpenSSL support for engine 'devcrypto'
Thu Aug 22 12:31:13 2019 Outgoing Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Thu Aug 22 12:31:13 2019 Incoming Control Channel Authentication: Using 256 bit message hash 'SHA256' for HMAC authentication
Thu Aug 22 12:31:13 2019 TCP/UDP: Preserving recently used remote address: [AF_INET]104.223.94.58:1912
Thu Aug 22 12:31:13 2019 Socket Buffers: R=[163840->327680] S=[163840->327680]
Thu Aug 22 12:31:13 2019 UDP link local: (not bound)
Thu Aug 22 12:31:13 2019 UDP link remote: [AF_INET]104.223.94.58:1912
Thu Aug 22 12:31:13 2019 TLS: Initial packet from [AF_INET]104.223.94.58:1912, sid=d2b3c3f6 f7ebd80f
Thu Aug 22 12:31:14 2019 VERIFY OK: depth=1, CN=TG-VPN-CA
Thu Aug 22 12:31:14 2019 VERIFY KU OK
Thu Aug 22 12:31:14 2019 Validating certificate extended key usage
Thu Aug 22 12:31:14 2019 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Thu Aug 22 12:31:14 2019 VERIFY EKU OK
Thu Aug 22 12:31:14 2019 VERIFY OK: depth=0, CN=server
Thu Aug 22 12:31:14 2019 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1570', remote='link-mtu 1569'
Thu Aug 22 12:31:14 2019 WARNING: 'comp-lzo' is present in local config but missing in remote config, local='comp-lzo'
Thu Aug 22 12:31:14 2019 Control Channel: TLSv1.2, cipher TLSv1.2 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Thu Aug 22 12:31:14 2019 [server] Peer Connection Initiated with [AF_INET]104.223.94.58:1912
Thu Aug 22 12:31:16 2019 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Thu Aug 22 12:31:16 2019 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 1.1.1.1,dhcp-option DNS 1.0.0.1,route ***.***.***.***,topology net30,ping 5,ping-restart 30,compress,ifconfig ***.***.***.*** ***.***.***.***,peer-id 2,cipher AES-256-GCM'
Thu Aug 22 12:31:16 2019 Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])
Thu Aug 22 12:31:16 2019 Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Thu Aug 22 12:31:16 2019 Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Thu Aug 22 12:31:16 2019 Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS])
Thu Aug 22 12:31:16 2019 OPTIONS IMPORT: timers and/or timeouts modified
Thu Aug 22 12:31:16 2019 OPTIONS IMPORT: compression parms modified
Thu Aug 22 12:31:16 2019 OPTIONS IMPORT: --ifconfig/up options modified
Thu Aug 22 12:31:16 2019 OPTIONS IMPORT: peer-id set
Thu Aug 22 12:31:16 2019 OPTIONS IMPORT: adjusting link_mtu to 1625
Thu Aug 22 12:31:16 2019 OPTIONS IMPORT: data channel crypto options modified
Thu Aug 22 12:31:16 2019 Data Channel: using negotiated cipher 'AES-256-GCM'
Thu Aug 22 12:31:16 2019 Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Aug 22 12:31:16 2019 Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Thu Aug 22 12:31:16 2019 TUN/TAP device tun0 opened
Thu Aug 22 12:31:16 2019 TUN/TAP TX queue length set to 100
Thu Aug 22 12:31:16 2019 /sbin/ifconfig tun0 ***.***.***.*** pointopoint ***.***.***.*** mtu 1500
Thu Aug 22 12:31:16 2019 Initialization Sequence Completed

What I don't quite understand is why outgoing and incoming data channel says AES-256-GCM but I set cipher AES-128-CBC?... Or is this sth. totally different?

Hmm.. Now I tried with option engine devcrypto and without that. Speed is exactly the same. That leads me to think maybe hw crypto doesn't work? Idk..
On the other hand doing: openssl engine -t -ctells me it's available:

(dynamic) Dynamic engine loading support
     [ unavailable ]
(devcrypto) /dev/crypto engine
 [DES-CBC, DES-EDE3-CBC, AES-128-CBC, AES-192-CBC, AES-256-CBC, AES-128-ECB, AES-192-ECB, AES-256-ECB]
     [ available ]

@trohn_javolta

I can't get any better speeds out of my PC which is a 12 core 24 thread CPU with PCI Gen4 SSD and high speed RAM. Also, I've tried multiple locations and the speeds are generally slower still.

This isn't going to be a router configuration issue. Later today I'm going to go to the Torguard forums and see how many others are experiencing the same.

EDIT

One test you can execute is to run htop while running a speed test. You will notice CPU on the router is far from 100%.

Oh, you're right... Cpu for the openvpn process is at 50%. Tbh I just looked at the cpu load graph in webif and it seemed pretty high.
So likely an issue at torguards side.. :smiley: What a coincidence just right after I update my router :smile:

1 Like

Torguard is in the middle of doing network upgrades, as well as implementing IPv6 support and perfect forward secrecy TLS 1.3.

Will likely be several months before everything is back to normal.

1 Like