Davidc502- wrt1200ac wrt1900acx wrt3200acm wrt32x builds


I also had the issue flashing from the november WRT3200acm build to this December 18th build. The final sha256 check in the web interface did not match the download check and the flash aborts. I succeeded by rebooting into the previous build on the alternate partition and in this older version upon flashing the sha256 check matched the download file check. The flashing process went through flawlessly.

I think there is something amiss in the build from November with regards to the flashing process.

I did initiate a flash to the stock open WRT 18.06.1 build and upon viewing the sha256 check in the WebUI, it appears this problem does not exist in the December 18th build so we should be good for next time.



There are 4 other issues that have been sitting in the queue for a few weeks now. My hopes of using a theme based on Material are diminishing.


@davidc502 Will you be issueing a new image with the checksum issue fixed, or should we update manually? Luci would not allow anyone to update ...


If you are on an image with the upgrade issue in luci linked above, you may have to scp an image over to your device and use sysupgrade from the CLI. As in you cannot just go the the other partition in-order to successfully flash.


Yes , that's clear... just wanted to skip the hassle...


What is the way to sysupgrade through CLI;

scp image.bin root@192.168.x.1:/tmp
ssh 192.168.x.1
cd /tmp
sysupgrade image.bin


For now update manually. The fix should be in before the next build which is usually around 2 weeks.


No need to do anything complicated:
Just edit manually the one script file in your router and remove the erroneous "-t" option from /lib/upgrade/fwtool.sh

Line 31:

-       if ! fwtool -q -t -i /tmp/sysupgrade.meta "$1"; then
+       if ! fwtool -q -i /tmp/sysupgrade.meta "$1"; then

After that change, you can sysupgrade quite normally via LuCI.


I'm seeing issues with dropbear in 8810 also. After upgrading I couldn't log into ssh. dropbear seems to crash right after successful auth. I reinstalled the previous build.


dibot just pushed version 3.6.0 of adblock (Adblock support thread). It's got a nice new reporting feature and I'm looking forward to that being included in the next build.


5ghz just stopped working, 2.4 is fine, reboot router and 5ghz back working. What may be wrong? Latest 18/12 build. TIA


Go ahead and grab some log files the next time it happens and post them.

Are you using DFS channels?


Which router?

I have a problem with 5Ghz on Shelby (v2) in last couple releases, (in rel from 30/11 it was most severe, I'm on stable 18.06.1 now, so didn't try 18/12 rel yet).
I have 5Ghz set to channel 120, after few hours of running it would change itself to 36, is impossible to change and no device can connect. When this starts it's still possible to connect to 2Ghz without problem, but it gets very slow with high pings and huge jitter.
Rebooting fixes issues maybe 1 in 5 tries. And by fixes I mean it's possible to change 5Ghz channel and then it works for few hours.
I've tried clean flash, still broken, so I went back to stock and now 18.06.1 - on both radio works without problem.

I forgot to save logs but didn't see anything extraordinary in them. When I have few spare hours I'll try 18/12 build and I'll keep logs then.


I'll do that. Not sure about DFS Channels, 5ghz is on 149 and 2.4ghz on 4.

by the way, thanks for the great work. Merry Christmas and a Happy New Year.


Cobra WRT1900AC v2


I'd been having really weird Wi-Fi Calling issues and performance issues with port forwards on the davidc builds since ~early November. I downgraded to the stable OpenWRT 18.06.1 build and both issues completely resolved.

WRT1900ACS v1 (Shelby)

Verizon Wi-Fi calling on iPhone 6s & iPhone XR - calls could be made or received, but the other side would stop hearing me after 30 - 60 seconds (I could still hear them).

Port forward from Internet IP to DMZ host for SSH access from outside. Connection would work fine for several minutes, then basically "freeze" and/or be highly-latent for a minute or two, then go back to normal, wash, rinse, repeat. Overall latency and throughput substantially reduced from what I saw before mid-Nov and what I see now with 18.06.1.


I'm currently running r6565. I'd like to install minidlna, but it isn't available.

Would it be possible to install the minidlna from r8810 without upgrading, or would this be a bad idea?

I'm reluctant to upgrade as everything just works right now :slight_smile: I'm also a bit concerned about several posts here about WiFi problems with the more recent releases. However if I did upgrade, could I tick "Keep Settings" in LuCi or do I need to upgrade without and then reapply all my settings?

On a similar note if I wanted to upgarde from r6565 to stock OpenWRT 18.06.1 could I "Keep Settings" then?



Unfortunately not as the kernel versions are different.

I wouldn't worry too much about it. You can always go back to r6565.

Yes, keep settings in LuCi, so use the sysupgrade image.

No you can't.