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.

nitroshift wrote:
kirkgbr wrote:

Has anyone who is running kernel 4.4rcx figured out how to get the wan LED to work?  All my builds seem to never have this one LED working.

That's because in kernels < 4.0 the driver was not present in kernel tree, OpenWRT relied on a patch that introduced the TLC59116 driver. Kernels > 4.0 have the driver integrated, but for the whole tlc591xx family. You need to edit leds.mk and change tlc59116 to tlc591xx.

nitroshift


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

dlang wrote:

so do you not use a read-only filesystem for the base OS the way OpenWRT does?

how do you handle wear-leveling of the flash? Unlike OpenWRT, the packages in Debian have not been selected/tweaked to avoid writing and re-writing files.

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, 01:38)

Chadster766 wrote:
dlang wrote:

so do you not use a read-only filesystem for the base OS the way OpenWRT does?

how do you handle wear-leveling of the flash? Unlike OpenWRT, the packages in Debian have not been selected/tweaked to avoid writing and re-writing files.

The Debian (Currently Jessie) root file system is entirely on a USB Drive 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 best practice.

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.

dlang wrote:

Ok, so you don't actually run on the AP, you require an external hard drive to run.

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, 15:12)

trustno1foxm wrote:

@muronghan would you be so kind and take apart: https://github.com/kaloz/mwlwifi/issues/54

I don't want to be the only one with the weird problem wink

thx!

so long

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

JohnnySL wrote:

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.


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

JohnnySL wrote:

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.


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, 20: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

JohnnySL wrote:

<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.

yes

ping -s 16384 -c 100 192.168.1.1

JohnnySL wrote:

<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.

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 smile

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, 18: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 sad
anyone here who has a working setup,  or that could give me some tips?

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

JohnnySL wrote:

@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 sad
anyone here has a working setup, that could give me some tips?

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

(Last edited by Chadster766 on 2 Jan 2016, 18: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, 19: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?

davidc502 wrote:

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, 19:30)

JohnnySL wrote:

@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 sad
anyone here who has a working setup,  or that could give me some tips?

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

Chadster766 wrote:
davidc502 wrote:

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.

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

davidc502 wrote:
Chadster766 wrote:
davidc502 wrote:

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.

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?

JohnnySL wrote:

@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.

doITright wrote:
davidc502 wrote:

It's kind of interesting about the boot thing... I've never had issues booting... however with the latest build, I noticed several times where it wouldn't boot(just sits at blinking light), and one time it booted from secondary flash, and had to flash again.

Did this problem start with 4.4rc5?

I noticed the problem about 2 weeks ago while still on 4.1.13, so I would guess it was introduced in the last 3 weeks or so.

With the nand patch 4.1.13 is rock stable but 4.4rc5 seems to be better off without the patch.

Stock and everything older like CC and McWRT are good.  My go to build is one of the last 3.18.23 with the .13 driver smile

If I remember correctly if it fails to boot 3 or 5 times in a row, it switches to the other region.

The only way to tell what is going on is to watch it via TTL.

Cheers

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 smile 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 smile
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 3 Jan 2016, 00:33)

Sorry, posts 9351 to 9350 are missing from our archive.