That is strange because I chose them in the menuconfig, and compiled with no errors, so assumed they would be there.

Will look at it tonight.

@JW0914

You can update the wiki now, my repo will be up as soon as the DNS records are refreshed

@thx4wrt

Any news on this USB2 issue ?

Edit: Updated link, Dropbox reorganized

(Last edited by mrfrezee on 19 May 2016, 16:05)

Change in yourRouterModel dsti in USB2 section address from 5000 to 5800 ( maybe i miss some zero digit:-)

https://www.dropbox.com/sh/83hqzhzu8zj1 … patch?dl=0
I applied this patch so it should work.

Edit: BTW, i'm finally back online \o/

(Last edited by mrfrezee on 17 May 2016, 17:44)

@mrfrezee

Are you by chance testing on mamba? Btw. 4.4.9 includes the fix.

I have a v1 (mamba) but i use the eSATA port
I will test as soon as the family is asleep.

@mrfrezee, while your repo is fully online, I just register to report status for you.
I am updated to your dropbox file, use bin_4.4_r49337(openwrt-mvebu-armada-385-linksys-shelby-squashfs-sysupgrade.tar). but failed to use local repo for some packages i need. and my setup can install packages from your repo now.
I use NTFS formatted USB drive for samba/rsync, mountd/ntfs-3g/rsyncd installed and functional. thanks for your repo,

although I did not test on USB2 (USB/eSATA) port before, but now I can confirm the USB drive work normally on USB2 too.

thanks again & cheer!

armada-385-linksys are all but mamba, so the patch has no effect for you, will look into it a bit later today.

Oh right, it's armada-xp... I'm get so lost sometimes with all their hardware changes but with the same name...

Glad to hear it and sorry for the unexpected downtime

(Last edited by mrfrezee on 17 May 2016, 18:52)

@mrfrezee

The are apparently two usb2 ports on the xp soc, maybe it's just that the other one is wired to the back.
You can try https://gist.github.com/anonymous/e9295 … 3100ffea8a

@JW0914

The Wiki at "Linksys WRT1X00AC/S Series" listed here:

https://wiki.openwrt.org/toh/linksys/start

is very much improved.

Two items may require a second look.

First:
When the WRT1200AC was introduced; Belkin/Linksys changed the CPU port configuration inside the router. The universal Wiki, Linksys WRT1X00AC/S Series, doesn't note the change.

The reference to the "Linksys WRT11200AC" is here https://wiki.openwrt.org/toh/linksys/wrt1200ac at the bottom of the page.

The port configuration for the WRT1900AC & WRT1200AC SEEM to be as follows:

                                    WRT1900AC v1                                WRT1200AC
Internal CPU port                  6                                                        5
Internal Numbering               4                                                        4
External Connector           WAN                                                  WAN

Internal CPU Port                 5                                                        6
Internal                          LAN Switch                                        LAN Switch
Internal Numbering          0 1 2 3                                                0 1 2 3
External Connector          4 3 2 1                                                4 3 2 1

Question: Is the port configuration for the WRT1900AC v2 & WRT1900ACS the same as the WRT1200AC?

Second
With a newly updated "universal" WRT1X00AC page, I would suggest the pages for the WRT1200AC & WRT1900ACS be removed.  It seems to me that having the universal page covers ALL variables.  With 3 pages, information would have to be parsed and updated across 2 extra pages.

If the pages need to stay, I suggest that the current contents be removed with only a link to the universal page.  In the interest of completeness; pages should be listed for all four WRT1200AC, WRT1900AC v1, WRT1900AC v2 & WRT1900ACS with links back to the universal page.

Thanks again for the efforts of all that contributed

Rick

Is the hardware offload patches applied to (./openwrt/target/linux/mvebu/patches-4.4) and does it work for 4.4.10? My build does compile with 4.4.10 in kernel-version.mk but when I applied the bm patches it gives errors (I suspect I either didn't put it in the right place or they are not applying correctly to 4.4.10)

(Last edited by lifehacksback on 17 May 2016, 20:44)

Results:

root@OpenWrt:~# openssl engine
(dynamic) Dynamic engine loading support
root@OpenWrt:~# openssl speed -evp aes256
Doing aes-256-cbc for 3s on 16 size blocks: 3539046 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 64 size blocks: 941391 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 256 size blocks: 239274 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 1024 size blocks: 60062 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 7514 aes-256-cbc's in 3.00s
OpenSSL 1.0.2h  3 May 2016
built on: reproducible build, date unspecified
options:bn(64,32) rc4(ptr,char) des(idx,cisc,2,long) aes(partial) blowfish(ptr)
compiler: arm-openwrt-linux-muslgnueabi-gcc -I. -I.. -I../include  -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -I/home/openwrt/trunk-public/staging_dir/target-arm_cortex-a9+vfpv3_musl-1.1.14_eabi/usr/include -I/home/openwrt/trunk-public/staging_dir/target-arm_cortex-a9+vfpv3_musl-1.1.14_eabi/include -I/home/openwrt/trunk-public/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-5.3.0_musl-1.1.14_eabi/usr/include -I/home/openwrt/trunk-public/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-5.3.0_musl-1.1.14_eabi/include/fortify -I/home/openwrt/trunk-public/staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-5.3.0_musl-1.1.14_eabi/include -znow -zrelro -DOPENSSL_SMALL_FOOTPRINT -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DOPENSSL_NO_ERR -DTERMIOS -Os -pipe -march=armv7-a -mtune=cortex-a9 -mfpu=vfpv3-d16 -fno-caller-saves -fno-plt -fhonour-copts -Wno-error=unused-but-set-variable -Wno-error=unused-result -mfloat-abi=soft -iremap /home/openwrt/trunk-public/build_dir/target-arm_cortex-a9+vfpv3_musl-1.1.14_eabi/openssl-1.0.2h:openssl-1.0.2h -Wformat -Werror=format-security -fstack-protector -D_FORTIFY_SOURCE=1 -Wl,-z,now -Wl,-z,relro -fpic -fomit-frame-pointer -Wall
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc      18874.91k    20083.01k    20418.05k    20501.16k    20518.23k

CPU use during a ~10 minute download at 5.0-5.5 MB/s over VPN using AES-256-CBC cipher:
https://www.dropbox.com/s/qka5h4oashys6ng/cpu.png?dl=0
How high should softirq use be?

@elxr
Does not look like you have the CESA device. Here is  output from a V1.

@lifehacksback
Assuming you are talking about the BM patchset? If so it is compiling on 4.4.10 for me, but I think I am using the "other" set.

(Last edited by anomeome on 17 May 2016, 23:14)

Indeed. I remember now. For some reason @nitroshift 's patches weren't compiling but the one made by david or someone else did compile. Now i have to either fix or look for the ones that do compile.

This point aside, 4.6 came out would be fun to have a router running a newer kernel than my laptop (Arch so prob not for long).

Thanks to all

EDIT
It was mrfreeze's patches that worked: https://www.dropbox.com/sh/ff57qijgv9w3 … iGnOa?dl=0

(Last edited by lifehacksback on 18 May 2016, 01:10)

The BM patch appears to be in trunk.

root@OpenWrt:~# find / -name mvneta
/proc/irq/27/mvneta
/proc/irq/28/mvneta
/sys/bus/platform/drivers/mvneta
/sys/module/mvneta
root@OpenWrt:~#

@arokh @davidc502 @mrfreeze
I've added your builds to the community builds firmware section

In order for the Table of Contents to make more sense, I encompassed Stable & Trunk builds under "OpenWrt Builds", which creates a nicely indented ToC list for OpenWrt Builds and Community Builds

I did have an issue coming up with unique words to describe each of your builds, and if you guys, or any other members, have ideas for better wording, please share =]

• arohk's is: "Fully Customized Trunk [DD] Build"

• davidc502's is: "Stable, Customized Trunk [DD] Build"

• mrfreeze's is: "Moderately Customized Trunk [DD] Build"

I looked at the build info pages [or thread in arohk's case], and everything I was coming up with to describe them was far more than a few words.  I originally had a nice description of each build under it's respective heading, however it looked out of place and I opted instead for linking to the respective build info pages.  With that being said, I'd still like to come up with something unique that describes what each build is in 4 - 5 words.

@davidc502
When you have time, or when you next update your build, could you also include md5sums and sha256sums master files with all respective hashes in them?  The main reason I ask is it would allow a cohesive template followed across all builds listed; with the more minor issue being the actual sha256sums string can't be linked to because it's included in every individual build's sums file.

Also, I made the color of your build section Red to match your signature; however, after applying the info to the wiki, it occurred to me most are accustomed to seeing red text as warnings.  If you'd like me to change the color, please let me know

@mrfreeze
A quick heads up: the email link on your build info page outputs the send to address as: contact(at)nc-network(dot)io

@rickstep
Thanks =]

I've tentatively updated the port layouts section to differentiate between the WRT1900ac v1 and all others .  I made the assumption the port layouts probably changed on the v2 and acs, however this will need to be confirmed.

I also thought it prudent to remove the redundant individual device pages, however I didn't want to simply make the decision on my own to do so.  If most members believes this to be the best thing going forward, give me a few days to coalesce the unique info in each into the WRT1X00AC/S Series wiki

@aluisperezh
Thanks =]

(Last edited by JW0914 on 18 May 2016, 01:57)

@davidc502
The BM unit is one of a few offload units on the mvneta network device

Re: 4.5/4.6 kernel, has anyone looked to see if support for any of the other units has been added?

Feel free to change the color if you like, as I don't have a preference.

yes, I can include Master md5 and sha256 sums.. I'm kind of curious about how others are doing it... Are they just compiling themselves or done via a script?

One of these packages is requiring a XML parser in perl to compile. I've tried installing several times, and is failing.

@elxr

openssl engine:

(cryptodev) BSD cryptodev engine
(dynamic) Dynamic engine loading support

If you don't see the cryptodev line then openssl doesn't see the cryptodev engine.  Cryptodev must be forced to compile before openssl when building.

openssl speed -evp aes256

Doing aes-256-cbc for 3s on 16 size blocks: 170449 aes-256-cbc's in 0.05s
Doing aes-256-cbc for 3s on 64 size blocks: 160233 aes-256-cbc's in 0.10s
Doing aes-256-cbc for 3s on 256 size blocks: 158817 aes-256-cbc's in 0.01s
Doing aes-256-cbc for 3s on 1024 size blocks: 117017 aes-256-cbc's in 0.05s
Doing aes-256-cbc for 3s on 8192 size blocks: 28523 aes-256-cbc's in 0.01s

Time <<< 3s indicates engagement of the cesa engine.

Last, there is no correct number for the softirq, it will depend on which cipher your VPN is using and how much traffic you're generating.  If virtually all cpu is user then the HW engine isn't being engaged.

Also, I'm not sure the V1 engine (armada-xp) includes AES in the crypto engine.  Testing above was performed on an ACS (armada-385).  If you want crypto on the VPN you'll have to select a cipher the armada engine supports.

Once you pass the first two tests openvpn should automatically use the hw acceleration if the selected cipher is supported.

@anomeome @InkblotAdmirer

I actually am using an ACS. And the CESA/crypto device does seem to be there, unless I'm reading this wrong:

root@OpenWrt:~# egrep '^module|^name' /proc/crypto
name         : hmac(sha256)
module       : marvell_cesa
name         : hmac(sha1)
module       : marvell_cesa
name         : hmac(md5)
module       : marvell_cesa
name         : sha256
module       : marvell_cesa
name         : sha1
module       : marvell_cesa
name         : md5
module       : marvell_cesa
name         : cbc(aes)
module       : marvell_cesa
name         : ecb(aes)
module       : marvell_cesa
name         : cbc(des3_ede)
module       : marvell_cesa
name         : ecb(des3_ede)
module       : marvell_cesa
name         : cbc(des)
module       : marvell_cesa
name         : ecb(des)
module       : marvell_cesa
name         : digest_null
module       : crypto_null
name         : compress_null
module       : crypto_null
name         : ecb(cipher_null)
module       : crypto_null
name         : cipher_null
module       : crypto_null
name         : xz
module       : kernel
name         : lzo
module       : kernel
name         : deflate
module       : kernel
name         : ecb(arc4)
module       : kernel
name         : arc4
module       : kernel
name         : aes
module       : kernel
name         : des3_ede
module       : kernel
name         : des
module       : kernel

It's mrfrezee's OpenWRT build that I'm running on my ACS. Could it be that the problem lies with his build of libopenssl (and openvpn-openssl?) or could I have missed something to make this work?

@JW0914

Another round.

General Notes
-------------
I agree with Rick that the individual pages can be reduced to a link (or a redirect if possible) to the shared page once all valuable info is incorporated into the shared page.
The page is rather colourful, more for decorative purpose than to convey information. At least those shades of gray on gray background forced me to increase font size by a tick to comfortably read it.
I thought it might be better to present the builds in tabular than tree form.

Introduction
------------
Please see Header -> Please see Serial Port
USB-TTL cables come in two forms -> move to serial port section (with some added bonus notes maybe)

firmware - stable
-----------------
"Chaos Calmer Repository" link points to 15.05 (are variables supported by the wiki so this could be made somewhat future-proof?)

community builds
-----------------
The displayed hashes might not be out of date daily but maybe weekly.

flashing firmware
-----------------
the notes about default password and how to backup linksys settings probably should be moved to oem -> openwrt

openwrt -> openwrt
------------------
oem -> openwrt uses "downloaded from the Firmware section", better but you could have built your own - not sure there is a better option than leaving it out.
missing first login

oem -> openwrt
--------------
Telnet in and install luci. Telnet in is probably the difficult part, yet the guide continues to explain how to use opkg to install luci which is already covered by the reference to luci.essentials. On top telnet is gone in trunk. Me thinks https://wiki.openwrt.org/doc/howto/firstlogin does a better job. I particularly like the note about good passwords there.
The note about refreshing network and modems isn't specific to this sub-section and should be moved up a level.

video tutorials
---------------
what is this tutorial about? Flashing using tftp by lifehacksback.

Reading about cesa in here made me want to give it a try, wont be doing sensitive stuff on the device anyway.

Took me 3 builds to get there. Those[1] are the relevant changes I made for cesa on shelby using 4.4.10 and trunk. Credit for 915 and 916 go to InkblotAdmirer.

[1] https://gist.github.com/anonymous/9d736 … 27caf9bc53

How would I go about setting up a redirect for the individual hardware pages? (As that's a great suggestion and would be better than simply having a link redirecting the user to the WRT1X00AC/S Series Wiki)

As to tabular form, how would I go about doing that, as that's a great idea =]

I was worried about that when i decided to go with dark grey [100 x3] and light grey [125 x3].  Was it only the light grey, or both, that was difficult to read?  I'll darken both, moving dark grey to [75 x3] and light grey to [100 x3], at least until I hear back from you about whether the [100 x3] was also difficult to read.

Whenever I write, or reformat, wikis, I always try to include color as it breaks up the monotony and creates easier to read information with clear section breaks.  I also wanted to differentiate the main, or important, information from annotations or notes, and utilize the dark/light greys for that.

[Introduction] will do

[Firmware] Fixed [I could have sworn I updated that the other day, as all the build links point to 15.05.1... Its possible when I was doing some reformatting a few days back that an older page version was accidentally applied.]

I thought that might be an issue as well, however each community build lists the build images in custom links specific to each build version (arohk's  points to subdirectory r49166, davidc509's to Kernel4.4.7, with mrfreeze's pointing to a general mvebu directory); because of this, I've set calendar reminders to double check the the build repositories once a week [Sundays] to ensure the links and hashes are kept up to date.

In combination, if any member sees they're out of date, please shoot me an email (via profile page or via: jw0914@live.com)

Good catch and great points =]  I'll update with the suggested changes later on today

I meant to make the suggested changes regarding the luci essentials wiki a few days ago, as you've suggested that three times now.  Whenever I add or edit information that's been suggested, I always have the post with the suggestions side by side with the wiki, and I must have overlooked [or forgot] to make that change.

Now that you mention it, I've never taken a look at it because I don't utilize Mac's; however I should have since I've been updating the wiki. 

I'll add a header above the video listing that it's a Video Tutorial about flashing via TFTP.  Also, should I move the Video Tutorials section to the Troubleshooting Section?

(Last edited by JW0914 on 18 May 2016, 13:01)