Hi All, so as i had said. Im not familiar with GIT. Previsouly i was using SVN to update/compile my own images.
As one forum member told here few posts ago. SVN has been discontinued. I was advised to use Git.
So ive gone ahead with doing the whole "git clone" thing.
Now when i try to do "git pull" to get upto the latest build. It gives me error:
----------------------------------------------------------------------------------------------------------------------------------------------
ali@ali-virtual-machine:/openwrt$ git pull
fatal: Not a git repository (or any parent up to mount point /media/ali/2a31be03-830e-4b99-ac3f-10a60ac8d2d0)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
----------------------------------------------------------------------------------------------------------------------------------------------

i can run the script update and install commands fine. I would really like some suggestions.
in the above error. The "/media/ali/2xxxxxxx" path is where my "openwrt" build folder resides

Then CD to openwrt and run these 2 commands

./scripts/feeds update -a
./scripts/feeds install -a

Then you need to open menuconfig
make menuconfig

Chose what you want, then save and close.
make V=s

Thanks, so in the past I used to do "Svn up" to get to latest build revision. I don't need to do "gift pull" as a similar step. Or even my Svn up step was useless in the past?
The script update and install will put me at the latest revision?
I know the steps afterwards.

marvell-cesa f1090000.crypto: CESA device successfully registered

BAM!!  Loading on ACS.  As suspected there is a bug in the device tree for the armada-385 platform.  Add this patch somewhere:

--- a/arch/arm/boot/dts/armada-385-linksys.dtsi
+++ b/arch/arm/boot/dts/armada-385-linksys.dtsi
@@ -58,8 +58,8 @@
     soc {
         ranges = <MBUS_ID(0xf0, 0x01) 0 0xf1000000 0x100000
               MBUS_ID(0x01, 0x1d) 0 0xfff00000 0x100000
-              MBUS_ID(0x09, 0x09) 0 0xf1100000 0x10000
-              MBUS_ID(0x09, 0x05) 0 0xf1110000 0x10000>;
+              MBUS_ID(0x09, 0x19) 0 0xf1100000 0x10000
+              MBUS_ID(0x09, 0x15) 0 0xf1110000 0x10000>;
 
         internal-regs {

I just appended it to the 010 patch in target/linux/mvebu/patches-4.4 which creates the shelby.dtb entry.  I think this will fix shelby, caiman and cobra.

And now the testing can begin in earnest (and hopefully no other bugs).

Anyone else having problems with RP-PPPoE plugin version 3.8p compiled against pppd 2.4.7?
Model Linksys WRT1900AC V1
Firmware VersionOpenWrt Designated Driver r49168 / LuCI Master (git-16.100.63971-9c77aea)
Kernel Version4.4.7.
Dhcp is fine.

Nicely done ! What a great debug work, you saw a failure, found where the bug was, and told us how to fix it, in less than 48h.

I created a clean patch for this, based on your suggestions, available here:
https://openwrt.nc-network.io/logs_and_ … dtsi.patch

I'm also building a public firmware tonight with marvell-cesa included to have more feedback from the community on Crypto Acceleration.

Edit: Changed file location to my server.

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

That seems to originate from the Linux kernel itself:
https://git.kernel.org/cgit/linux/kerne … v4.4.7#n59

Due to commit: https://git.kernel.org/cgit/linux/kerne … e560048941

Whole patch: https://git.kernel.org/cgit/linux/kerne … e560048941
(Curiously, just this armada-385-linksys.dtsi deviates from the others in the range definition.)

(Last edited by hnyman on 16 Apr 2016, 11:24)

Hi,

I just could not login anymore with my old user, gone. So i created a new one...

I tried to use my IPhone 6plus with latest IOS for tethering through USB but I didn't got it to work. The phone were be found by the wrt1900acs but it got no virtual network port assigned.

Upgrading to the latest packages was not the solution due to kernel 3.18 was to low. I thought may the phone is to new and not fully integrated into the packages which are neccessary for tethering.

Now one of may questions:

Which image shell I use, like I readed the snapshot and 15.05.01 Chaos Calmer are using the 3.18 kernel. I flashed now the image from davidc502 which is based on 4.4.6. But here I can see that a lot of packages are blocked for updating through opkg.

What is the best solution if I want to upgrade the installed packages from time to time to the latest existing? I am not so deep into the image building until now, what meens that I can't build my own image with the imagebuilder yet.

I need to use the following services:
- bind dns server as secondary master for several a web domain's
- dlna
- openvpn with policy based routing (to unlock georestrictions)
- ssh & sftp as secondary backup space from webservers
- realtime traffic monitoring (not used yet, but neccessary in the future)
- nfs & samba services
- dhcp lan
- no ip6 neccessary at all
- tethering with iphone 6 plus

So which image is the most actual with newer kernel and easy to upgrade?

Thank you!

(Last edited by thx4wrt on 16 Apr 2016, 11:27)

@thx4wrt

You can use my package repository (currently in 4.4.6) with david's builds without problems (you need to change your /etc/opkg.conf tho) or use one of my builds which come with opkg preconfigured with my repository feeds and keys.

A question to all about the 'Wireless speed' on a WRT1900ACS. The tests are done within a time frame of 2 minutes. I'm using mrfrezee first build.
I have a broadband internet connection of 150mb(it)s/15mb(it)s.
Wired speed test to wan gives me full speed on Ooklaspeedtest.
Wireless speed on wan gives me 40mb(it)s/15m(it)s Ooklaspeedtest on the same laptop 5GHz AC ch149.
Wireless upload from the server (on lane) gives me 20mB(yte)S/?.
My question is this a problem of the wireless driver or some other sw or setting?

I now know how to put in custom feeds to builds, and will add your repositories that way people shouldn't have to think about them.

Under System>Software>Configuration>Distribution feeds, paste the following, replacing what is in there now.

src/gz designated_driver_base  http://openwrt.nc-network.io/repo/4-4-6/mvebu/packages/base

src/gz designated_driver_kernel http://openwrt.nc-network.io/repo/4-4-6/mvebu/packages/kernel

src/gz designated_driver_telephony http://openwrt.nc-network.io/repo/4-4-6/mvebu/packages/telephony

src/gz designated_driver_packages http://openwrt.nc-network.io/repo/4-4-6/mvebu/packages/packages

src/gz designated_driver_routing http://openwrt.nc-network.io/repo/4-4-6/mvebu/packages/routing

src/gz designated_driver_luci http://openwrt.nc-network.io/repo/4-4-6/mvebu/packages/luci

src/gz designated_driver_management http://openwrt.nc-network.io/repo/4-4-6/mvebu/packages/management

#src/gz designated_driver_base http://downloads.openwrt.org/snapshots/ … kages/base
#src/gz designated_driver_kernel http://downloads.openwrt.org/snapshots/ … ges/kernel
#src/gz designated_driver_telephony http://downloads.openwrt.org/snapshots/ … /telephony
#src/gz designated_driver_packages http://downloads.openwrt.org/snapshots/ … s/packages
#src/gz designated_driver_routing http://downloads.openwrt.org/snapshots/ … es/routing
#src/gz designated_driver_luci http://downloads.openwrt.org/snapshots/ … kages/luci
#src/gz designated_driver_management http://downloads.openwrt.org/snapshots/ … management
# src/gz designated_driver_targets http://downloads.openwrt.org/snapshots/ … es/targets

(Last edited by davidc502 on 16 Apr 2016, 20:16)

@david

Be aware that with the recent kernel release (4.4.7), i put two directories in my repo (respectively 4-4-6/mvebu and 4-4-7/mvebu) where the old repo directory (mvebu) is a symbolic link to the 4.4.6/mvebu to avoid breaking older releases. Change your default opkg config in your future releases accordingly

Also, use the <code> BBcode when pasting config file so links don't get truncated

Edit: I'm currently building a 4.4.7 firmware and his repository (Changelog and Live Build Log)

(Last edited by mrfrezee on 16 Apr 2016, 15:38)

Will adjust accordingly -- Thank you

Have you heard how long it will be before 4.4.7 is mainstream?

(Last edited by davidc502 on 16 Apr 2016, 15:52)

Dunno, last time it was quick, less than 48h...
Linux Kernel released on Mar 16 08:43:17 2016 GMT-7
Pushed in trunk on Mar 17 22:41:07 2016 GMT+1

It's variable but shouldn't take too long. Most of the patches (at least on mvebu) can be fixed in less than 10 minutes.

@hnyman

Poring through that is exactly how I found the typo.  Far be it from me to second-guess the developers for a typo when they covered so many platforms and variants.  The fact that they provided this code in the first place is awesome.  But yes, this typo is committed in the linux kernel.

With this build on the WRT1900ACS:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5                930.31k     2797.46k    11128.32k    44672.34k   267168.43k
sha1               941.56k     2805.85k    11215.96k    44183.55k   215536.96k
des cbc          48727.29k    51189.09k    51693.21k    52092.18k    51901.90k
des ede3         18303.90k    18496.53k    18505.74k    18706.29k    18708.24k
aes-128 cbc      78981.50k    89380.74k    93295.62k    94101.86k    94552.93k
aes-192 cbc      68916.32k    76595.41k    78678.07k    80589.27k    80906.87k
aes-256 cbc      62059.69k    68451.16k    70832.96k    71212.15k    71615.21k
sha256           14853.30k    36055.59k    64317.95k    81223.34k    87888.49k
sha512            3516.94k    13948.27k    19834.62k    28009.56k    30528.85k
                  sign    verify    sign/s verify/s
rsa 2048 bits 0.015787s 0.000445s     63.3   2245.4
                  sign    verify    sign/s verify/s
dsa 2048 bits 0.004161s 0.004949s    240.3    202.0

NOW we're getting somewhere!  That's with the -multi 4 flag set for openssl.  Not sure if 4 is the right number, still trying to figure out for sure how all this ties together.  For example, with no additional flags:

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
md5               3079.20k    12833.35k    56356.57k   207228.34k  2556201.89k
sha1              3934.04k    11223.04k    65780.05k   194310.92k  2234982.40k

So there must be additional overhead routing to multiple engines.  Right now, in all cases, only the md5 and sha1 are shifting CPU to kernel, so my gut tells me there's more to be done here.  When there are multiple drivers for a given cipher or hash, how do we force the use of cesa?  Unload all the other drivers?

@Nihilanth, @kirkgbr

Add the following in /etc/config/wireless

option htmode 'VHT40'

under 'radio0' section then restart wifi and please report the speed you are seeing.

Thanks.

nitroshift

(Last edited by nitroshift on 16 Apr 2016, 18:45)

Thank you.  Will give it a go tonight!!

EDIT: Do you mean change?

        option htmode 'HT20'
to
        option htmode 'VHT40'

(Last edited by kirkgbr on 16 Apr 2016, 22:46)

I have just flashed my new Linksys 1900AC V2 with recommended (September 11, 2015) official release for V2 -  https://downloads.openwrt.org/chaos_cal … actory.img

This hardware is supposed to have 128 MB flash memory. After I flashed the router, this is what I got:

$df -h
Filesystem                Size      Used Available Use% Mounted on
rootfs                   23.6M    520.0K     21.9M   2% /
/dev/root                 2.5M      2.5M         0 100% /rom
tmpfs                   251.8M      1.1M    250.7M   0% /tmp
/dev/ubi0_1              23.6M    520.0K     21.9M   2% /overlay
overlayfs:/overlay       23.6M    520.0K     21.9M   2% /
ubi1:syscfg              29.6M    284.0K     27.7M   1% /tmp/syscfg
tmpfs                   512.0K         0    512.0K   0% /dev

Pardon my ignorance. I'm confused where's the rest of 128 MB. rootfs is only 23.6 MB.

Is there a way to use rest of the memory?

Thanks

(Last edited by arun157 on 17 Apr 2016, 02:13)

So there is still something wrong with the configuration on the armada-385.  Invoking the AES hw encryption hangs the machine, I'm still digging for this.  The crypto engine is working -- the MD5 and SHA1 speed tests use predominantly system cpu (and are blazing fast) when openssl is compiled with hash support.

Here are results on the 1900ACV1 (openssl speed -evp aes256):

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc       1869.05k     7132.06k    19423.09k    87196.29k   840908.80k

That performance results in 20% system cpu% on one core, and 6% system cpu on the other.

Yes.

nitroshift

@arun157

Flash memory is split in 2: the main firmware and the backup one, each occupying half of it.

nitroshift

VHT40 kills the 2.4g radio - does that work for you? I've always used VHT20 which works well for me..

radio 0 is the 5ghz radio, not the 2.4ghz.
So do NOT use VHT40 on 2.4ghz (radio 1). For radio 1 i always just use HT20

edit - nevermind, seems that on the V1, the 2.4 and the 5ghz radio are switched, compared to the V2/ACS?

(Last edited by JohnnySL on 17 Apr 2016, 11:56)

Here's the relevant part of my /etc/config/wireless:

config wifi-device 'radio0'
    option type 'mac80211'
    option hwmode '11g'
    option path 'platform/soc/soc:pcie-controller/pci0000:00/0000:00:02.0/0000:02:00.0'
    option txpower '20'
    option country 'RO'
    option htmode 'VHT40'
    option noscan '1'
    option channel '5'

With these settings I'm seeing full 600mbps bandwidth.

nitroshift