Only luci UI is in place, but main packages doesn't - transmission-daemon-*, transmission-web, transmission-cli-*, transmission-remote-*

Now I'm running your build, and I'll get back to you as soon as I know more.

Best regards - meffe

Ok, it's not working either. Reboots is happening when connecting to the radio's, at random it seems.

Now I'm trying an old stable (17.01.2), with an slightly updated mwlwifi (https://github.com/eduperez/mwlwifi_LED … ag/4f60068) -- I did use 17.01.2 with this wrt1900ac v1 (mamba) at one time, and it worked flawless. I can't remember what mwlwifi driver I was using, but I'm pretty sure I didn't use the one that is included in the 17.01.2 stable release. I never had any issue with reboots with it, and the speeds were great (according to me) -- I'm not 100% sure how much the max throughput were with 2.4/5ghz - but I do know that I had my 100/100mbit stable over 5ghz at least.

With all this said, what I'm trying to say is -- I know, for a fact, that it's possible to have a working wrt1900ac v1 (mamba) without any issues with "random" reboots.. I just need to find a working combo, again.

The so called "rock solid" david build, 5113(?) also gave me reboots..

(Last edited by meffovic on 26 Dec 2017, 10:08)

It could be a different issue? The random reboot issue with the 4.9 kernel seemed to happen reguardless if the radios were on or off. Does this occur on the 4.4 kernel? that should be rock solid

I've installed latest firmware 1 hour ago into my 1900ACS (Shelby). I can confirm that "transmission-*" packages are missing. Only luci-transmission is present.
EDIT: Fw rev: Lede SNAPSHOT r5501-30e18c8d64 / LuCI Master (git-17.343.27587-8e6b1a6)

(Last edited by ambrosa on 26 Dec 2017, 12:47)

My numbers could be off here, but appears the the 1900ac Version 1 patch works about 50% of the time.  For the Version1 folks that are still having reboot issues, please give DD-WRT a try.  Also, for those who still own the Version 1, I recommend buying the ACS or ACM as there can be really good deals on Ebay, if one stays patient and snipes at the end of a sale   Kernel 4.14 will likely be coming out before too long, but if it isn't stable on the V1, who knows how long it will take before there is a fix in.... if ever. My experience with the ACM has been really good since the wifi drivers have been honed a bit, and I do know Linksys is continuing to add wifi features that will probably only be available on the 3200acm I.E. MU-MIMO for example. One disadvantage, some might have a issue with, is that in the USA one can not mess with the wifi power output.

For Transmission packages ---   If the packages are not in the repository then they are failing to build. I'm currently working on a new build, and I'll take a look to see what might be happening with them. It's likely they will fail to compile today, but I'll reach out to the package maintainer and maybe he/she will give some insight as to why they are failing. My opinion doesn't count because I believe we should all use our routers the way we see fit, but I don't recommend using your router as a BitTorrent client    If you want, as soon as a build is available one can grab those needed transmission packages from daily lede snapshot builds.

My Patched V1 is working great!  Uptime currently 4+ days....  I have 18+ active wireless devices constantly and another 10 hard wired. 

-----------------------------------------------------
Lede SNAPSHOT, r5572-4a4d957d1a
-----------------------------------------------------
root@wrt1900ac:~# uptime
14:07:02 up 4 days,  5:09,  load average: 0.00, 0.01, 0.00
root@wrt1900ac:~#

@davidc502

I suspect that you hear from a much higher percentage of those with problems than those who are working fine.  Obviously I have no proof if this but it is what I believe.

The transmission packages build fine here, so not sure why they wouldn't there.

The current build is still compiling, but this was picked out of the line-up...  Here is an example.

make[3] -C feeds/packages/net/transmission compile
    ERROR: package/feeds/packages/transmission failed to build (build variant: mbedtls).
 make[3] -C feeds/packages/net/transmission compile
    ERROR: package/feeds/packages/transmission failed to build (build variant: openssl).
 make[3] -C feeds/packages/net/transmission compile
    ERROR: package/feeds/packages/transmission failed to build (build variant: mbedtls).
 make[3] -C feeds/packages/net/transmission compile
    ERROR: package/feeds/packages/transmission failed to build (build variant: openssl).
 make[3] -C feeds/packages/net/transmission compile
     ERROR: package/feeds/packages/transmission failed to build (build variant: mbedtls).
 make[3] -C feeds/packages/net/transmission compile
    ERROR: package/feeds/packages/transmission failed to build (build variant: openssl).

@davidc502

thats weird, they build fine here, I'd offer them up but I'm on 4.9.70/LEDE SNAPSHOT r5616+7-67c1c14 / LuCI Master (git-17.316.07773-4891dea).  They are building fine also on my netgear build and have been.  You might be missing some packages on your host they need to compile.

If i can help in any way i'm more than happy to.

(Last edited by WWTK on 26 Dec 2017, 20:34)

You are probably right about the missing packages...  Thanks.

I've only had issues when the radio was turned on, and "only" when clients were connecting, not all the time - I can't find what the real trigger is..

And yes, I've had issues with the 4.4 kernel as well (like with the 17.01.4 stable) -- but as i said, I only had reboots when clients connect to the wifi's, mostly when they d/c from one and connect to another.

I have another reboot this morning.

Seems like it's a kind of soft-reboot, because i have system log intact, and i see this in it:

Mon Dec 25 16:07:15 2017 daemon.info hostapd: wlan0: STA 70:4d:7b:7f:d2:00 WPA: pairwise key handshake completed (RSN)
Wed Dec 27 10:19:06 2017 cron.err crond[1625]: time disparity of 2530 minutes detected

See the time difference between entries!
Is the RTC patch applied before can be the source of this issue?

PS: Unfortunately, upgrade it's not an option for me here - 3200 just not available in any case. And yes, i use high-grade routers as a Torrent client/NAS for the last five years without any issue. It's nice to have stationary 24/7 torrent client.

That is an excellent clue on the reboot trail.

Could you check the ntp setup? Also, the ntpd can have trouble setting the clock when booting if using dnscrypt because the time is off too much for the dnscrypt to generate valid certificates neeeded to lookup the pool.ntp.org servers. Having an IP address for a time server in the servers list avoids the need for initial dns lookups or tweak the dnscrypt setup to allow using unsecure dns for the time servers.

Also, I just checked with my simple setup and the chrond is not running. My /etc/crontabs is empty so the crond doesn't start. Maybe the jobs in the crontabs for your install are unneeded or the /etc/init.d/cron could be prevented from starting crond as a quick fix. I can see how clock problems can give cron a breakdown.

Build r5621 has been uploaded to the server.

I've patched the 1900ac Version 1 that helps to resist the random reboot issue. However, keep in mind, that V1 owners use this build at their own risk. I don't own a V1 and can not verify any part of this patch including if it has any adverse affects or not, so please keep this in mind. Other V1 owners have expressed a slight temperature increase, so I recommend if you're gong to use it, keeping an eye on CPU temperature.

This build does include a few kernel bumps and various fixes.

*EDIT*

For V1 owners please verify the package repository is working correctly.

(Last edited by davidc502 on 27 Dec 2017, 20:48)

I don't use DNSCrypt, it's disable at startup. Only DNSmasq in play.

NTP settings near default, except i use some additional local NTP servers, NTP server disabled. Seems like it try to sync time every 1880 sec.

I have cron jobs active, some for dynamic DNS update, some for heartbeat check, etc - have no issues about them.

Good news - reboots happens after some hours/days of uptime, so it's barely acceptable - at least for experiment - for me.

Ok, i'll check new David's release this weekend, let's see how it acts like.

Hi! The build seems to work perfectly on my 1900ac V1 with 12 hours uptime for now (before it would have rebooted after 20 minutes on 4.9). I even noticed faster wifi speed and stability.

Here's the temperature (in a server room at 18°C):

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

tmp421-i2c-0-4c
Adapter: mv64xxx_i2c adapter
temp1:        +35.9°C
temp2:        +38.4°C

I have another problem now. I can't get the adblock package. I'm getting a "signature check failed" message on all downloaded packages:

(I put hxxps on the following capture to be able to post here)
...
Updated list of available packages in /var/opkg-lists/lede_telephony
Downloading hxxps://davidc502sis.dynamic-dns.net/snapshots/r5621/packages/arm_cortex-a9_vfpv3/telephony/Packages.sig
Signature check failed.
Remove wrong Signature file.

Thank you for your hard work I really appreciate all the efforts you put in providing these builds.

There must be a reason your system clock got so out of sync and made crond cause a reboot. The ntpd couldn't have been working properly if the time was off by more than a day. If worried, I would keep checking the system clock to look for the cause or nevermind.

That's what I was wondering about, and thanks for posting the issue.  It should be safe to just force the install. The V1 is from a separate build, but from the exact same packages and version number.

Thanks! I removed validation in OPKG-Configuration and now I can get the packages I want!

This may be the route I go for a while, so I'll take a look and see if I can remove the entry prior to building the image.

This is the line that needs to be removed ---   option check_signature 1

(Last edited by davidc502 on 28 Dec 2017, 20:10)

Hey All. Someone posted a couple pages back about there being a "wide-scale" issue (Linksys says about 0.5% of install base) with the WRT-3200ACM and WRT-32X; just wanted to make this forum aware of the issue. Most people complain about their wireless just "not working", requiring a reboot to correct, and even then not for long.

Personally, I experienced the issue running Davidc502's build of LEDE, stable LEDE, and stock. Currently, the finger is being pointed at Google's Chromecast/Android KRACK patch as the primary suspect. I have also seen articles about Netgears having issues and can confirm that with my parents' router.

More specific symptoms for me were:
1) 5GHz network randomly disappearing, sometimes coming back, usually not
2) 2.4GHz network dropping all clients and refusing reconnects
3) Chromecast devices do not show in the list of available Cast destinations and cannot be managed via the Google Home app (My one Chromecast on Ethernet usually works, but not always)

Disabling the 5GHz has made my 2.4GHz stable again but has done nothing for Chromecast availability. If you care to follow along or contribute what you can, the official thread is here:
http://community.linksys.com/t5/Wireles … p/1246764/
and is being moderated by a dedicated community team member: Linksys_Lucas
His most recent update (http://community.linksys.com/t5/Wireles … 25#M344886) said they might be close to a workaround, but permanent fix will rely on cooperation from

Wow, how could I miss this!

I will try this build right away - and I want to thank you for all your hard work David!

~ Bless ~

EDIT: I can confirm that the reboot issue isn't solved with this build - yet.
I'm pretty sure I triggered a reboot when accessing the luci from my android unit - this with only 5ghz (2.4ghz disabled) band enabled..

(Last edited by meffovic on 29 Dec 2017, 22:38)

This seems to be a different issue or a memory corruption problem, which no one cares on here to follow. Because I had the same issue with Luci so far. Two times, when I opened Luci, the same second, the router rebooted. I am certain, that there is something wrong with the memory on these routers (this rom). Maybe the memory is wrongly clocked and overclocked with kernel 4.9, leading to rare memory corruptions. For example, my router hasnt rebooted anymore, since I deactivated a script of mine. It is a self written watchdog for OpenVPN, and it uses "sleep 20" in it. I had two times now this in the logs:

[318506.951336] BUG: Bad page map in process sleep  pte:00060000 pmd:1bd74831

Since I deactivated the watchdog script, the router has not rebooted anymore. The sleep is triggered every 20 seconds in the script, which might cause a memory corruption way sooner than not using the script.

(Last edited by makedir on 30 Dec 2017, 01:55)

Hi, newbie thinking of trying a wrt1900acv2 build.  Did not see a search for specific build issues for the ACV2 but it seems the ACV1 is or has been a problem child. Since this thread is fairly huge, i figured just ask 1st, as i have a good idea on how to install and remove if needed.

I also have another question... is it me or just an oddity with ACSV1 build being about the same size as the ACV2, so is there minor partion differences between them since hardware is the same? I noticed a bunch of factory refurbished ACV2  being unloaded below $90 and the ACSV2 routers below $110.