Thanks for the info.  I will give it a shot tonight.

The Debian (Currently Jessie) root file system is entirely on a USB Drive Ext4 partition R/W and OS operates normally using that.

There is no wear at all as far as the router's nand flash is concerned. McDebian only "reads" nand flash once at powerup.

If you use an external USB hard drive the storage space is the same as any Debian server and wear leveling is also not a concern in this scenario. If you use a USB Key; well that is what I do and it's easy to backup so wear leveling is also not a concern. A USB Key for the root files system is standard these days just like the VMware ESXi Server best practice.

(Last edited by Chadster766 on 1 Jan 2016, 00:38)

Ok, so you don't actually run on the AP, you require an external hard drive to run. That eliminates you from consideration for me unfortunately. I'm not going to even try to deal with a hundred external storage devices and preventing them from walking away in public settings.

Yes

One of the things i'm still seeing is that after a couple of days the interface to the router on the 5ghz wifi interface gets laggy, with a lot of packet loss. I just have no idea what causes it (wireless driver i guess), but i've found a simple method to test for it.

could you guys test this for me as well, to see if it is a widespread issue or not.
To test:
1. have an uptime of the router of at least 2-3 days.
2. from a wireless client on the 5ghz interface, ping the router with a larger block (16k) size a 100 times and check for the average values afterwards:
3. switch the client to the 2.4ghz SSID and repeat.

e.g on a windows machine: ping 192.168.1.1 -l 16384 -n 100
normal ping times for a large ping like this should be ~6-7msec. But often i see packet loss or >100 msec response times.
e.g:

5ghz:
Ping statistics for 192.168.1.1:
    Packets: Sent = 100, Received = 57, Lost = 43 (43% loss),
Approximate round trip times in milli-seconds:
    Minimum = 6ms, Maximum = 121ms, Average = 11ms

2.4ghz:
Ping statistics for 192.168.1.1:
    Packets: Sent = 100, Received = 100, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 5ms, Maximum = 112ms, Average = 11ms

a reboot will resolve the issue for a day or two and then it is back again.
NB. small sized packets (i.ow. a normal ping) would not show any packetloss.

any ideas on how to troubleshoot this would be greatly appreciated.

(Last edited by JohnnySL on 1 Jan 2016, 14:12)

I too have this problem, will report back there as well! This is with a WRT1200AC on the latest driver.

Firmware Version OpenWrt Designated Driver r48006 / LuCI Master (git-15.354.35228-edf352e) 
Kernel Version 4.1.13
Local Time Fri Jan 1 11:58:20 2016
Uptime 4d 14h 26m 6s
Load Average 0.00, 0.01, 0.05

Win 7 HP laptop with Intel Centrino Advanced-N 6200 AGN

1. 2.4 GHz ave 23 ms - no packet loss
2. 5.0 GHz ave 4 ms - no packet loss

The weird thing is that the 2.4 GHz latency is not constant...  sometimes I do see 1 or 2 ms

Another one that makes me go hmmm:

Over a 2.4 GHz bridge I have no latency i.e. < 2 ms, while over a 5 GHz bridge I see > 25 ms

Cheers

MacBook Pro with OS X El Capitan
Router wrt1900acV1 - DD - Kernel 4.1.13 - mwlwifi 10.3.0.1

root@router:~# uptime
 12:39:47 up 2 days, 19:07,  load average: 0.08, 0.03, 0.05

5ghz:
--- 192.168.1.1 ping statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 7.012/8.030/10.424/0.639 ms

2.4ghz:
--- 192.168.1.1 ping statistics ---
100 packets transmitted, 100 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 9.852/15.006/78.323/8.210 ms

(Last edited by kirkgbr on 1 Jan 2016, 19:40)

<scratches his head> Why am i always chasing issues that nobody else has.
@doITright: is your router a V1 as wel? maybe this is a V2 specific issue?
@both, you did checked it with a large ping size i hope.

Hey Guys ,
Im on OpenWRT (OpenWrt Chaos Calmer 15.05) -
Recently noticed on Wifi there is Legacy or N mode , is there a way to run B/G/N Mode ? Instead of just Legacy (B/G Probably) or Just N ? I Have a few Old devices which can't connect to an N Network , Any solution ?
Thanks

yes

ping -s 16384 -c 100 192.168.1.1

both my units are v1:

1. @ 4.1.13 r48006 with nand patch
2. @ 4.4rc5 r48025 no nand patch -> pre-order so probably 1st batch -> problems with nand

large ping size was used

Reading the dd-wrt forum last night, points at the driver for sure wrt latency.... 
I think if we can trace this one down and get it fixed we will have a very stable unit....

My nand issues on the older unit are so bad and random that I am thinking of trying Chadsters McDebian

Cheers

Anyone with WRT1200AC got problems with the latest builds that have a 4.1 kernel or up with the USB 1 port? It doesn't work at all with two WRT1200AC units (I have one and a friend of mine as well, same problems). Are any WRT1900AC users experiencing these issues?

(Last edited by johan81 on 2 Jan 2016, 17:17)

@Johan: i'm using a USB key to share files, and it works fine?

Another thing i'm puzzeling with: proper hwclock support
if I do a hwclock -r, it shows :
root@WRT1900AC-v2:/dev# hwclock -r
Thu Jan  1 00:59:59 1970  0.000000 seconds

if i then set the hwclock from system time:

root@WRT1900AC-v2:/dev# hwclock -w

and reread the clock:
root@WRT1900AC-v2:/dev# hwclock -r
Thu Jan  1 00:59:59 1970  0.000000 seconds

so my rtc is not supported? i've added the kernel module for the Marvell RTC, but to no avail
anyone here who has a working setup,  or that could give me some tips?

(Last edited by JohnnySL on 2 Jan 2016, 18:03)

AFAIK these WRT models don't have a RTC and depend on NTP.

(Last edited by Chadster766 on 2 Jan 2016, 17:59)

@Chadster766:

weird, as there is a kernel module loaded for it at the 12 second mark:

root@WRT1900AC-v2:/dev# dmesg | grep rtc
[    1.367853] hctosys: unable to open rtc device (rtc0)
[   12.171971] armada38x-rtc f10a3800.rtc: rtc core: registered f10a3800.rtc as rtc0

Was thinking that it might need I2C support or something

(Last edited by JohnnySL on 2 Jan 2016, 18:11)

Notice:

The WRT1900AC V1 firmware file FW_WRT1900AC_1.1.8.164461_prod.img will no longer be available from my website.

In the OpenWRT WRT1900AC page below the listed link should be changed to another site:
http://wiki.openwrt.org/toh/linksys/wrt1900ac

"Older Firmware Linksys OEM 1.1.8 Image"

Can you say if it was Linksys that didn't want it there? Or some other reason?

Download abuses; I see massive downloading to the same IP Addresses at the same time. It's almost as though it's a DOS attempt. I noticed this a while back and kept this firmware file available as long as I could.

(Last edited by Chadster766 on 2 Jan 2016, 18:30)

My USB workshops on the USB 3 port, but not on the esata/USB port whioe this used tot work on the 3.18 kernel builds

I've gone ahead and changed the link. We'll see how long it stays up.

Thanks, when I was checking the link just now I noticed there is another one lower down the page as well.

@davidc502: would you be able to explain how to build for kernel version 4.4.x? 4.1.3 + the nand-patch doens't fix my boot issue, so once in a while my router needs an extra reset to boot again. Maybe 4.4 + patch will improve this issue?

I'll refer you to this quote from @doITright (below). I'm not sure if the RC Kernels are having issues booting without the nand patch or if it's better with one. Install and run at your own risk.

For your other question, building other kernels, no I don't have any experience, and haven't tried to do it yet. However, my 4.1.13 is rock solid, so let me know and I'll post a link to the image (includes luci).  I recently built a image for Wizkid specifically for the ACS, and it's been reported to be rock solid as well.

I went out of lazy mode, had a look around and figured it out in the meanwhile building 4.4 as i'm typing this.
I have a serial cable and jtag is underway (to fix an e4200 with a corrupt CFE), so if i break it, it should be able to fix it again
4.1.3 was stable for the first few builds for me, but eventually it failed to boot. I guess it is depending on HW quality and some timings.

(Last edited by JohnnySL on 2 Jan 2016, 23:33)