OpenWrt Forum Archive

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.

Re: Encryption metrics.

I have also been trying to find the recipe for a build to maximize throughput. My numbers are significantly lower on some fronts than those posted. Determining the crypto modules to include proves to be somewhat elusive in terms of maximizing encryption throughput.

I have pasted metric output, also including a diff of my config. Perhaps if we compare crypto modules included in respective builds we can determine a recipe to maximize the utilization of this component.

This is a wrt1900acv1

(Last edited by anomeome on 4 Apr 2016, 02:09)

InkblotAdmirer wrote:

With respect to the crypto patch, here are some results.  I thought I already had the hardware crypto acceleration figured out, but I figured I'd play with the patch nitroshift linked. Results below.

and you ran openssl with '-engine cryptodev' or even enabled it in openssl.cnf?

Thank you all for your help, and I opted for RMA process. @mrfrezee you included in luci web config switch? when I return the router install your version if so. Thank you again for everything.

leitec wrote:

If you build with this patch the switch will show up in LuCI by default on the ACS/v2/1200AC:

http://patchwork.ozlabs.org/patch/560773/

that's missing right now for those models. There's no need for any additional LuCI packages.

This is the equivalent base config done by hand:

https://forum.openwrt.org/viewtopic.php … 81#p316681


I have to copy it as is in for example vi /etc/config /network? or I need an additional command? as far as I config switch usually comes by default in the trunk, although there are custom compilations omit it. ISP for my needs force me to take that option. IF it included in the compilation and web luci make me my favor, and I'm starting on this. Thank you

anomeome wrote:

Re: Encryption metrics.

I have also been trying to find the recipe for a build to maximize throughput. My numbers are significantly lower on some fronts than those posted. Determining the crypto modules to include proves to be somewhat elusive in terms of maximizing encryption throughput.

I have pasted metric output, also including a diff of my config. Perhaps if we compare crypto modules included in respective builds we can determine a recipe to maximize the utilization of this component.

This is a wrt1900acv1

I don't see CONFIG_OPENSSL_HARDWARE_SUPPORT=y on your configdiff, is that normal ?

Edit: Do you have a /dev/crypto on your device ?

(Last edited by mrfrezee on 4 Apr 2016, 17:55)

roberto_MCF wrote:
leitec wrote:

If you build with this patch the switch will show up in LuCI by default on the ACS/v2/1200AC:

http://patchwork.ozlabs.org/patch/560773/

that's missing right now for those models. There's no need for any additional LuCI packages.

This is the equivalent base config done by hand:

https://forum.openwrt.org/viewtopic.php … 81#p316681


I have to copy it as is in for example vi /etc/config /network? or I need an additional command? as far as I config switch usually comes by default in the trunk, although there are custom compilations omit it. ISP for my needs force me to take that option. IF it included in the compilation and web luci make me my favor, and I'm starting on this. Thank you

It's only configured by default on the v1. The patch I linked to fixes that, but it hasn't been merged to trunk yet (unless it happened while I was away recently and didn't see it)

In the second link there is a sequence of 'uci' commands. SSH to your router and copy-paste those commands at the prompt. You don't need to edit /etc/config/network -- when you run the final 'uci commit' that will write /etc/config/network for you. Once you reboot you should have the switch in LuCI.

Will recompile for acs and v2 tonight with the switch patch. Will report any issues.

@roberto

You should take david's build. Mine take so much longer to finish and i didn't even started to compile.

(Last edited by mrfrezee on 4 Apr 2016, 18:57)

nortii wrote:

and you ran openssl with '-engine cryptodev' or even enabled it in openssl.cnf?

OK good point.  I originally spent time on the V1 build and got it close to that posted in the benchmarks and didn't go further.  ACV1 and the ACS have different Marvell chips and will likely need to be handled differently (namely, the patch won't apply to the V1).

I'll get my ducks in a row and report back.

mrfrezee wrote:
disleos wrote:

Has anyone had any issues with their recent trunk builds and the 1900ac v1 LED's?

The only LED's I have listed available under /sys/class/leds is mamba:white:power. I assumed it was just a trunk change that went awry, but given I haven't seen anyone mention it in this thread yet, I suspect I've broken something sad

Any ideas?

Got the same problem. On the v1, the TLC5911xx seems to work only on 4.4.x.
Edit: see https://dev.openwrt.org/ticket/21825

Nice one, cheers! Time for a kernel change.

mrfrezee wrote:

@roberto

You should take david's build. Mine take so much longer to finish and i didn't even started to compile.

Recommendations about patching? I renamed to 989, and thought it would take, but figure I'm missing something.

Placed patch in the kernel 4.4 directory.

Applying patch platform/989-WRT1900ACv2-S.patch
can't find file to patch at input line 5
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/target/linux/mvebu/base-files/etc/board.d/02_network b/target/linux/mvebu/base-files/etc/board.d/02_network
|index 289a4b0..5616aaf 100755
|--- a/target/linux/mvebu/base-files/etc/board.d/02_network
|+++ b/target/linux/mvebu/base-files/etc/board.d/02_network
--------------------------
No file to patch.  Skipping patch.


Emailing -- leitec@staticky.com
http://patchwork.ozlabs.org/patch/560773/

(Last edited by davidc502 on 4 Apr 2016, 23:30)

@mrfrezee
I don't know if it's normal, but certainly not right given what I am trying to achieve. Thanks for the keen eye. I do have the /dev/crypto file. I flashed another image with define changes for openssl. My numbers were better, but still not great, so went back to check on whether the CESA define was in my build_dir config file, and it was not. So that earlier change set is not taking effect. I have created a patch from the nitroshift link and doing a new build for another test.

(Last edited by anomeome on 5 Apr 2016, 03:08)

Hi guys, I am experiencing wireless connection problems with the WRT1200ac.

What does happen? My Samsung UE40 Smart TV connects to the router and is unable to communicate or reconnect after about one minute while connected. A reconnect from the the TV is not possible. Happens on both 802.11a or 802.11g, encryption WPA2-PSK AES-CCMP. The same thing has happened to my Ubuntu notebook but by far not that often.

I have tried 15.05.1 and David's (Bleeding Edge, r49037) w/NAND patch & 10.3.0.17 Wifi Driver without success.
On my second router TP-Link TL-WDR3500 the identical configuration works without problems.

Where should I look for the cause? Do you have any tips?

mmat wrote:

Hi guys, I am experiencing wireless connection problems with the WRT1200ac.

What does happen? My Samsung UE40 Smart TV connects to the router and is unable to communicate or reconnect after about one minute while connected. A reconnect from the the TV is not possible. Happens on both 802.11a or 802.11g, encryption WPA2-PSK AES-CCMP. The same thing has happened to my Ubuntu notebook but by far not that often.

I have tried 15.05.1 and David's (Bleeding Edge, r49037) w/NAND patch & 10.3.0.17 Wifi Driver without success.
On my second router TP-Link TL-WDR3500 the identical configuration works without problems.

Where should I look for the cause? Do you have any tips?

You may post your issue at https://github.com/kaloz/mwlwifi/. The improvement of new .17 driver was observed however there is still some room to catch up.

Emailed - leitec@staticky.com

He responded and said the best way to add the patch is through git.

I've run the git command, and it has appeared to have modified the 02_network file.

Compiling for acs right now.

Thanks -- leitec

davidc502 wrote:

Configure switch patch applied to Shelby (ACS) for anyone who wants to try it. Let me know if it should be built for v2 as well.

http://personalpages.tds.net/~davidc502 … T1900ACv2/

If you would compile a V2, I'll give it a go.

Hi guys,

I'm a newbie to openwrt. I have used Tomato by Shibby in the past, but would like to try out openwrt. I have the Linksys WRT1900ACS and I'm very confused on what firmware to choose. What I'm looking for is stability and speed with added functions that's not in the OEM firmware I also know I will need to flash something that already has the LuCI web GUI installed because I don't want to ssh/telnet to the router to do it later, so with that in mind what do you all recommend for stability/ performance with added features not found in OEM firmware and with LuCI web GUI installed?

Please advise and thank you in advance for your help.

mojolacerator wrote:
davidc502 wrote:

Configure switch patch applied to Shelby (ACS) for anyone who wants to try it. Let me know if it should be built for v2 as well.

http://personalpages.tds.net/~davidc502 … T1900ACv2/

If you would compile a V2, I'll give it a go.

It's ready, and in the same directory --- "Cobra"

sfernandes wrote:

Hi guys,

I'm a newbie to openwrt. I have used Tomato by Shibby in the past, but would like to try out openwrt. I have the Linksys WRT1900ACS and I'm very confused on what firmware to choose. What I'm looking for is stability and speed with added functions that's not in the OEM firmware I also know I will need to flash something that already has the LuCI web GUI installed because I don't want to ssh/telnet to the router to do it later, so with that in mind what do you all recommend for stability/ performance with added features not found in OEM firmware and with LuCI web GUI installed?

Please advise and thank you in advance for your help.

Start with 15.05.1 may server your request Please find it at https://downloads.openwrt.org/chaos_cal … /generic/. Simply upgrade to the so called "openwrt-15.05.1-mvebu-armada-385-linksys-shelby-squashfs-factory.img" in your Linksys firmware web interface (WRT1900ACS has the code name shelby). BTW, flashing between OFM and OpenWrt is very easy. ..and enjoy.

And, you better upgrade the wifi driver to the new version 10.3.0.17. Please find it at https://github.com/NemoAlex/mwlwifi-bin … r/15.05.1.

Regarding crypto and HW acceleration...

Here is my "original" configuration with decent crypto performance, WRT1900ACS:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5               9389.98k    32306.22k    94967.38k   167082.33k   219785.90k
sha1              6629.30k    18147.99k    37536.71k    51512.66k    58307.11k
des cbc          24228.04k    25278.26k    25511.73k    25512.96k    25650.00k
des ede3          9253.49k     9468.46k     9539.55k     9567.04k     9530.03k
aes-128 cbc      34693.14k    39816.11k    41683.80k    42328.19k    42254.34k
aes-192 cbc      31545.96k    34799.21k    36341.35k    36898.37k    35665.81k
aes-256 cbc      29286.46k    30779.94k    32155.47k    32528.73k    32691.29k
sha256            7234.63k    16872.51k    30481.92k    38228.65k    41390.15k
sha512            1761.70k     7015.13k    10239.23k    13994.67k    15676.76k
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.034198s 0.000903s     29.2   1107.8
                  sign    verify    sign/s verify/s
dsa 2048 bits 0.009249s 0.011301s    108.1     88.5

Here is the version appending -engine cryptodev to the openssl speed command:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5               4134.82k    15713.71k    58738.53k   222495.03k  1735304.53k
sha1              4461.88k    16943.40k    76576.12k   317807.59k  1961984.00k
des cbc          24098.35k    25154.11k    25470.29k    25617.12k    25542.66k
des ede3          9271.67k     9479.66k     9536.73k     9578.15k     9609.22k
aes-128 cbc      35480.47k    39827.33k    41341.14k    42358.78k    42677.85k
aes-192 cbc      31795.15k    35301.67k    36718.08k    37066.41k    37014.19k
aes-256 cbc      28420.27k    31476.22k    32688.37k    32890.54k    32975.53k
sha256            7230.65k    16954.37k    30372.69k    38017.37k    40896.98k
sha512            1718.56k     6809.92k    10142.99k    14130.85k    15767.55k
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.029467s 0.000842s     33.9   1187.2
                  sign    verify    sign/s verify/s
dsa 2048 bits 0.007646s 0.009442s    130.8    105.9

Interestingly, you'll notice that the throughput on md5 and sha1 are much lower -- I believe this is the hardware offload capability.  Here are the initial lines of output from the openssl speed routine:

engine "cryptodev" set.
Doing md5 for 3s on 16 size blocks: 188651 md5's in 0.73s
Doing md5 for 3s on 64 size blocks: 184145 md5's in 0.75s
Doing md5 for 3s on 256 size blocks: 174380 md5's in 0.76s
Doing md5 for 3s on 1024 size blocks: 143405 md5's in 0.66s
Doing md5 for 3s on 8192 size blocks: 50839 md5's in 0.24s
Doing sha1 for 3s on 16 size blocks: 189630 sha1's in 0.68s
Doing sha1 for 3s on 64 size blocks: 182671 sha1's in 0.69s
Doing sha1 for 3s on 256 size blocks: 164519 sha1's in 0.55s
Doing sha1 for 3s on 1024 size blocks: 121040 sha1's in 0.39s
Doing sha1 for 3s on 8192 size blocks: 33530 sha1's in 0.14s
Doing sha256 for 3s on 16 size blocks: 1351227 sha256's in 2.99s

I think what this is saying is that for the first line (for example) for 3s of computation time only 0.73s of CPU time is being used -- the HW engine is offloading that work.

The CPU usage stays very low during the md5 and sha1 phases of the routine, then spikes up to high values and 100% during the rest of the routine.  So the HW offload keeps the CPU low but has lower throughput than the actual software rotuines.

I'm doing all these tests on live systems so there'll be some variability.  However, I haven't really seen a case where my CPU is at max so I'm not sure I want to enable the crypto engine.

Similar results on the V1 by the way, I'm not pasting here to keep an already long post from getting even longer.  Throughput on 16 byte md5/sha1 were reduced to 785k and 718k respectively, so much worse than original.

Also, there's a newer patch addressing all versions of hardware:
https://git.kernel.org/cgit/linux/kerne … 0d34454af7

Here's my version (4.4.6 kernel):

See kernel/git/next/linux-next.git commit 6e3695a741eca510f2517b7834bf790d34454af7
---
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -731,6 +731,7 @@ CONFIG_LOCKUP_DETECTOR=y
 CONFIG_CRYPTO_DEV_TEGRA_AES=y
 CONFIG_CPUFREQ_DT=y
 CONFIG_KEYSTONE_IRQ=y
+CONFIG_CRYPTO_DEV_MARVELL_CESA=m
 CONFIG_CRYPTO_DEV_SUN4I_SS=m
 CONFIG_CRYPTO_DEV_ROCKCHIP=m
 CONFIG_ARM_CRYPTO=y
--- a/arch/arm/configs/mvebu_v5_defconfig
+++ b/arch/arm/configs/mvebu_v5_defconfig
@@ -184,9 +184,9 @@ CONFIG_DEBUG_KERNEL=y
 # CONFIG_DEBUG_PREEMPT is not set
 # CONFIG_FTRACE is not set
 CONFIG_DEBUG_USER=y
+CONFIG_CRYPTO_DEV_MARVELL_CESA=y
 CONFIG_CRYPTO_CBC=m
 CONFIG_CRYPTO_PCBC=m
 # CONFIG_CRYPTO_ANSI_CPRNG is not set
-CONFIG_CRYPTO_DEV_MV_CESA=y
 CONFIG_CRC_CCITT=y
 CONFIG_LIBCRC32C=y
--- a/arch/arm/configs/mvebu_v7_defconfig
+++ b/arch/arm/configs/mvebu_v7_defconfig
@@ -154,3 +154,4 @@ CONFIG_MAGIC_SYSRQ=y
 CONFIG_TIMER_STATS=y
 # CONFIG_DEBUG_BUGVERBOSE is not set
 CONFIG_DEBUG_USER=y
+CONFIG_CRYPTO_DEV_MARVELL_CESA=y
anomeome wrote:

@mrfrezee
I don't know if it's normal, but certainly not right given what I am trying to achieve. Thanks for the keen eye. I do have the /dev/crypto file. I flashed another image with define changes for openssl. My numbers were better, but still not great, so went back to check on whether the CESA define was in my build_dir config file, and it was not. So that earlier change set is not taking effect. I have created a patch from the nitroshift link and doing a new build for another test.

So if CONFIG_CRYPTO_DEV_MARVELL_CESA is set in target/linux/generic/config-4.4, it doesn't work ?

I always tend to dirclean each time i touch kernel settings because build_dir doesn't update correctly. Are you doing that as well ?

@mrfrezee
Correct, even though I had set it to 'y' in the config-4.4, it was not showing up in the mvebu_v7_defconfig file for me. I had to create a patch file from the git. My normal procedure would be to do just a make clean, unless things have gone South in my build dir.

Edit:
New paste. Included settings used in the openssl.cnf file. Numbers are better but lower than post by InkblotAdmirer, especially aes-128 which is what started me down this path. Still something not quite right with my build.

(Last edited by anomeome on 5 Apr 2016, 16:49)

Sorry, posts 10651 to 10650 are missing from our archive.