That's possible, too. I had been working on the assumption that David had the same issue that Dheeran Senthilvel wrote about on the LEDE mailing list, which someone has already linked to here. In that case at least the last problem he had was due to u_env being invalid and the bootloader not saving the defaults when reset.

The thing is that fw_setenv in Linux will save a set of defaults when it finds an invalid/empty partition. It then checks out as correct since it has a valid checksum, but it's lacking the values the Marvell u-boot is looking for. The auto_recovery stuff mucks this up a little more when it falls back and writes out a new value for 'boot_part'. In that case, sysupgrade will write the new image (unlike in David's case) but it won't come back correctly after the reboot.

(Last edited by leitec on 14 Jun 2016, 16:21)

I did a test build for the ACS using LEDE source a few weeks ago and had issues updating configs.  Some would take but after a reboot the device would be mounted as read-only.  I didn't bother to troubleshoot since I didn't have time and others were seeing issues and reporting them.

I built a new image with latest commits yesterday and no issues so far.

And KWB config is?  why we do not have it for another 1900 router?

I double-checked that this is the case, should somebody with a 1200AC/1900v2/ACS should want to try. My exact procedure was:

root@wrt1900ac:~# dd if=/dev/mtd0 of=/tmp/uboot.img
2048+0 records in
2048+0 records out
root@wrt1900ac:~# 

then

scp root@wrt1900ac:/tmp/uboot.img .
hexdump -C uboot.img > dump1
hexdump -C u-boot-uart.kwb > dump2

dirk$ diff dump1 dump2 | head
1,2c1,2
< 00000000  8b 00 00 00 00 61 0c 00  01 01 00 90 00 90 01 00  |.....a..........|
< 00000010  00 00 00 00 00 00 00 00  00 02 01 00 00 00 01 da  |................|
---
> 00000000  69 00 00 00 00 61 0c 00  01 01 00 90 00 90 01 00  |i....a..........|
> 00000010  00 00 00 00 00 00 00 00  00 02 01 00 00 00 01 b8  |................|
<snip>
dirk$ 

ignoring the snipped-off tail (the partition is bigger than the image), only the byte at position 0x0 and the byte at 0x1f differ. Using a hex editor, I changed them to match u-boot-uart.kwb (0x0 = 0x69, 0x1f = 0xb8) it then boots fine with:

kwboot -a -b uboot.img -t /dev/ttyUSB5

this is the "special" kwboot someone posted a while ago with the -a flag. The upstream u-boot version may have since incorporated this.

edit: in case anyone's wondering, kwboot -p (which is supposed to make the nand image bootable) did not work. The byte at 0x1f is also significant, though I haven't checked what it means.

edit2: it's a checksum, so it'll be a little more complicated than just changing it to match what's here

(Last edited by leitec on 14 Jun 2016, 18:33)

@leitec

Isn't that  just the -p option?

ie no hexedit and

kwboot -p -a -b uboot.img -t /dev/ttyUSB0

Yeah, the version of kwboot I used (the one nitroshift provided a while ago) didn't update the checksum so -p failed. I just compiled a new one from u-boot git and it works fine with the raw mtd dump and just "-p".

(Last edited by leitec on 14 Jun 2016, 18:45)

So once again, make backups before playing.

Thanks for testing.

here it is for 1900acs.

$ diff dump1 dump2 | head

1,4c1,4
< 00000000  8b 01 00 00 a0 dd 0d 00  01 01 00 30 00 30 01 00  |...........0.0..|
< 00000010  00 00 00 00 00 00 00 00  00 04 00 00 00 00 01 02  |................|
< 00000020  02 01 ac 21 02 00 00 00  5b 00 00 00 68 00 00 00  |...!....[...h...|
< 00000030  ff 5f 2d e9 c1 02 00 fa  00 00 a0 e3 ff 9f bd e8  |._-.............|
---
> 00000000  69 00 00 00 00 61 0c 00  01 01 00 90 00 90 01 00  |i....a..........|
> 00000010  00 00 00 00 00 00 00 00  00 02 01 00 00 00 01 b8  |................|
> 00000020  02 01 98 80 02 00 00 00  5b 00 00 00 68 00 00 00  |........[...h...|
> 00000030  ff 5f 2d e9 1c 00 00 fa  00 00 a0 e3 ff 9f bd e8  |._-.............|

(Last edited by gsustek on 14 Jun 2016, 19:01)

@gsustek, what binary are you comparing your mtd0 dump against?

from 1900ac

https://github.com/nitroshift/wrt1900ac … t-uart.kwb

from where i can download or build kwb for 1900acs?

There isn't one that Linksys or anyone else has provided yet, but what we're saying here is that we can make a bootable backup ourselves. On my v1, I can just take a dump of mtd0 and boot it with a recent kwboot that correctly modifies the header with "-p".

(here's my binary for 64-bit Linux: https://staticky.com/dl/routers-misc/kwboot.gz)

The comparison with diff was just to show that there were only those two differences. It's now moot since recent versions of kwboot don't require you to make any changes to the NAND version flashed on your device.

thnx leitec.

i assume that you have been read this:

http://www.openstora.com/forum/viewtopi … amp;t=1211

Sure, no problem.

Not that particular page, but that's similar to what we're doing here.

Hi guys,

My 1200AC will arrive tomorrow and I'm wondering if it's currently totally safe to put either LEDE or OpenWrt on it. I've read the last few pages and people mention backing up certain things. Would I be safe if I backed those things up and then went ahead with the installation? If so, what do I need to back up specifically?

Thanks

I don't think anyone can every guarantee 'totally safe' :-)

That said, a lot of people are using it successfully.

If you don't have any config on the device, you don't need to worry about backing anything up.

You may find the WRT1X00AC/S Series Wiki helpful, as it will provide a lot of the information you'll need

Since I haven't had time in the last two weeks or so to finish up editing it, it doesn't discuss LEDE.  However, as it appears OpenWrt is dead in the water and will be for some time, I'll be adding LEDE info when I begin editing it again.

(Last edited by JW0914 on 15 Jun 2016, 03:13)

to all; please help me to troubleshoot, resolve this issue:-)
I have 1900acs router and i have try'd every build from CC 15.05.1 to latest LEDE and i have the same issue...
Router setup:
-SATA connected HDD(i was also connect it through USB3.0-issue remains)  http://sprunge.us/NjPP
-vsftpd(or nfs4)

When i upload through wifi (5GHz) from Laptop(Intel7625, or ipad Air2) large file(size 2-3 Gigs) it seems that OS runs out of memory(i don't have this issue, when i upload through the same wifi, through router LAN to another PC with vsftpd service). I have swap mounted to OS(sometimes i have even 4-6 MB occupied).

  last graph is before crash wifi->vsftpd->SATA HDD, firtst three is wifi->ethernet->ethernet(PC)->vsftpd

some logs,(free, dmesg,meminfo)

http://sprunge.us/ZOKW
http://sprunge.us/iOMJ
http://sprunge.us/CBIe

Please give me some hints how to find what is causing this router restart, why swap isn't working:-)
what and how i can enable more traces..to resolve this issue,

also since both nfs (which runs in kernel space) and vsftpd (which runs in userspace) are affected it is unlikely to be a userspace program leak.

maybe its a problem with the buffer manager?
how the dataflow works there?
maybe it is something only triggered when the wifi driver needs to copy network data to the local system or something?
what i should look for in htop?
it does not occur with ethernet to ethernet 80MB/s
it does not occur with wifi to ethernet  50MB/s
it does occur with wifi to USB/SATA 30MB/s

i'm pretty sure that everyone has this issue...could anyone try?
i will try to add second swap partition on USB...

i found this:

https://stackoverflow.com/questions/367 … hes-on-smp

(Last edited by gsustek on 15 Jun 2016, 15:11)

maybe try the Gargoyle build?

http://lantisproject.com/gargoyle_ispyisail/

initial web gui log in password is "password"

(Last edited by mojolacerator on 15 Jun 2016, 15:12)

Yes modifying a mtd0 would probably work for the kwb binary but the image would have to come from a WRT that didn't have any nand corruption or bad blocks in the image itself. Which is scary because the only way to test comes with a high risk of bricking your router.

Having a KWB config file for WRT1200\1900 V1 V2 ACS would be awesome because we wouldn't have the brick risk and we could update u-boot on these routers.

thnx. i will try that, but it is also openwrt base, hm...DDWRT i should try at once:-)

\

do you think flashing back to Linksys Stock and then back to the latest lede build would clear up the issue?

yup, it is. I tried it for the first time this past weekend, I have been running dd-wrt(kong), it has been quite good, but the Gargoyle image seems to be working better for me then anything yet.
even passed the "teenager" test !

Thanks JW0914 for the info as well as the work on the wiki, it's appreciated, and thanks to everyone else who's involved with these routers and LEDE/OpenWrt.

It's now up and running on LEDE, I look forward to seeing the great people who make the community builds change over to LEDE.

I doubt it. Are you having any major issues with the router? Did you get the u-boot settings put back?

update: gargoyle crashed also.
but ddwrt is rock stable: with latest mwlwifi:

http://sprunge.us/YFiT

some crypto

root@1900acs:~# openssl speed -evp aes256
Doing aes-256-cbc for 3s on 16 size blocks: 6866010 aes-256-cbc's in 2.98s
Doing aes-256-cbc for 3s on 64 size blocks: 1957185 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 256 size blocks: 506758 aes-256-cbc's in 2.98s
Doing aes-256-cbc for 3s on 1024 size blocks: 128186 aes-256-cbc's in 3.00s
Doing aes-256-cbc for 3s on 8192 size blocks: 16038 aes-256-cbc's in 3.00s
OpenSSL 1.0.2h  3 May 2016
built on: reproducible build, date unspecified

compiler: ccache arm-openwrt-linux-gcc -I/mnt/intel/DEV4/src/router/zlib -L/mnt/intel/DEV4/src/router/zlib -I/mnt/intel/DEV4/src/router/openssl/crypto -fPIC -I. -I.. -I../include  -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Os -pipe -march=armv7-a -mcpu=cortex-a9 -mtune=cortex-a9 -msoft-float -mfloat-abi=soft -fno-caller-saves -fno-plt -DASMAES512 -ffunction-sections -fdata-sections -I/mnt/intel/DEV4/src/router/zlib -DNDEBUG -DOPENSSL_NO_ERR -DTERMIO  -fomit-frame-pointer -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
aes-256-cbc      36864.48k    41753.28k    43533.57k    43754.15k    43794.43k
root@1900acs:~# 

(Last edited by gsustek on 15 Jun 2016, 19:49)