Feel free to try it, but the router is likely to reboot every so often.

the k4.4 r5113 has been rock solid on the wrt1900ac v1.  i have not experience any reboot with r5113 as described by a few users.

Yup.  I installed r6302 on my 1900acv1 and updated the mwlwifi module and firmware to the latest.  And it does still exhibit random reboots, so I flashed things back to r5113 with kernel 4.4 for the time being.  Bummer.

This might be a strange question - I'm still running a 1900acv1 - on r5113 - stable as a stable thing - what is the max WAN speed people have seen on these routers.. I've got a 1Gigabit connection - but seeing a whole 200mbps coming down the pipe...

A couple of years ago I owned the v1. At times, depending on the build, I could get 650mbps to 800mbps. There was always this issue with IRQ balancing. Most of the times 1 cpu would handle the entire load, and when that happened I could only get around maybe 400mbps.  The other and main issue of why it isn't able to get 1Gbps was due to the lack of hardware acceleration. Over the years there have been several people who have tried to patch and get it working, but nothing really stuck, and nothing ever reached trunk for distribution. At least that's what I remember.

200Mbps seems a little low even if IRQ balancing isn't working.  Run htop whist doing a speed test and see if 1 processor gets maxed out. Also, for a test, you might check the latest build. The latest build (r6302) will have reboot issues, but I'm curious if some of the processor changes to keep it from rebooting on r5113 is killing throughput.

You can get r6302 from this page --   https://davidc502sis.dynamic-dns.net/sn … u/generic/

Do a few speed tests with it and then revert back to r5113.

Are there any detailed reports (i.e. kernel back traces) available on 1900acv1 reboot issues?

The short answer is no.

Yip - A CPU core is pegging during the speed test - the second core hits around 50%-60% with r5113... will roll back to stock and test, and upgrade to r6302 and test..

Thanks

For whatever it's worth...  I have a 1900acv1 and mine is rock solid on this release..

r5621  - Kernel 4.9.70

Anything newer though, and it randomly reboots.

//Brew

(Last edited by Brewder on 1 Mar 2018, 22:54)

mwlwifi is failing to compile due to patch 001-remove-vfs_write.patch

Has anyone posted the fix for this patch or is there another reason?

Applying ./patches/001-remove-vfs_write.patch using plaintext: 
can't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- a/debugfs.c
|+++ b/debugfs.c
--------------------------
No file to patch.  Skipping patch.
3 out of 3 hunks ignored
Patch failed!  Please fix ./patches/001-remove-vfs_write.patch!
Makefile:90: recipe for target '/home/davidc502/Desktop/lede-build/lede1/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu/mwlwifi-10.3.4.0-20180226/.prepared_57209cb5d863f1b6c6cd11c2c468010f_6664517399ebbbc92a37c5bb081b5c53' failed
make[3]: *** [/home/davidc502/Desktop/lede-build/lede1/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/linux-mvebu/mwlwifi-10.3.4.0-20180226/.prepared_57209cb5d863f1b6c6cd11c2c468010f_6664517399ebbbc92a37c5bb081b5c53] Error 1
make[3]: Leaving directory '/home/davidc502/Desktop/lede-build/lede1/package/kernel/mwlwifi'
package/Makefile:106: recipe for target 'package/kernel/mwlwifi/compile' failed
make[2]: *** [package/kernel/mwlwifi/compile] Error 2

***EDIT***

Operator error...  I managed to zip a folder within a folder that isn't supposed to be there, so it fails.  It is fixed now.

(Last edited by davidc502 on 2 Mar 2018, 00:17)

Hi,

WRT1900ACS v2 back to reset alone, and in idle mode temp is 82,5 C, will back  for r5917 for tests ..

root@lede:~# sensors
tmp421-i2c-0-4c
Adapter: mv64xxx_i2c adapter
temp1:        +49.6°C 
temp2:        +51.6°C 

armada_thermal-virtual-0
Adapter: Virtual device
temp1:        +80.4°C

Hi,

tmp421-i2c-0-4c ==> WRT 1900ACS
Adapter: mv64xxx_i2c adapter
temp1:        +51.8°C 
temp2:        +53.5°C 

armada_thermal-virtual-0
Adapter: Virtual device
temp1:        +80.4°C 

=================
Adapter: mv64xxx_i2c adapter ===> WRT3200ACS
temp1:        +47.5°C 
temp2:        +49.9°C 

armada_thermal-virtual-0
Adapter: Virtual device
temp1:        +77.0°C 

really and very high work, even more than the 3200. but what is causing me concern are the re-boots, I will do a test with the last vs. without changing the binaries, the FW WIFI, to verify, since I may have done something wrong in replacing, maybe ......

I remember that I am not criticizing, I inform in the intention to help improve the work done.

grateful for the support.

Ps .: I am monitoring the two router at the moment by HTOP the WRT3200 remotely, the only difference I noticed and the use of more memory in the 3200, and working at a lower temperature 7C ....

If you are still having issues with the actual compiled output for kernel 4.14, it looks like there is an open pull request to get the OpenWrt master branch updated with the latest driver commit and also an updated version of the vfs_write to kernel_write patch (https://github.com/openwrt/openwrt/pull/765).

I'm currently using a 1900ACv1 running a build from DavidC.  It's stable and I love the LEDE firmware and Luci interface.

I have a fair number of wifi devices connecting to this device.  Does the MU-MIMO functionality of a WRT3200ACM work on David's builds of LEDE/OpenWRT?

Looking for a good reason to buy some new hardware! 

//Brew

MU-MIMO is not available yet. It is unknown when yuhhaurlin will start working on it.

You can read about how the thread has progressed below.

https://github.com/kaloz/mwlwifi/issues/241

*EDIT*

I recommend upgrading to the 3200acm even without MU-MIMO right now.

(Last edited by davidc502 on 2 Mar 2018, 16:18)

i'm wondering if you have observed any noticeable performance advantage with the k4.9 r5621 over the k4.4 r5113 other than the r5621 has a newer kernel?  thank you.

Did a pull this afternoon and it looks like the master branch has been updated with kernel 4.14 and the latest driver.

I did a test build with 4.14 yesterday, and the wifi configuration was all screwed up.

There looks like there's a ton of commits... Will download and try again tonight.

(Last edited by davidc502 on 2 Mar 2018, 23:20)

am running the latest 4.14 code now on my (older) AC V2, and it (up til now) runs stable, even with all features and trimmings i use on top. (uptime of 1+ hr currently)

root@WRT1900AC-v2:~# uname -a
Linux WRT1900AC-v2 4.14.23 #0 SMP Fri Mar 2 20:33:08 2018 armv7l GNU/Linux

only thing i'm still puzzling with is this one:

[    1.144816] usbcore: registered new interface driver usb-storage
[    1.241896] xhci-hcd f10f8000.usb3: xHCI Host Controller
[    1.247242] xhci-hcd f10f8000.usb3: new USB bus registered, assigned bus number 2
[    1.254835] xhci-hcd f10f8000.usb3: hcc params 0x0a000990 hci version 0x100 quirks 0x00010010
[    1.274278] xhci-hcd f10f8000.usb3: irq 44, io mem 0xf10f8000
[    1.288098] xhci-hcd f10f8000.usb3: xHCI Host Controller
[    1.293462] xhci-hcd f10f8000.usb3: new USB bus registered, assigned bus number 3
[    1.301022] usb usb3: We don't know the algorithms for LPM for this host, disabling LPM.
[    1.580524] usb 1-1: new high-speed USB device number 2 using orion-ehci
[    2.000557] usb 3-1: new SuperSpeed USB device number 2 using xhci-hcd
[    2.031456] usb 3-1: USB controller f10f8000.usb3 does not support streams, which are required by the UAS driver.
[    2.041778] usb 3-1: Please try an other USB controller if you wish to use UAS.

@David/others: do you have any idea how to fix this? seems the USB3-1 controller is simply not properly recognized and it drops back to generic code or something?

(Last edited by JohnnySL on 3 Mar 2018, 00:05)

I am trying to setup a wireless camera over 2.4ghz and I seem to have issue (explained in detail here: https://forum.lede-project.org/t/dhcp-f … 4ghz/12230 (dnsmasq doesn't discover the camera)

Using the snapshort r6302. Additionally, I found this in

/tmp/run/hostapd-phy1.conf 

interface=wlan1
ctrl_interface=/var/run/hostapd
ap_isolate=1
disassoc_low_ack=1
preamble=1
wmm_enabled=0
ignore_broadcast_ssid=0
uapsd_advertisement_enabled=1
wpa_passphrase=THEPASSWORD
auth_algs=1
wpa=1
wpa_pairwise=CCMP
ssid=SSID_2GHZ
bridge=br-lan
wpa_disable_eapol_key_retries=0
wpa_key_mgmt=WPA-PSK
bssid=60:38:xx:xx:xx:xx

ap_isolate seems to be set to 1 for some reason.

This is the latest log:

Sat Mar  3 00:32:31 2018 kern.debug kernel: [34940.428917] ieee80211 phy1: staid 4 deleted
Sat Mar  3 00:32:32 2018 daemon.info hostapd: wlan1: STA 88:83:5d:b1:f8:38 IEEE 802.11: associated (aid 4)
Sat Mar  3 00:32:32 2018 daemon.notice hostapd: wlan1: AP-STA-POSSIBLE-PSK-MISMATCH 88:83:5d:xx:xx:xx
Sat Mar  3 00:32:33 2018 daemon.notice hostapd: wlan1: AP-STA-POSSIBLE-PSK-MISMATCH 88:83:5d:xx:xx:xx
Sat Mar  3 00:32:34 2018 daemon.notice hostapd: wlan1: AP-STA-POSSIBLE-PSK-MISMATCH 88:83:5d:xx:xx:xx
Sat Mar  3 00:32:37 2018 kern.debug kernel: [34946.061801] ieee80211 phy1: staid 4 deleted
Sat Mar  3 00:32:38 2018 daemon.info hostapd: wlan1: STA 88:83:5d:b1:f8:38 IEEE 802.11: associated (aid 4)
Sat Mar  3 00:32:39 2018 daemon.notice hostapd: wlan1: AP-STA-POSSIBLE-PSK-MISMATCH 88:83:5d:xx:xx:xx
Sat Mar  3 00:32:40 2018 daemon.notice hostapd: wlan1: AP-STA-POSSIBLE-PSK-MISMATCH 88:83:5d:xx:xx:xx
Sat Mar  3 00:32:41 2018 daemon.notice hostapd: wlan1: AP-STA-POSSIBLE-PSK-MISMATCH 88:83:5d:xx:xx:xx

(Last edited by GaNi on 3 Mar 2018, 06:36)

You will notice significant performance degrade for wifi, in fact. But 4.9 release have security patch for WPA2. So i recommend continue using 4.4, if you need performance.

It does not make any sense to """upgrade""" from a 1900 to a 3200. I would even say, sell the 1900 on ebay and "downgrade" to a 1200. The 1900 and 3200 both dont make sense to buy or use.

I'm curious as to why it doesn't make any sense? What are your reasons?

1. The CPU on the 3200acm is much better/faster.
2. Twice the RAM.. However, for my use it make zero difference. Others may be different
3. The wifi drivers on the 3200acm are actively being worked on as well as the firmware.
4. Potential Wifi speeds are superior to the 1900ac. I found them to be much better/faster than the 1900acs as well as the 1900ac V1.
4. One can get 1Gbps out of the outside interface due to its CPU being much faster even without proper HA.

One can find the 3200acm pretty cheap these days... Here's on on ebay going for 139.00 USD with free shipping!  https://www.ebay.com/itm/Linksys-WRT320 … SwLgNaa3By
Here is a new one on Amazon for 211.00 USD  https://www.amazon.com/Linksys-Dual-Ban … ds=3200acm

My 2¢    However, I'm sure there's a 'con' list that others would make, so I'm curious to hear about them.

(Last edited by davidc502 on 3 Mar 2018, 17:33)

A new experimental build has been uploaded to the server and is ready to be downloaded. It is based on kernel 4.14.23. According to the latest commits, this is now the 'default' kernel for our model series. Rather than just jump into it, I thought it would be a good idea to do some testing and hear feedback from users before making it a regular build. The last experimental build had wifi issues especially for V2 owners, so I'm interested to hear if those problems continue of if they have now been fixed. I suspect they have indeed been fixed.

Patch 005 has been added to the build, so the very latest 3200acm hardware can enjoy this firmware as well.
I did not hack the wifi driver for the 1200acm this time. I'm interested to hear from 1200acm users if they still experience latency or high ping times when playing games etc. If the issue continues, I will continue to make changes to the driver to accommodate 1200ac owners. 

Kernel 4.14.23 with the latest wifi driver commit.
https://davidc502sis.dynamic-dns.net/sn … u/generic/

Sorry V1 owners, the reboot issue continues with this kernel.

(Last edited by davidc502 on 3 Mar 2018, 17:20)