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?
1 Like
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..
2 Likes
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
1 Like
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).
For this:
Linksys WRT AC series have a Cortex a9 CPU. The changes to a53 and a73 will only really be interesting if you're running an ESPRESSObin, MACCHIATObin, or Clearfog board. The changeset affecting us is:
+CONFIG_CC_HAS_ASM_GOTO=y
-CONFIG_USB_XHCI_PCI=y
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).
1 Like
This is what I want ^^
1 Like
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 
Does anyone have a bandwidth tracking package that works with luci? I used to have one but I cant seem to find it, I thought it was BMON but this doesnt show in the luci sidebar after install and restart
That looks like a fine SBC for use, just looking at the specs of it now. The fact that you can upgrade the ram is sweet.
I'm looking for one as well. Please let us know if you find one...
nlbwmon?
2 Likes
Hi Everyone,
I have a 1900ACSv2 router running on snapshot v9133 (kernel 4.14.95), as it's been a while since I installed this build (and have had no problems with it) I was wondering if there was any reason (security or otherwise) I need to upgrade the firmware to the latest version.
Thanks for any advice.
There have been updates since the end of January/February 2019. Dealing with Wifi drivers ??? No
Depending on your particular situation I could go either way.
yeah, I'm an "if it aint broke" person...so if there are no security vulnerabilities then I'm inclined to leave it as it is
do you post anything on your website when a new version comes out that fixes specific vulnerabilities?
Thanks, I'm testing this package at the moment!
Hello @davidc502
I am currently running Kernel 4.19.66 build r10851 on my linksys wrt32x. Last night I upgraded to the latest one from https://dc502wrt.org/releases/
As you know the wrt32x has a dual boot. At first I flashed the .bin file from within openwrt but then I realized that it only flashed it over the stock firmware on the other partition instead of upgrading the current one that I was running. Is this expected? or did I go about it the wrong way?
Any way, I ended up restoring the stock rom and flashed the latest *.img file from this link https://dc502wrt.org/releases/ instead of flashing the *.bin file.
When I did this, I restored my previous configurations successfully but non of my clients are able to connect to the internet. They just connect to the wifi but now internet. This is also true for wired connected devices through RJ45.
Any advice on the above two issues?
One last question: Does the latest firmware include the latest dnscrypt-proxy V2? or do I have to install it once I flash the update firmware?
Thanks
Correct, flashing in place is not supported, as it will always flash the other partition. If using the .bin to flash over stock firmware, it will not work as you must use the .img.
dnscrypt-proxy2 is available, but not 'baked' in. So, you must un-install luci-app-dnscrypt-proxy, and dnscrypt-proxy version 1, before installing version 2. I'm counting on having Version 2 built in either in this weekends build or the next build.
So, have you flashed again to get the router working or still stuck?
Thanks @davidc502.
I just re-flashed the latest build and it is still the same so i reverted back to build r10851 since it is working well for me.
Here my observations:
- Clients connect fine to the wifi but it is limited and without internet.
- when i try to open a website the address never gets resolved and the browser keeps displaying the message at the bottom toolbar "looking up www.website.com" until it fails
- It seems that somewhere in the settings there is a DNS that the router is using but it is not resolving anything
- I noticed that the STOP button for the WAN and WAN6 interfaces are greyed out even if I restart these two interface the STOP button is still deactivated.
- Under NETWORK -> DHCP and DNS, the DNS forward has a value of 127.0.0.1#5353 and another one for pool.ntp.org/8.8.8.8.
I tried deleting these two DNS forward addresses and it did not help.