There is no luci-app-dns installed on this system. Only luci-app-ddns. That's obviously not what I want, right?
The luci-app-dns-proxy can sometimes be left over in the menu.
Sometimes clearing the browser cache fixes it, logging out then back in, uninstalling the app if it has left overs or rebooting the router.
I have a wrt3200acm. When I flash the latest firmware (both with and without keeping settings) my router is not getting an IP address therefore no internet is available. Has anyone else seen this?
I did not have time to dig into it too much but if you have any suggestions or would like to know anything else let me know.
D-Link won't patch a remote exploit in four of its routers, saying they are end-of-life, despite some being discontinued in 2018 and still being sold on Amazon.
Ah, an all too familiar story. With Linksys the only difference is the unsupported products are still plastered all over their website.
I opened a new thread on the forum to inquire regarding this, please see here: Configuring a default setting for LuCI in a compiled firmware image
But it seems questionable if this is the best approach - as in, why is this happening in the first place on your builds but not stock OpenWrt? My theory - something due to the at-material theme?
Very True... Huge list of Linksys routers with vulnerabilities and Linksys has updates for most of them, but won't push them out. Customers have to download and install them which isn't the best thing to do. IMHO, consumer routers should demand setting the clock and a time frame in which to automatically install patches for issues like these.
Had another reply as well - FYI:
I compiled a test image, and installed. dnscrypt-proxy2 was baked into the build, and version 1 was removed. Looks like the configuration located in /etc/dnscrypt-prox2/dnscrypt-proxy.toml was saved and brought over to the test build. However, dnscrypt-proxy is not working correctly.
What I found was a different .toml file in /overlay, and I don't know why. My configuration file found in /etc/dnscrypt-proxy2 is correct, but the .toml file found in /overlay is the default un-altered.
Any idea how the 2 could be different? Anyhow, hope that makes sense.
Edit -- Just as a note.. UCI was broken in LuCi too.
I reverted back to the other partition, and then sysupgrade again. Now everything is working fine. So, I don't know what caused the other issue.
Will be making a new build my end for testing. Will see if I get the same issue as you did.
Do you build with neon support?
No I haven't been using anything different then your settings
Seemed to me when this first started happening multiple people tried different LuCi and was having the same issue. Also, at the time OpenWrt was having the same issue. Some also said it was HTTPS, but I had the same problem with HTTP.
It is odd to be sure. I should put up a FAQ for the issue, and point people to it.
Hi, could this be something that is of interest for David's builds?
It has been looked at several times over the years, but had little interest. Really, the 1900ac stood to gain the most since the processor runs a little hot, but I tested scaling on my 1900ac, and the average temp may have gone down 1 °c. If the upside was really big or even moderate then there would have been a large push to get the driver implemented. I think it would be nice if someone put it in, but eh..
Yea no thermal issues with my WRT32X although I don't load it up heavily, maybe higher higher workloads it would be worth it. Honestly it would good to have in the interest of efficiency.
In other news I wonder if mvebu will perform any different on 4.19 now with this commit: https://github.com/openwrt/openwrt/commit/ace1bfb5541387ee4f4eca5d0372da8897023449
There hasn't been any developments in the Linux kernel by Marvell CPU maintainers for the Armada 38x regarding power saving features. This issue from 2015 still hasn't been solved even in 2019 (5.4-rc2).
Changing the frequencies won't help the electrical current draw if the processor does not go to a lower power state to match it. Hence:
Reading around (can't be bothered to look it up again), there is a hardware design flaw leading to crashes/stalls once the CPU goes to a lower power state. Once it goes down to a lower power/idle state, it will never go out of it.
Besides, the thing already has a beefy heatsink for most consumer routers. And frequency scaling may also have a slight adverse effect on traffic shaping (quote from one of the sqm-scripts maintainers).
Linksys WRT AC series have a
Cortex a9 CPU. The changes to
a73 will only really be interesting if you're running an ESPRESSObin, MACCHIATObin, or Clearfog board. The changeset affecting us is:
ASM_GOTO was moved to the kernel config from a preprocessor macro throughout the Linux kernel code. This was an unnoticed regression when moving from 4.14 -> 4.19. As for,
USB_XHCI_PCI, it is a driver that was obsoleted by a newer one in 4.19 (formerly used solely by
mamba [WRT1900ACV1] devices I think).
This is what I want ^^
The Clearfog GT 8K does look great – but I still feel that x86 with AES-NI extensions will be more useful given the world is heading towards an encrypted future. I'm leaning towards the PC Engines apu4c2