Far be it for me to comment definitively, but IMHO, methinks luci-app-dnscrypt-proxy2 will contribute to far more confusion given it’s current state of development. Have you tried it?
I have not tried it.. Looking at it, and integrating it into make menuconfig, there is a problem, so it probably will not compile. It needs a dependency, and when it try to compile that dependency it fails, so it probably won't be available anyway.
I guess I have the version that has the power levels set and that are not changeable.
But that is not the issue, the issue is that for the same WRT3200ACM (same box/version) on your r13059 revision I can go to max 27 dBm but on the same WRT3200ACM (same box) with revision r13244 I can only get to max 26 dBm. The only thing that changed was your updated revision to r13244 with the kernel 5.4.41.
What has changed to cause this is the question. Any ideas?
For the hardware where you can't change the power settings, it is called a dummy switch. It kind of reminds me of Spinal Tap's guitar amplifiers... They would max at 11, and all the other amplifiers would only go to 10. Sure, you can turn it to 11, but does nothing more than 10. It's all just psychological.
Good that now with transition to linux 5.4 WiFi is usable again. Feb. firmware update broke it, many clients got problems connecting after that and the transfer speed was considerable lower. It was a known regression but firmware was not reversed. The build was running so great with previous WiFi firmware.
You might reconsider that LuCI app for dnscrypt2. It is not proper build up:
Only that dnscrypt2 is so easy to set up direct in config files. If it is included in the build, why not set it up on compiling, select Cloudflare servers which are the fastest, let's say? And add the only 4 lines needed in dhcp under dnsmasq:
option noresolv '1'
option localuse '1'
option boguspriv '1'
list server '127.0.0.53'
Docker CE option pls or k3s ?
Ok, so what I get from my non-expert understanding is that no matter what is showing in the GUI (or command line queries such as "iw phy0 info") on the WRT3200ACM models with power table in eeprom, the WRT only uses the eeprom power settings and ignores all software power settings.
So the following power settings from my WRT3200ACM can be ignored?
Extract from: iw phy0 info
VHT TX highest supported: 0 Mbps Frequencies: * 5180 MHz [36] (23.0 dBm) * 5200 MHz [40] (23.0 dBm) * 5220 MHz [44] (23.0 dBm) * 5240 MHz [48] (23.0 dBm) * 5260 MHz [52] (20.0 dBm) (radar detection) * 5280 MHz [56] (20.0 dBm) (radar detection) * 5300 MHz [60] (20.0 dBm) (radar detection) * 5320 MHz [64] (20.0 dBm) (radar detection) * 5500 MHz [100] (26.0 dBm) (radar detection) * 5520 MHz [104] (26.0 dBm) (radar detection) * 5540 MHz [108] (26.0 dBm) (radar detection) * 5560 MHz [112] (26.0 dBm) (radar detection) * 5580 MHz [116] (26.0 dBm) (radar detection) * 5600 MHz [120] (26.0 dBm) (radar detection) * 5620 MHz [124] (26.0 dBm) (radar detection) * 5640 MHz [128] (26.0 dBm) (radar detection) * 5660 MHz [132] (26.0 dBm) (radar detection) * 5680 MHz [136] (26.0 dBm) (radar detection) * 5700 MHz [140] (26.0 dBm) (radar detection) * 5720 MHz [144] (disabled) * 5745 MHz [149] (13.0 dBm) * 5765 MHz [153] (13.0 dBm) * 5785 MHz [157] (13.0 dBm) * 5805 MHz [161] (13.0 dBm)
1 Like
What you get on the rango (unfortunately), is the maximum TX power, for the channel in use, with the locale of device data. Which you can see as per your output example.
1 Like
Ok, will try the new build later today and let you know!
It would be great to have dnscrypt in LuCi.
cause it was in LuCi some years ago
1 Like
New builds have been uploaded to the server. These are based on kernel 5.4.X. I don't recall hearing about an big problems, so no better time than now to rip the band-aid off.
This does have luci-app-dnscrypt-proxy2 available for download -- However, it did not work when I installed it 
I do recall seeing some errors about collectd, but I have not investigated. So, be prepared just in case it doesn't work.
Kernel version = 5.4.41
WiFi driver = 10.3.8.0-20200416
Build = r13342
4 Likes
hi dear dave
were you tested this new kernel 5 in WRT 1200 AC Version 1?
can this gives high performance in Softether Package and other Packages without problems?
Thank you for help
Regards,
Tarek Herik
Thank you dear Dave
For this new kernel it makes high performance and stable
Everything's good without issue
Hi Dave,
Thank you for new release !
Just flash sysupgrade from r12121 keep conf.
The transmission unfortunately not working 8(
I deleted the procd_set_param seccomp "/etc/seccomp/transmission-daemon.json" line from init.d.but it still doesn't work 8 (
logread:
Mon May 25 01:37:03 2020 daemon.info procd: Instance transmission::instance1 s in a crash loop 6 crashes, 0 seconds since last crash
I tried to start:
transmission-daemon -e /mnt/hdd/torrent/log -g /mnt/hdd/torrent/config
but not found...
root@Linksys:~# transmission-daemon -e /mnt/hdd/torrent/log -g /mnt/hdd/torrent/
config
-ash: transmission-daemon: not found
br,
zacci
Hi,
I've just realized that my android phone had switched to 2.4Ghz wifi on r13244 and when I checked the WRT1900ACS wifi setings, the 5Ghz was down. I'm also getting this error in the system log "WARNING (wireless_add_process): executable path /usr/sbin/wpad does not match process path (/proc/exe)". Strangely, if I reenabled the 5GHz, it's now working but the 2.4Ghz become disabled and vice versa. Rolled back to r12833 and now everything is ok. Being using the same settings for a while without any issue. Might be related to the new kernel. Will try r13342 tomorrow.
Hi all,
Does anyone work with transmission with the new release ?
br,
zacci
I never had any issues with Transmission, it just works.
nitroshift
HI nitroshift,
Interesting...with the new release ?
br,
zacci