Topic: Update on Linksys WRT1900AC support

The content of this topic has been archived between 16 Sep 2014 and 7 May 2018. Unfortunately there are posts – most likely complete pages – missing.

Page 251 of 598

Post #6251

Vanav

11 Jul 2015, 01:37

northbound wrote:

Running trunk ver 46262 called 46263 according to buildbot. First cpu stall I have seen. If anyone is interested here is a link.
https://onedrive.live.com/redir?resid=E … file%2ctxt
build 46131 did not do this but it really ate the memory. I will have to try another build at least it seems like collectd was working for a change. This build went down yesterday also but everything locked tight no access. It seemed to last about 16 hrs both times.

I'm collecting backtraces and logs of halts here: https://github.com/kaloz/mwlwifi/issues … -103892374
Anyone who experience halts (https://github.com/kaloz/mwlwifi/issues/21) or disconnects (https://github.com/kaloz/mwlwifi/issues/20) can add comments to bring developer's attention.

Post #6252

gaga

11 Jul 2015, 08:11

belliash wrote:

gaga wrote:
belliash wrote:

What is your VPN performance?
What transfers do you get?
On my LG G4: ~30mbit/s

Interesting.
All I got here is about 12mbps

I think it could be even faster. Looking at the CPU stats I think my G4 is limited by that

Post #6253

jlynton

11 Jul 2015, 11:58

Hello, my first post here.

I used OpenWrt years back on my wrt54gs, and now have a wrt1900ac v1 that I would like to flash. The wiki page seems to suggest that file openwrt-15.05-rc2-mvebu-armada-xp-linksys-mamba-squashfs-factory.img includes LuCI, but I am not sure, can anyone corfirm?

Many thanks!

Post #6254

JW0914

11 Jul 2015, 15:02

jlynton wrote:

Hello, my first post here.
I used OpenWrt years back on my wrt54gs, and now have a wrt1900ac v1 that I would like to flash. The wiki page seems to suggest that file openwrt-15.05-rc2-mvebu-armada-xp-linksys-mamba-squashfs-factory.img includes LuCI, but I am not sure, can anyone corfirm?
Many thanks!

If I remember right from when I installed RC2, it does. Also, the config says it does as well. If it doesn't, it's a simple step to install it.

Post #6255

JW0914

11 Jul 2015, 17:27

gaga wrote:

belliash wrote:
gaga wrote:
On my LG G4: ~30mbit/s

Interesting.
All I got here is about 12mbps
I think it could be even faster. Looking at the CPU stats I think my G4 is limited by that

When you have a chance, could you read through the VPN Wiki and let me know if you think anything else should be added or clarified? Thanks =]

(Last edited by JW0914 on 11 Jul 2015, 17:28)

Post #6256

JW0914

11 Jul 2015, 18:26

@gaga If you're still unable to access your NAS, see if this makes any difference

Add

#--- OpenWRT's Subnet ---#
list push 'route 192.168.2.101 255.255.255.0'

Below

#--- DHCP Subnet ---#
list push 'route 192.168.1.0 255.255.255.0'

If that doesn't work, replace OpenWRT's subnet with

#--- Modem Subnet ---#
list push 'route 192.168.2.0 255.255.255.0'

If that still doesn't work, add back OpenWRT's along with the Modem's

Prior to doing that, I would check the output of OpenWRT's firewall and system logs after trying to access your NAS, as it has to be determined where the traffic is being blocked.

(Last edited by JW0914 on 11 Jul 2015, 18:33)

Post #6257

drawz

11 Jul 2015, 20:10

JW0914 wrote:

drawz wrote:
JW0914 wrote:
So I have HTTPS enabled and HTTP disabled for uhttpd... is there a way to make 192.168.1.1 auto load https://192.168.1.1?
I know it's possible, as most secure sites will autoload their HTTPS address even if their HTTP address is typed.... I'm just not sure how that works.
I think this feature was added in trunk recently
Does that imply that it's not possible in the RC2 build?

Not sure

Post #6258

northbound

11 Jul 2015, 23:33

Vanav wrote:

northbound wrote:
Running trunk ver 46262 called 46263 according to buildbot. First cpu stall I have seen. If anyone is interested here is a link.
https://onedrive.live.com/redir?resid=E … file%2ctxt
build 46131 did not do this but it really ate the memory. I will have to try another build at least it seems like collectd was working for a change. This build went down yesterday also but everything locked tight no access. It seemed to last about 16 hrs both times.
I'm collecting backtraces and logs of halts here: https://github.com/kaloz/mwlwifi/issues … -103892374
Anyone who experience halts (https://github.com/kaloz/mwlwifi/issues/21) or disconnects (https://github.com/kaloz/mwlwifi/issues/20) can add comments to bring developer's attention.

I do not believe that this has anything to do with those issues this was just a faulty build. Which is to be expected running trunk.
The version of trunk I am on now seems fine. Like I said it is the first cpu stall I have seen.

Post #6259

JW0914

12 Jul 2015, 00:22

gaga wrote:

JW0914 wrote:
Can you post the output of cat /etc/config/openvpn as managing the vpn from LuCI re-writes the config file and I'd like to compare your config from yesterday to the new config
config openvpn 'VPNserver'
    option enabled '1'
    option dev 'tun0'
    option topology 'subnet'
    option proto 'udp'
    option port '1194'
    option server '10.1.1.0 255.255.255.0'
    option ifconfig '10.1.1.1 255.255.255.0'
    list push 'route 192.168.1.0 255.255.255.0'
    list push 'dhcp-option DNS 192.168.1.1'
    list push 'dhcp-option WINS 192.168.1.1'
    list push 'dhcp-option DNS 8.8.8.8'
    list push 'dhcp-option DNS 8.8.4.4'
    list push 'dhcp-option NTP 129.6.15.30'
    list push 'sndbuf 393216'
    list push 'rcvbuf 393216'
    option cipher 'AES-256-CBC'
    option dh '/etc/openvpn/keys/dh2048.pem'
    option tls_auth '/etc/openvpn/keys/ta.key 0'
    option log '/tmp/openvpn.log'
    option status '/tmp/openvpn-status.log'
    option verb '7'
    option keepalive '10 120'
    option comp_lzo 'yes'
    option client_to_client '1'
    option persist_key '1'
    option persist_tun '1'
    option sndbuf '393216'
    option rcvbuf '393216'
    option fragment '0'
    option mssfix '0'
    option tun_mtu '24000'
    option user 'nobody'
    option group 'nogroup'
    option ca '/etc/openvpn/keys/ca.crt'
    option cert '/etc/openvpn/keys/my-server.crt'
    option key '/etc/openvpn/keys/my-server.key'
    option tls_server '1'
After it worked, I changed to UDP...
As of now I can't access my NAS, though. Need to figure out why...
I have the following setup:
ISP router
192.168.2.1
WRT1900
192.168.2.101
DNS 192.168.2.1
=> Serving as 192.168.1.1 from 192.168.1.2 - 192.168.1.150
NAS
192.168.1.10, DNS: 192.168.1.1
Now I get as a OpenVPN client the IP address 10.1.1.2 and thus, I can't reach my NAS. This is probably only a small issue, but I can't figure out what I need to do.
Any hints?

Scratch that, it's working, sort of. One problem remains: I can't access my SMB shares (Total Commander, ES File Explorer). Through Webbrowser it works, though. What's wrong?

In combination with my post earlier today, here's what I think may be happening (you'd have to view your firewall and system log to verify)

10.1.1.2 is assigned by the vpn server, which then tries to communicate with 192.168.1.10, however in order for traffic to 192.168.1.10 to be routed, it must first travel to 192.168.2.0, then to 192.168.2.101, on to 192.168.1.1, and finally 192.168.1.10.

Because of your setup, I'm almost positive either 192.168.2.0 or 192.168.2.101 (or both) need to be pushed routes via the vpn server. Try adding what I suggested here and see if that fixes the routing issue. If not, to know for certain where traffic is being blocked, you'd have to view the firewall and system logs. If you're running a firewall on your NAS, it'd be worth a look to see if the firewall shows any dropped or denied traffic from 10.1.1.2 (highly doubtful, but verify to be certain).

(Last edited by JW0914 on 12 Jul 2015, 00:25)

Post #6260

jlynton

12 Jul 2015, 06:31

JW0914 wrote:

jlynton wrote:
Hello, my first post here.
I used OpenWrt years back on my wrt54gs, and now have a wrt1900ac v1 that I would like to flash. The wiki page seems to suggest that file openwrt-15.05-rc2-mvebu-armada-xp-linksys-mamba-squashfs-factory.img includes LuCI, but I am not sure, can anyone corfirm?
Many thanks!
If I remember right from when I installed RC2, it does. Also, the config says it does as well. If it doesn't, it's a simple step to install it.

Thanks so much for your reply, I have it installed and set up now, LuCI is a joy after the linksys bloatware!

Post #6261

belliash

12 Jul 2015, 13:38

gaga wrote:

belliash wrote:
gaga wrote:
On my LG G4: ~30mbit/s

Interesting.
All I got here is about 12mbps
I think it could be even faster. Looking at the CPU stats I think my G4 is limited by that

Pretty strange because my router acts as a client.
OpenVPN server is installed on my personal server powered by Xeon L5630.
I have tried several options all the timem and all I get is around 12mbps (max 1.6MiB/s).
W/o VPN I can reach 100mbps...

Post #6262

JW0914

12 Jul 2015, 14:41

belliash wrote:

gaga wrote:
belliash wrote:

Interesting.
All I got here is about 12mbps
I think it could be even faster. Looking at the CPU stats I think my G4 is limited by that

Pretty strange because my router acts as a client.
OpenVPN server is installed on my personal server powered by Xeon L5630.
I have tried several options all the timem and all I get is around 12mbps (max 1.6MiB/s).
W/o VPN I can reach 100mbps...

What is the encryption level on your ssl certificates? Can you post your server and client configs (minus port #, DDNS, and keys if using xml in the configs).

Also:

What OS is your server running?
What processor, how much RAM, and is the NIC at least a 1Gbit?
What is the average CPU and RAM load when trying to access the VPN?
What brand and model of modem are you're using (unless you know the stream count for upstream/downstream)?
What type of internet service do you have and do you know what the ISP's downstream/upstream count is?
What file system is being used on your NAS (I'm assuming your server is an NAS), and what type of RAID are you using?

Downstream/upstream is not upload and download speed and the streams determine how fast your internet service will be (not the download speed of the service, but how fast the service will actually be). For example, in the U.S., Time Warner is a 16x4 ISP (16 download streams, 4 upload streams), while Comcast is either 8x4 or 8x2.

Think of it like a download manager, the more streams, the faster a file is downloaded/uploaded. While the ISP speed will never exceed 65mbps, it you have 16 streams and each is downloading at 41.85mbps, a 4.2MB file will download 16x faster than on a 1 stream service. You could also compare it to multi core CPUs.

Normally, an OpenVPN server running on a dedicated server before OpenWRT (modem --> server --> OpenWRT) should get upwards of 100 - 500mbps (~12.5 - 62.5MB/s) or greater, while after OpenWRT will vary depending on a myriad of factors, the most limiting of which is the AP OpenWRT is installed on. While the WRT1900ac is a blazing fast AP compared to other consumer routers, comparing it to a dedicated server running pfsense or another distro makes it look like a snail.

I get upwards of 10M - 15MB/s download (~80 - 120mbps) while upload is between 1 - 4MB/s (~8mbps - 32mbps).

(Last edited by JW0914 on 12 Jul 2015, 15:21)

Post #6263

gaga

12 Jul 2015, 15:15

JW0914 wrote:

gaga wrote:
JW0914 wrote:
Can you post the output of cat /etc/config/openvpn as managing the vpn from LuCI re-writes the config file and I'd like to compare your config from yesterday to the new config
config openvpn 'VPNserver'
    option enabled '1'
    option dev 'tun0'
    option topology 'subnet'
    option proto 'udp'
    option port '1194'
    option server '10.1.1.0 255.255.255.0'
    option ifconfig '10.1.1.1 255.255.255.0'
    list push 'route 192.168.1.0 255.255.255.0'
    list push 'dhcp-option DNS 192.168.1.1'
    list push 'dhcp-option WINS 192.168.1.1'
    list push 'dhcp-option DNS 8.8.8.8'
    list push 'dhcp-option DNS 8.8.4.4'
    list push 'dhcp-option NTP 129.6.15.30'
    list push 'sndbuf 393216'
    list push 'rcvbuf 393216'
    option cipher 'AES-256-CBC'
    option dh '/etc/openvpn/keys/dh2048.pem'
    option tls_auth '/etc/openvpn/keys/ta.key 0'
    option log '/tmp/openvpn.log'
    option status '/tmp/openvpn-status.log'
    option verb '7'
    option keepalive '10 120'
    option comp_lzo 'yes'
    option client_to_client '1'
    option persist_key '1'
    option persist_tun '1'
    option sndbuf '393216'
    option rcvbuf '393216'
    option fragment '0'
    option mssfix '0'
    option tun_mtu '24000'
    option user 'nobody'
    option group 'nogroup'
    option ca '/etc/openvpn/keys/ca.crt'
    option cert '/etc/openvpn/keys/my-server.crt'
    option key '/etc/openvpn/keys/my-server.key'
    option tls_server '1'
After it worked, I changed to UDP...
As of now I can't access my NAS, though. Need to figure out why...
I have the following setup:
ISP router
192.168.2.1
WRT1900
192.168.2.101
DNS 192.168.2.1
=> Serving as 192.168.1.1 from 192.168.1.2 - 192.168.1.150
NAS
192.168.1.10, DNS: 192.168.1.1
Now I get as a OpenVPN client the IP address 10.1.1.2 and thus, I can't reach my NAS. This is probably only a small issue, but I can't figure out what I need to do.
Any hints?

Scratch that, it's working, sort of. One problem remains: I can't access my SMB shares (Total Commander, ES File Explorer). Through Webbrowser it works, though. What's wrong?
In combination with my post earlier today, here's what I think may be happening (you'd have to view your firewall and system log to verify)
10.1.1.2 is assigned by the vpn server, which then tries to communicate with 192.168.1.10, however in order for traffic to 192.168.1.10 to be routed, it must first travel to 192.168.2.0, then to 192.168.2.101, on to 192.168.1.1, and finally 192.168.1.10.
Because of your setup, I'm almost positive either 192.168.2.0 or 192.168.2.101 (or both) need to be pushed routes via the vpn server. Try adding what I suggested here and see if that fixes the routing issue. If not, to know for certain where traffic is being blocked, you'd have to view the firewall and system logs. If you're running a firewall on your NAS, it'd be worth a look to see if the firewall shows any dropped or denied traffic from 10.1.1.2 (highly doubtful, but verify to be certain).

@JW0914

Please allow me 1-2 days, it's a bit hectic right now. For sure I will provide feedback...and an embarrassing one, too.

In short: It works now....I mean everything. :-)

Post #6264

JW0914

12 Jul 2015, 15:16

gaga wrote:

JW0914 wrote:
gaga wrote:
config openvpn 'VPNserver'
    option enabled '1'
    option dev 'tun0'
    option topology 'subnet'
    option proto 'udp'
    option port '1194'
    option server '10.1.1.0 255.255.255.0'
    option ifconfig '10.1.1.1 255.255.255.0'
    list push 'route 192.168.1.0 255.255.255.0'
    list push 'dhcp-option DNS 192.168.1.1'
    list push 'dhcp-option WINS 192.168.1.1'
    list push 'dhcp-option DNS 8.8.8.8'
    list push 'dhcp-option DNS 8.8.4.4'
    list push 'dhcp-option NTP 129.6.15.30'
    list push 'sndbuf 393216'
    list push 'rcvbuf 393216'
    option cipher 'AES-256-CBC'
    option dh '/etc/openvpn/keys/dh2048.pem'
    option tls_auth '/etc/openvpn/keys/ta.key 0'
    option log '/tmp/openvpn.log'
    option status '/tmp/openvpn-status.log'
    option verb '7'
    option keepalive '10 120'
    option comp_lzo 'yes'
    option client_to_client '1'
    option persist_key '1'
    option persist_tun '1'
    option sndbuf '393216'
    option rcvbuf '393216'
    option fragment '0'
    option mssfix '0'
    option tun_mtu '24000'
    option user 'nobody'
    option group 'nogroup'
    option ca '/etc/openvpn/keys/ca.crt'
    option cert '/etc/openvpn/keys/my-server.crt'
    option key '/etc/openvpn/keys/my-server.key'
    option tls_server '1'
After it worked, I changed to UDP...
As of now I can't access my NAS, though. Need to figure out why...
I have the following setup:
ISP router
192.168.2.1
WRT1900
192.168.2.101
DNS 192.168.2.1
=> Serving as 192.168.1.1 from 192.168.1.2 - 192.168.1.150
NAS
192.168.1.10, DNS: 192.168.1.1
Now I get as a OpenVPN client the IP address 10.1.1.2 and thus, I can't reach my NAS. This is probably only a small issue, but I can't figure out what I need to do.
Any hints?

Scratch that, it's working, sort of. One problem remains: I can't access my SMB shares (Total Commander, ES File Explorer). Through Webbrowser it works, though. What's wrong?
In combination with my post earlier today, here's what I think may be happening (you'd have to view your firewall and system log to verify)
10.1.1.2 is assigned by the vpn server, which then tries to communicate with 192.168.1.10, however in order for traffic to 192.168.1.10 to be routed, it must first travel to 192.168.2.0, then to 192.168.2.101, on to 192.168.1.1, and finally 192.168.1.10.
Because of your setup, I'm almost positive either 192.168.2.0 or 192.168.2.101 (or both) need to be pushed routes via the vpn server. Try adding what I suggested here and see if that fixes the routing issue. If not, to know for certain where traffic is being blocked, you'd have to view the firewall and system logs. If you're running a firewall on your NAS, it'd be worth a look to see if the firewall shows any dropped or denied traffic from 10.1.1.2 (highly doubtful, but verify to be certain).
@JW0914
Please allow me 1-2 days, it's a bit hectic right now. For sure I will provide feedback...and an embarrassing one, too.
In short: It works now....I mean everything. :-)

Awesome =] Glad you got everything figured out

Post #6265

gaga

12 Jul 2015, 15:20

JW0914 wrote:

belliash wrote:
gaga wrote:
I think it could be even faster. Looking at the CPU stats I think my G4 is limited by that

Pretty strange because my router acts as a client.
OpenVPN server is installed on my personal server powered by Xeon L5630.
I have tried several options all the timem and all I get is around 12mbps (max 1.6MiB/s).
W/o VPN I can reach 100mbps...
What is the encryption level on your ssl certificates? Can you post your server and client configs (minus port #, DDNS, and keys if using xml in the configs).
Also:
What OS is your server running?
What processor, how much RAM, and is the NIC at least a 1Gbit?
What is the average CPU and RAM load when trying to access the VPN?
What brand and model of modem are you're using (unless you know the stream count for upstream/downstream)?
What type of internet service do you have and do you know what the ISP's downstream/upstream count is?
Downstream/upstream is not upload and download speed and the streams determine how fast your internet service will be. For example, in the U.S., Time Warner is a 16x4 ISP (16 download streams, 4 upload streams), while Comcast is either 8x4 or 8x2.
Think of it like a download manager, the more streams, the faster a file is downloaded/uploaded. While the ISP speed will never exceed 65mbps, it you have 16 streams and each is downloading at 41.85mbps, a 4.2MB file will download 16x faster than on a 1 stream service. You could also compare it to multi core CPUs.
Normally, an OpenVPN server running on a dedicated server before OpenWRT (modem --> server --> OpenWRT) should get upwards of 100 - 500mbps (~12.5 - 62.5MB/s) or greater, while after OpenWRT will vary depending on a myriad of factors, the most limiting of which is the AP OpenWRT is installed on. While the WRT1900ac is a blazing fast AP compared to other consumer routers, comparing it to a dedicated server running pfsense or another distro makes it look like a snail.
I get upwards of 10MB/s download (~80mbps), sometimes hitting 15MB/s (~120mbps), while upload is between 1 - 4MB/s (~8mbps - 32mbps).

I can confirm this. Over SMB on my phone (LG G4) I get ~30mbps. Through WEBDAV (https) I get ~50mbps on my phone.

I couldn't test it on a laptop so far => my phone seems CPU limited so you should be able to get even higher transfer rates.

Post #6266

JW0914

12 Jul 2015, 15:27

gaga wrote:

JW0914 wrote:
belliash wrote:

Pretty strange because my router acts as a client.
OpenVPN server is installed on my personal server powered by Xeon L5630.
I have tried several options all the timem and all I get is around 12mbps (max 1.6MiB/s).
W/o VPN I can reach 100mbps...
What is the encryption level on your ssl certificates? Can you post your server and client configs (minus port #, DDNS, and keys if using xml in the configs).
Also:
What OS is your server running?
What processor, how much RAM, and is the NIC at least a 1Gbit?
What is the average CPU and RAM load when trying to access the VPN?
What brand and model of modem are you're using (unless you know the stream count for upstream/downstream)?
What type of internet service do you have and do you know what the ISP's downstream/upstream count is?
What file system is being used on your NAS (I'm assuming your server is an NAS), and what type of RAID are you using?
Downstream/upstream is not upload and download speed and the streams determine how fast your internet service will be (not the download speed of the service, but how fast the service will actually be). For example, in the U.S., Time Warner is a 16x4 ISP (16 download streams, 4 upload streams), while Comcast is either 8x4 or 8x2.
Think of it like a download manager, the more streams, the faster a file is downloaded/uploaded. While the ISP speed will never exceed 65mbps, it you have 16 streams and each is downloading at 41.85mbps, a 4.2MB file will download 16x faster than on a 1 stream service. You could also compare it to multi core CPUs.
Normally, an OpenVPN server running on a dedicated server before OpenWRT (modem --> server --> OpenWRT) should get upwards of 100 - 500mbps (~12.5 - 62.5MB/s) or greater, while after OpenWRT will vary depending on a myriad of factors, the most limiting of which is the AP OpenWRT is installed on. While the WRT1900ac is a blazing fast AP compared to other consumer routers, comparing it to a dedicated server running pfsense or another distro makes it look like a snail.
I get upwards of 10M - 15MB/s download (~80 - 120mbps) while upload is between 1 - 4MB/s (~8mbps - 32mbps).
I can confirm this. Over SMB on my phone (LG G4) I get ~30mbps. Through WEBDAV (https) I get ~50mbps on my phone.
I couldn't test it on a laptop so far => my phone seems CPU limited so you should be able to get even higher transfer rates.

Those were my PC speeds over WiFi, but the router I was connected to was an R6300v1, which only has a single core 600Mhz processor.

There's a lot of factors that limit VPN speed, the most limiting of which are the modem being used on both sides (at home I use an SB6121, which is only 4 streams, and I'm upgrading to the SB6183 which is a 16 stream modem), how many streams the ISP offers on both sides, and the routers on both sides.

Post #6267

belliash

12 Jul 2015, 22:07

JW0914 wrote:

belliash wrote:
gaga wrote:
I think it could be even faster. Looking at the CPU stats I think my G4 is limited by that

Pretty strange because my router acts as a client.
OpenVPN server is installed on my personal server powered by Xeon L5630.
I have tried several options all the timem and all I get is around 12mbps (max 1.6MiB/s).
W/o VPN I can reach 100mbps...
What is the encryption level on your ssl certificates? Can you post your server and client configs (minus port #, DDNS, and keys if using xml in the configs).
Also:
What OS is your server running?
What processor, how much RAM, and is the NIC at least a 1Gbit?
What is the average CPU and RAM load when trying to access the VPN?
What brand and model of modem are you're using (unless you know the stream count for upstream/downstream)?
What type of internet service do you have and do you know what the ISP's downstream/upstream count is?
What file system is being used on your NAS (I'm assuming your server is an NAS), and what type of RAID are you using?
Downstream/upstream is not upload and download speed and the streams determine how fast your internet service will be (not the download speed of the service, but how fast the service will actually be). For example, in the U.S., Time Warner is a 16x4 ISP (16 download streams, 4 upload streams), while Comcast is either 8x4 or 8x2.
Think of it like a download manager, the more streams, the faster a file is downloaded/uploaded. While the ISP speed will never exceed 65mbps, it you have 16 streams and each is downloading at 41.85mbps, a 4.2MB file will download 16x faster than on a 1 stream service. You could also compare it to multi core CPUs.
Normally, an OpenVPN server running on a dedicated server before OpenWRT (modem --> server --> OpenWRT) should get upwards of 100 - 500mbps (~12.5 - 62.5MB/s) or greater, while after OpenWRT will vary depending on a myriad of factors, the most limiting of which is the AP OpenWRT is installed on. While the WRT1900ac is a blazing fast AP compared to other consumer routers, comparing it to a dedicated server running pfsense or another distro makes it look like a snail.
I get upwards of 10M - 15MB/s download (~80 - 120mbps) while upload is between 1 - 4MB/s (~8mbps - 32mbps).

OpenVPN server is running on Gentoo Linux. It is equipped with Xeon L5630 and 24GB RAM. I use ext4 everywhere.
On the other side, VPN client is running on WRT1900AC with OpenWrt.

Both sides are connected to each other over the Internet (same provider, symmetrical 100mbps, FTTH - PON).
I can get 100mbps via pure Internet, but only around 12-13mbps over VPN. I use AES-192 with 2048bit certificate.

Post #6268

JW0914

12 Jul 2015, 23:36

belliash wrote:

JW0914 wrote:
belliash wrote:

Pretty strange because my router acts as a client.
OpenVPN server is installed on my personal server powered by Xeon L5630.
I have tried several options all the timem and all I get is around 12mbps (max 1.6MiB/s).
W/o VPN I can reach 100mbps...
What is the encryption level on your ssl certificates? Can you post your server and client configs (minus port #, DDNS, and keys if using xml in the configs).
Also:
What OS is your server running?
What processor, how much RAM, and is the NIC at least a 1Gbit?
What is the average CPU and RAM load when trying to access the VPN?
What brand and model of modem are you're using (unless you know the stream count for upstream/downstream)?
What type of internet service do you have and do you know what the ISP's downstream/upstream count is?
What file system is being used on your NAS (I'm assuming your server is an NAS), and what type of RAID are you using?
Downstream/upstream is not upload and download speed and the streams determine how fast your internet service will be (not the download speed of the service, but how fast the service will actually be). For example, in the U.S., Time Warner is a 16x4 ISP (16 download streams, 4 upload streams), while Comcast is either 8x4 or 8x2.
Think of it like a download manager, the more streams, the faster a file is downloaded/uploaded. While the ISP speed will never exceed 65mbps, it you have 16 streams and each is downloading at 41.85mbps, a 4.2MB file will download 16x faster than on a 1 stream service. You could also compare it to multi core CPUs.
Normally, an OpenVPN server running on a dedicated server before OpenWRT (modem --> server --> OpenWRT) should get upwards of 100 - 500mbps (~12.5 - 62.5MB/s) or greater, while after OpenWRT will vary depending on a myriad of factors, the most limiting of which is the AP OpenWRT is installed on. While the WRT1900ac is a blazing fast AP compared to other consumer routers, comparing it to a dedicated server running pfsense or another distro makes it look like a snail.
I get upwards of 10M - 15MB/s download (~80 - 120mbps) while upload is between 1 - 4MB/s (~8mbps - 32mbps).

OpenVPN server is running on Gentoo Linux. It is equipped with Xeon L5630 and 24GB RAM. I use ext4 everywhere.
On the other side, VPN client is running on WRT1900AC with OpenWrt.
Both sides are connected to each other over the Internet (same provider, symmetrical 100mbps, FTTH - PON).
I can get 100mbps via pure Internet, but only around 12-13mbps over VPN. I use AES-192 with 2048bit certificate.

Please post server and client configs

Post #6269

jeremyjack

13 Jul 2015, 00:48

I got RC2 to run for a little over 10 days before the router locked up entirely (no pings, no lan, no wifi). I looked through the logs and it doesn't appear to be temperature related... the load spiked quite a bit but the new fan script spun the fan up to 100% and kept the temp down to around 60.

It looks like it may be part of the issue that Vanav mentioned previously.

Wed Jul 8 02:33:54 2015 kern.err kernel: [889545.969625] INFO: rcu_sched self-detected stall on CPU { 0} (t=6000 jiffies g=3835439 c=3835438 q=1304)
Wed Jul 8 02:33:54 2015 kern.info kernel: [889545.979301] Task dump for CPU 0:
Wed Jul 8 02:33:54 2015 kern.info kernel: [889545.982639] kworker/u4:2 R running 0 8771 2 0x00000002
Wed Jul 8 02:33:54 2015 kern.info kernel: [889545.989200] Workqueue: phy0 ieee80211_iface_work [mac80211]
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889545.994899] Backtrace:
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889545.997477] [<c001ae14>] (dump_backtrace) from [<c001b17c>] (show_stack+0x18/0x1c)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.005168] r6:c044afc0 r5:c044b080 r4:cdc07800 r3:00000006
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.011024] [<c001b164>] (show_stack) from [<c0044e40>] (sched_show_task+0xc8/0xfc)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.018806] [<c0044d78>] (sched_show_task) from [<c0047034>] (dump_cpu_task+0x40/0x44)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.026845] r5:c044b080 r4:00000000
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.030584] [<c0046ff4>] (dump_cpu_task) from [<c005f640>] (rcu_dump_cpu_stacks+0x70/0xb4)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.038964] r4:00000000 r3:00000001
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.042700] [<c005f5d0>] (rcu_dump_cpu_stacks) from [<c00621d8>] (rcu_check_callbacks+0x24c/0x668)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.051784] r9:c044afc0 r8:c044afc0 r7:0f99b000 r6:00000518 r5:c043e214 r4:cfdd9214
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.059745] [<c0061f8c>] (rcu_check_callbacks) from [<c0064280>] (update_process_times+0x48/0x68)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.068738] r10:c046da80 r9:c046da80 r8:c046da00 r7:00000000 r6:00000000 r5:cdc07800
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.076767] r4:cddf6000
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.079428] [<c0064238>] (update_process_times) from [<c007233c>] (tick_sched_timer+0x210/0x254)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.088338] r7:cddf77c8 r6:cfdd9570 r5:00032905 r4:fe6912d6
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.094193] [<c007212c>] (tick_sched_timer) from [<c0064fec>] (__run_hrtimer.isra.35+0xa8/0x144)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.103105] r10:cfdd9368 r9:00000000 r8:cfdd9378 r7:00000001 r6:cfdd9368 r5:cfdd93a0
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.111138] r4:cfdd9570
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.113795] [<c0064f44>] (__run_hrtimer.isra.35) from [<c006529c>] (hrtimer_interrupt+0x138/0x2ac)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.122878] r7:00000001 r6:cfdd9368 r5:00032905 r4:fe690606
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.128722] [<c0065164>] (hrtimer_interrupt) from [<c0264f54>] (armada_370_xp_timer_interrupt+0x4c/0x54)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.138328] r10:c0485d58 r9:000003ff r8:cfddcc40 r7:00000010 r6:cf80aa00 r5:c044f4f8
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.146360] r4:cfddcc40
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.149019] [<c0264f08>] (armada_370_xp_timer_interrupt) from [<c005bcd8>] (handle_percpu_devid_irq+0x74/0x8c)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.159148] r4:cf803c40 r3:c0264f08
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.162888] [<c005bc64>] (handle_percpu_devid_irq) from [<c00580c0>] (generic_handle_irq+0x34/0x44)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.172060] r8:cf805000 r7:00000001 r6:cddf7d58 r5:00000000 r4:00000010 r3:c005bc64
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.180021] [<c005808c>] (generic_handle_irq) from [<c00583c8>] (__handle_domain_irq+0x90/0xa4)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.188838] r4:c043e8f8 r3:0000005e
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.192572] [<c0058338>] (__handle_domain_irq) from [<c0008698>] (armada_370_xp_handle_irq+0x64/0xe0)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.201918] r8:cddf77c8 r7:00000001 r6:c0485d6c r5:20000153 r4:c0011e14 r3:cddf77c8
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.209877] [<c0008634>] (armada_370_xp_handle_irq) from [<c00097a0>] (__irq_svc+0x40/0x54)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.218348] Exception stack(0xcddf77c8 to 0xcddf7810)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.223524] 77c0: ce8e683c 00000000 00002709 00002708 ce4fc7c0 00000000
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.231839] 77e0: ce88ce20 00000004 00000000 054cabe3 00000001 cddf781c cddf7820 cddf7810
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.240150] 7800: bf2766bc c0011e14 20000153 ffffffff
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.245311] r10:00000001 r9:054cabe3 r8:00000000 r7:cddf77fc r6:ffffffff r5:20000153
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.253343] r4:c0011e14
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.256024] [<c0011de0>] (_raw_spin_lock) from [<bf2766bc>] (mwl_tx_xmit+0x458/0x8dc [mwlwifi])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.264875] [<bf276264>] (mwl_tx_xmit [mwlwifi]) from [<bf2715a8>] (mwl_mac80211_tx+0x60/0x64 [mwlwifi])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.274484] r10:00000000 r9:00000002 r8:00000000 r7:cf3b2ca8 r6:ce8e4b40 r5:ce4fc7c0
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.282518] r4:cddf78f8
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.285224] [<bf271548>] (mwl_mac80211_tx [mwlwifi]) from [<bf222424>] (ieee80211_nullfunc_get+0x15d0/0x168c [mac80211])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.296294] [<bf222084>] (ieee80211_nullfunc_get [mac80211]) from [<bf22307c>] (ieee80211_get_buffered_bc+0x210/0x82c [mac80211])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.308081] r10:c0444350 r9:00000000 r8:ce8e4b40 r7:0000005e r6:cf3b24c2 r5:00000000
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.316114] r4:ce4fc7c0
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.318825] [<bf222fb0>] (ieee80211_get_buffered_bc [mac80211]) from [<bf224550>] (ieee80211_xmit+0xf0/0xf8 [mac80211])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.329739] r9:ce4fc7c0 r8:ce5ea086 r7:ce88c800 r6:ce8e4b40 r5:cf3b24c0 r4:ce4fc7c0
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.337739] [<bf224460>] (ieee80211_xmit [mac80211]) from [<bf2248e0>] (__ieee80211_subif_start_xmit+0x88/0x90 [mac80211])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.348912] r8:ceae7c68 r7:cf901600 r6:ceae7c00 r5:cf3b24c0 r4:cf3b2000
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.355879] [<bf224858>] (__ieee80211_subif_start_xmit [mac80211]) from [<bf2248fc>] (ieee80211_subif_start_xmit+0x14/0x1c [mac80211])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.368098] r5:cf3b2000 r4:ce4fc7c0
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.371864] [<bf2248e8>] (ieee80211_subif_start_xmit [mac80211]) from [<c0289e88>] (dev_hard_start_xmit+0x270/0x31c)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.382533] [<c0289c18>] (dev_hard_start_xmit) from [<c02a3db8>] (sch_direct_xmit+0xb4/0x218)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.391185] r10:cf3b2000 r9:ce4fc7c0 r8:ceae7c68 r7:cf901600 r6:ceae7c00 r5:ceae7c00
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.399206] r4:00000000
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.401877] [<c02a3d04>] (sch_direct_xmit) from [<c028a170>] (__dev_queue_xmit+0x23c/0x524)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.410353] r10:00000000 r9:ceae7c68 r8:00000000 r7:cf901600 r6:cf3b2000 r5:ceae7c00
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.418375] r4:ce4fc7c0
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.421046] [<c0289f34>] (__dev_queue_xmit) from [<c028a46c>] (dev_queue_xmit+0x14/0x18)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.429251] r10:cddf7b78 r9:c0442100 r8:cf3b2000 r7:cf3b2000 r6:cddf7b78 r5:ce4fc7c0
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.437280] r4:ce4fc7c0
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.439991] [<c028a458>] (dev_queue_xmit) from [<bf21b9e4>] (ieee80211_get_ringparam+0x350/0x954 [mac80211])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.450018] [<bf21b8a8>] (ieee80211_get_ringparam [mac80211]) from [<bf21e07c>] (ieee80211_sta_ps_transition+0x1d38/0x37c4 [mac80211])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.462239] r7:cddf7b28 r6:ce8e4b40 r5:ce4fc7c0 r4:cf3b24c0
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.468135] [<bf21cac8>] (ieee80211_sta_ps_transition [mac80211]) from [<bf21fa38>] (ieee80211_sta_ps_transition+0x36f4/0x37c4 [mac80211])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.480702] r10:ce8e4b40 r9:00000000 r8:ce5ea086 r7:ce8e4b40 r6:cddf7b28 r5:ce4fc7c0
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.488723] r4:cddf7b78
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.491448] [<bf21efd8>] (ieee80211_sta_ps_transition [mac80211]) from [<bf2200fc>] (ieee80211_rx+0x5f4/0x7e4 [mac80211])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.502536] r10:00000630 r9:cddf7b78 r8:ce5ea086 r7:00000000 r6:00000000 r5:ce4fc7c0
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.510566] r4:ce8e4b40
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.513265] [<bf21fb08>] (ieee80211_rx [mac80211]) from [<bf277ad4>] (mwl_rx_recv+0x4b4/0x654 [mwlwifi])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.522872] r10:00000000 r9:ce8e5840 r8:ce9f4dc0 r7:cddf7c28 r6:cddf7c20 r5:0000001a
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.530905] r4:ce4fc7c0
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.533579] [<bf277620>] (mwl_rx_recv [mwlwifi]) from [<c0029684>] (tasklet_action+0x9c/0x108)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.542316] r10:00000006 r9:cddf6000 r8:c043e13c r7:c0465bc0 r6:00000000 r5:ce8e6858
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.550347] r4:ce8e6854
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.553011] [<c00295e8>] (tasklet_action) from [<c0029850>] (__do_softirq+0x104/0x234)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.561051] r9:00000100 r8:cddf6000 r7:40000002 r6:c0442090 r5:c0442098 r4:00000000
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.569011] [<c002974c>] (__do_softirq) from [<c0029c00>] (irq_exit+0xa0/0xb0)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.576356] r10:c0485d58 r9:000003ff r8:cf805000 r7:00000001 r6:00000000 r5:00000000
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.584390] r4:c043e8f8
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.587054] [<c0029b60>] (irq_exit) from [<c00583cc>] (__handle_domain_irq+0x94/0xa4)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.595006] r4:c043e8f8 r3:0000005e
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.598730] [<c0058338>] (__handle_domain_irq) from [<c0008698>] (armada_370_xp_handle_irq+0x64/0xe0)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.608076] r8:cddf7d58 r7:00000001 r6:c0485d6c r5:40000153 r4:c0011e1c r3:cddf7d58
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.616036] [<c0008634>] (armada_370_xp_handle_irq) from [<c00097a0>] (__irq_svc+0x40/0x54)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.624515] Exception stack(0xcddf7d58 to 0xcddf7da0)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.629681] 7d40:ce8e683c 00000000
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.637993] 7d60: 00002708 00002708 ce8e4b40 ce8e5840 ce8e683c 00000001 00000000 00000000
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.646308] 7d80: ce65c620 cddf7dac cddf7db0 cddf7da0 bf27079c c0011e1c 40000153 ffffffff
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.654612] r10:ce65c620 r9:00000000 r8:00000000 r7:cddf7d8c r6:ffffffff r5:40000153
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.662647] r4:c0011e1c
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.665324] [<c0011de0>] (_raw_spin_lock) from [<bf27079c>] (mwl_mac80211_ampdu_action+0x5c/0x39c [mwlwifi])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.675336] [<bf270740>] (mwl_mac80211_ampdu_action [mwlwifi]) from [<bf20cf5c>] (__ieee80211_start_rx_ba_session+0x240/0x47c [mac80211])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.687819] r10:ce8e4b40 r9:00000040 r8:00000000 r7:00000001 r6:00000040 r5:cd71a640
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.695852] r4:ce65c000
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.698562] [<bf20cd1c>] (__ieee80211_start_rx_ba_session [mac80211]) from [<bf20d1ec>] (ieee80211_process_addba_request+0x54/0x5c [mac80211])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.711478] r10:ce8e4f3c r9:cf3b24c0 r8:cf3b2904 r7:ce8e4b40 r6:00000001 r5:00000000
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.719499] r4:00000001
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.722222] [<bf20d198>] (ieee80211_process_addba_request [mac80211]) from [<bf211260>] (ieee80211_iface_work+0x1d0/0x3ac [mac80211])
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.734354] r6:cf3b28f4 r5:ce844088 r4:cdfe9280
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.739169] [<bf211090>] (ieee80211_iface_work [mac80211]) from [<c00396f8>] (process_one_work+0x1f4/0x33c)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.749037] r10:00000000 r9:00000000 r8:cddf6020 r7:cfa7c000 r6:cf830800 r5:cf3b28f4
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.757070] r4:cd8bd300
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.759740] [<c0039504>] (process_one_work) from [<c003a270>] (worker_thread+0x31c/0x50c)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.768035] r10:cddf6000 r9:00000088 r8:cddf6020 r7:cd8bd318 r6:cf830814 r5:cf830800
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.776065] r4:cd8bd300
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.778723] [<c0039f54>] (worker_thread) from [<c003dc90>] (kthread+0xf4/0xf8)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.786067] r10:00000000 r9:00000000 r8:00000000 r7:c0039f54 r6:cd8bd300 r5:00000000
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.794102] r4:ceaffd80
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.796760] [<c003db9c>] (kthread) from [<c0008f18>] (ret_from_fork+0x14/0x3c)
Wed Jul 8 02:33:54 2015 kern.warn kernel: [889546.804103] r7:00000000 r6:00000000 r5:c003db9c r4:ceaffd80

Wed Jul 8 02:36:21 2015 kern.err kernel: [889693.732155] INFO: rcu_bh detected stalls on CPUs/tasks: { 0} (detected by 1, t=6002 jiffies, g=13112, c=13111, q=4)
Wed Jul 8 02:36:21 2015 kern.info kernel: [889693.742781] Task dump for CPU 0:
Wed Jul 8 02:36:21 2015 kern.info kernel: [889693.746111] kworker/u4:2 R running 0 8771 2 0x00000002
Wed Jul 8 02:36:21 2015 kern.info kernel: [889693.752680] Workqueue: phy0 ieee80211_iface_work [mac80211]
Wed Jul 8 02:36:21 2015 kern.warn kernel: [889693.758371] Backtrace:
Wed Jul 8 02:36:21 2015 kern.warn kernel: [889693.760965] [<cddf5ff4>] (0xcddf5ff4) from [<00000088>] (0x88)
Wed Jul 8 02:36:21 2015 kern.warn kernel: [889693.766906] Backtrace aborted due to bad frame pointer <cd8bd318>

(Last edited by jeremyjack on 13 Jul 2015, 05:08)

Post #6270

davidc502

13 Jul 2015, 01:22

If the cpu stall can't be fixed, that's fine, it just needs to recover from it.

I have a script that is checking, every minute, for the cpu stall, and if it's found, reboots the router. However, it would be nice for the router to recover on its own.

One day I would like to see long periods of uptime because I monitor for monthly bandwidth used, and when the router reboots, the counters are reset. The stats are checked every 6 hours, so if it does reboot, a maximum of 6 hours of bandwidth usage might be lost. It's not a big deal, but it's nice to know exactly what is being used every month.

(Last edited by davidc502 on 13 Jul 2015, 01:34)

Post #6271

belliash

13 Jul 2015, 07:24

JW0914 wrote:

belliash wrote:
JW0914 wrote:
What is the encryption level on your ssl certificates? Can you post your server and client configs (minus port #, DDNS, and keys if using xml in the configs).
Also:
What OS is your server running?
What processor, how much RAM, and is the NIC at least a 1Gbit?
What is the average CPU and RAM load when trying to access the VPN?
What brand and model of modem are you're using (unless you know the stream count for upstream/downstream)?
What type of internet service do you have and do you know what the ISP's downstream/upstream count is?
What file system is being used on your NAS (I'm assuming your server is an NAS), and what type of RAID are you using?
Downstream/upstream is not upload and download speed and the streams determine how fast your internet service will be (not the download speed of the service, but how fast the service will actually be). For example, in the U.S., Time Warner is a 16x4 ISP (16 download streams, 4 upload streams), while Comcast is either 8x4 or 8x2.
Think of it like a download manager, the more streams, the faster a file is downloaded/uploaded. While the ISP speed will never exceed 65mbps, it you have 16 streams and each is downloading at 41.85mbps, a 4.2MB file will download 16x faster than on a 1 stream service. You could also compare it to multi core CPUs.
Normally, an OpenVPN server running on a dedicated server before OpenWRT (modem --> server --> OpenWRT) should get upwards of 100 - 500mbps (~12.5 - 62.5MB/s) or greater, while after OpenWRT will vary depending on a myriad of factors, the most limiting of which is the AP OpenWRT is installed on. While the WRT1900ac is a blazing fast AP compared to other consumer routers, comparing it to a dedicated server running pfsense or another distro makes it look like a snail.
I get upwards of 10M - 15MB/s download (~80 - 120mbps) while upload is between 1 - 4MB/s (~8mbps - 32mbps).

OpenVPN server is running on Gentoo Linux. It is equipped with Xeon L5630 and 24GB RAM. I use ext4 everywhere.
On the other side, VPN client is running on WRT1900AC with OpenWrt.
Both sides are connected to each other over the Internet (same provider, symmetrical 100mbps, FTTH - PON).
I can get 100mbps via pure Internet, but only around 12-13mbps over VPN. I use AES-192 with 2048bit certificate.
Please post server and client configs

client wrote:

config openvpn 'ABC'
option enable '1'
option client '1'
option remote ''
option port ''
option proto 'udp'
option dev 'tun0'
option ca ''
option cert ''
option key ''
option tls_auth ''
option comp_lzo 'yes'
option keepalive '10 120'
option mssfix '1400'
option fragment '0'
option status '/tmp/openvpn.status'
option verb '4'
option persist-key '1'
option persist-tun '1'
option cipher 'AES-192-CBC'

server wrote:

dev tun0
proto udp
port ABC
mode server
tls-server
cipher AES-192-CBC
dh /path/
ca /path/
cert /path/
key /path/
tls-auth /path/
status /path/
log /path/
server IP 255.255.255.0
keepalive 10 120
fragment 0
mssfix 1400
user openvpn
group openvpn
max-clients 5
comp-lzo
persist-key
persist-tun
verb 4

Post #6272

gaga

13 Jul 2015, 10:25

JW0914 wrote:

When you have a chance, could you read through the VPN Wiki and let me know if you think anything else should be
added or clarified? Thanks =]
Awesome =] Glad you got everything figured out

I will re-flash my router this weekend and re-do everything from scratch...just to make sure it's complete. One nice thing would be to add directly after the wiki how-to route all traffic through VPN. I am struggling with that right now...many different solution approaches out there...many don't work for me...

The solution for my SMB-accessing problem was rather embarrassing. Before I had some firewall rules on my Synology to only accept connections from 192.168.1.0/24 to 192.168.4.0/24. Now with OpenVPN I get 10.1.1.0/24...so...yes...that stupid...

The odd thing was, that I was able to access my NAS through the phone's browser or Synology's own apps, while connected through VPN, but not by using "ES file browser" or "Total Commander". Currently, I don't trust my setup, but then again, too many changes in an uncontrolled manner. Hence, I am redoing everything. :-)

Update & Feedback
@JW0914: First of all a big THANK YOU! for your great work and kind & patient support!!

I spent a couple of hours yesterday because in my attempt to get my router back into a clean state, I bricked it and needed some time to get it back working again. Flashing Linksys' stock firmware did not work for me at all, but I am pretty sure it's a handling issue on my end...

Anyways, I followed your tutorial. In short: It works for me with a minor modification.

In my Android openvpn.ovpn file I had to remove

<tls-auth>
-----BEGIN OpenVPN Static key V1-----
 
-----END OpenVPN Static key V1-----
</tls-auth>

and replace it with

tls-auth ta.key 1

No other change was needed (neither certificates nor "option tls_server '1'").

Personally, I would appreciate a little more detail in the section Create SSL Certificates. It is also somewhat misleading as the tutorial states

It is highly recommended to add a complex password to your Certificate Authority (CA)
Failure to set any password allows anyone who gains access to your Certificate Authority the ability to create client certificates.

but when I did a

build-ca

I couldn't set a password. Only for the others, where partly it is indicated to not set one.

This section is confusing to me and I am a bit unsure whether my certificates are now created the "proper" way or not.

Other than that the tutorial is just awesome and makes the process to setup a VPN-server so much easier. The only thing left for me is to get all traffic routed through the OpenVPN server...

(Last edited by gaga on 14 Jul 2015, 11:03)

Post #6273

quagga

13 Jul 2015, 14:27

BusyBox v1.23.2 (2015-06-14 19:52:45 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 CHAOS CALMER (Bleeding Edge, r45952)
 -----------------------------------------------------
  * 1 1/2 oz Gin            Shake with a glassful
  * 1/4 oz Triple Sec       of broken ice and pour
  * 3/4 oz Lime Juice       unstrained into a goblet.
  * 1 1/2 oz Orange Juice
  * 1 tsp. Grenadine Syrup
 -----------------------------------------------------
root@bast:~# uptime
 09:24:11 up 19 days, 10:20,  load average: 0.00, 0.01, 0.04
root@bast:~#

One thing which I think has really helped the lockups is that I reactivated my upstair access point. So 5GHz devices at the edge of range for the wrt1900ac (which is on the basement floor) now access the Airport Express (on the 3rd floor). My Mac is now more often on a Cat6 cable than wifi so that reduces the wifi load as well.

Post #6274

davidc502

13 Jul 2015, 14:46

quagga wrote:

BusyBox v1.23.2 (2015-06-14 19:52:45 UTC) built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 CHAOS CALMER (Bleeding Edge, r45952)
 -----------------------------------------------------
  * 1 1/2 oz Gin            Shake with a glassful
  * 1/4 oz Triple Sec       of broken ice and pour
  * 3/4 oz Lime Juice       unstrained into a goblet.
  * 1 1/2 oz Orange Juice
  * 1 tsp. Grenadine Syrup
 -----------------------------------------------------
root@bast:~# uptime
 09:24:11 up 19 days, 10:20,  load average: 0.00, 0.01, 0.04
root@bast:~#

What I did, which seemed to help was to take the ipad off of 5Ghz, and put it on 2.4Ghz. Since making the change, I now have 5 days of uptime.

Time will tell if it really made any kind of difference.

Post #6275

IvanRaide

13 Jul 2015, 16:41

CHAOS CALMER (Bleeding Edge, r45222)
 -----------------------------------------------------

root@OpenWrt:~# uptime
 11:36:59 up 39 days, 13:25,  load average: 0.04, 0.03, 0.04

With all the talk of RC2, I still haven't updated from 45222 cause it has been rock solid!
Is there any "critical" reason to update? Like critical security fixes, cause I'm thinking "if it aint broke...."

Page 251 of 598