All same problem
I use these builds for half a year now, though the Rosy theme is not displayed well, left sidebar is hiding the countdown before a change. And inside Network>Interfaces>LAN>Physical settings the "interface" drop down is not showing choices.
Thanks for the information... Well, it looked like Rosy was actively being supported, and was the main reason why I switched. However, the last 4, formatting issues have been sitting in the queue for a week sigh......
Feel free to report this. Read above posts for the Rosy Github.
Hi all, got a query with dnscrypt 2.
Ive installed this as per your instructons david. The install seems Ok when I check it. But when I try the test to resolve I get
Domain exists: yes, 4 name servers found
Canonical name: google.com.
IP addresses: 216.58.204.14
TXT records: docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95 v=spf1 include:_spf.google.com ~all
Resolver IP: 141.101.70.44
This looks fine, as that IP is one of Cloudfare's servers here. But I run a dnsleak test from the web it tells me that my DNS queries are going to my ISP. Rival dns test services give the same result. So is Dnsproxy working correctly? or is being somehow bypassed?
PS - ive switched the value for IPv6 to True in the dnscrypt-proxy.toml
file - still the same result
I have installed Davidc502 LEDE package for a new Linksys WRT3200ACM router. Firmware flash takes fine and the router works as it should for about 30min - and hour. Then I start seeing high latency and really slow speeds. Speed tests at Speakeasy.net show 2-4Mbps down and 0.8Mbps up. That is on a comcast highspeed cable service that normally sees 150+ Mbps down and 10+ Mbps up. Unplugging my computer from the router and directly into the cable modem I will see the normal highspeed results. Booting to the Linksys firmware recovery partition or reflashing with DDWRT I will also see the speeds revert and stabilize. Flashing back to the LEDE build the router works for a little while, then begins to slow down again. Thoughts??
A couple things you want to check are ---
-
Make sure "Use DNS servers advertised by peer" is unchecked. Look in Interfaces - WAN - Advanced settings..
-
Be sure your clients are receiving the proper dhcp DNS assignment. Check to see that your clients DNS settings are set to go to your GateWay, and not some other DNS server on the internet.
Hi David
thanks as always. I deleted the files and then reinstalled the whole thing form scratch. And unchcecking the box in the WAN section seems to have fixed the issue; all DNS leak test sites now show Cloudfare!
1 Like
I just uploaded new builds to the server and are ready for download.
Kernel version = 4.14.88
WiFi driver = 10.3.8.0-20181210
Build = r8810
Several kernel bumps since the last build.
There have been some wifi driver changes and firmware changes.
softethervpn was removed from the build as it was causing compiling issues.
lede-mvebu-cortexa9-linksys-wrt3200acm-squashfs-sysupgrade.bin
maybe broken?
Sha256 checksum 9990b576258f87a7f761a7bd80afca03881a32aae5a303262ebb86acfdfcf47f
Which not equal to sha256 in Downloads.
Redownloaded 5 times.
checking checksums.
getting a similar issue with WRT1200AC
Errors in log
Tue Dec 18 18:16:20 2018 authpriv.info dropbear[8733]: Early exit: Terminated by signal
Tue Dec 18 18:16:25 2018 authpriv.warn dropbear[8849]: Failed loading /etc/dropbear/dropbear_ecdsa_host_key
Tue Dec 18 18:16:25 2018 authpriv.info dropbear[8849]: Not backgrounding
The checksums.... check out fine. EDIT I did check each image and they all match the checksums.
From the server ---
sha256sum ./lede-mvebu-cortexa9-linksys-wrt3200acm-squashfs-sysupgrade.bin
f40c031b3dd6019d7adbb0892b2fd0f6af9990b6fdcc32965bb68b19b4268024 ./lede-mvebu-cortexa9-linksys-wrt3200acm-squashfs-sysupgrade.bin
Downloaded to my linux machine
davidc502@pc2:~/Downloads$ sha256sum ./lede-mvebu-cortexa9-linksys-wrt3200acm-squashfs-sysupgrade.bin
f40c031b3dd6019d7adbb0892b2fd0f6af9990b6fdcc32965bb68b19b4268024 ./lede-mvebu-cortexa9-linksys-wrt3200acm-squashfs-sysupgrade.bin
Not in my logs today, but I did have the same errors yesterday. Have you tried build r8810 yet?
root@lede:~# logread | grep dropbear
Mon Dec 17 22:17:12 2018 daemon.notice procd: /etc/rc.d/S50dropbear: interface wan has no physdev or physdev has no suitable ip
Mon Dec 17 22:17:12 2018 authpriv.warn dropbear[2971]: Failed loading /etc/dropbear/dropbear_ecdsa_host_key
Mon Dec 17 22:17:12 2018 authpriv.warn dropbear[2971]: Failed listening on '22': Error listening: Address not available
Mon Dec 17 22:17:12 2018 authpriv.info dropbear[2971]: Not backgrounding
Mon Dec 17 22:17:18 2018 authpriv.warn dropbear[5729]: Failed loading /etc/dropbear/dropbear_ecdsa_host_keyThe errors i listed are from your 8810 release. WRT1200ACv1 failed.
I am going to try it on my WRT1900ACSv2 & WRT1200ACv2
Thank you. Problem was with update through Luci - wrong checksum.
Download and upgrade through ssh - no problem. Sorry for disturbing.
1 Like
Same "issue" here on my 3200ACM. Downloading it from your site gives me the same checksum in my OS but luci shows the sha256 as
9990b576258f87a7f761a7bd80afca03881a32aae5a303262ebb86acfdfcf47f
This is the first time the checksums haven't matched for me on luci and I believe it's the first time I'm updating since the new theme went in if that helps track down what's causing it.
followed the wiki instructions on updating over ssh though and it worked fine.
Build r8810 works well on my Linksys WRT1900ACS V2 for the few hours that I've been running it. I augment the build with DNS-over-TLS (getdns and stubby), vpn-policy-routing, and wireguard and it all is operating smoothly. I'm glad the rosy theme is now displaying memory use correctly on the status overview page.
1 Like
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.
1 Like
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.