Running your latest build right now, currently no issues at all right now that i can see.
I am not using Rosy LuCi however i have been using luci-theme-material theme now for a while since 9133, but this is my taste and each persons taste is different.
Question regarding #2.. sorry this is just me confirming but is the change to the Wifi mean that this change:
Is present in the latest build? If so that's excellent. In addition does this mean that the next time OpenWrt does builds (18.06.3, or whatever the next iteration may be now) will contain the change as well?
Sorry - this is something that is probably obvious to you or most but as someone still learning I don't like to make assumptions on what may or may not be present 
I always compile the very latest driver/firmware from the master. I download it to my machine, change some code for the AMSDU lag issue for the 1200 series, change the "make" file for mwlwifi to point to the modified driver, and ensure it is compiled for that build.
As for 18.06.3, they usually pull in the latest wifi changes for mwlwifi. So, .2 for example should have the latest wifi driver/firmware for the time it was compiled.
A while back I followed Starcms's guide (which has since been removed from the openwrt wiki) to get rid of luci certificate warnings when trying to login via the web interface. Now after this update I'm getting an ssl version interference error when I try to login to the web interface, due to what I assume has to do with whatever has changed with openssl. Can someone give me a little bit of guidance on how to either fix, remove, or bypass openssl and the self signed cert that it created so that I can get back into Luci?
Import the certificate into the certificate store and you won't have to see the self signed certificate again. At least until the next build when it creates a new self signed certificate. Just google how to accept self signed certificates for the browser of your choice.
I've added uHTTPd into the build which gives users some flexibility on how to handle certificates or just turn HTTPS off and use HTTP. So, be sure to take a look at those options as well.
Also, I know what you are talking about with Starcms's guide, but since it has been a long time since I've seen those instructions, I've forgotten how he did it. However... You can use Wayback machine to see the OpenWrt webpage and how it looked 1 year ago, so you should be able to pull out the instructions that way too.
Think this might be the guide from starcms that you're looking for:
https://openwrt.org/docs/guide-user/luci/getting_rid_of_luci_https_certificate_warnings
What build are you running?
Looks like it could be another Rosy formatting issue.
Well it seems like the page is actually still up, so thanks @inph for linking it. This is what I had bookmarked so I'm not sure what I did or why the address was changed: https://openwrt.org/docs/user-guide/getting-rid-of-luci-https-certificate-warnings
The thing with the cert is that even though I followed Starcms's instructions exactly and your advice now, I was never actually able to get the firefox/chrome store to accept the cert that openssl generated. So what I did was just let my OS handle it by dropping it in my /etc/ca-certificates folder on my pc and that has worked fine for multiple updates, until now of course. So I'm a bit stuck of what I need to do with the certificate I have to get it to work again or what to do to revert what I did with Starcms's guide.
I will definitely look into the options you're suggesting when I get this sorted so thanks for mentioning uHTTPd.
It looks like rosysong was waiting for a followup from @pintopwnie - I replied with information I was able to dissect from the screenshot posted, but maybe following up to an answer on your browser and OS used may be helpful.
Could you tell me your version of Openwrt ? master or 18.06 ?
And your browser, mobile phone or PC ? Showing A snapshot would be great. Thanks! @pintopwnie
I'm sorry for the basic question, but why the new builds no longer come with dnscrypt-proxy V2 already compiled and configured to be used
We pushed a new commit to the master (merged), please update your source code, if it doesn't work,
please tell me the detailed steps to reproduce this problem, thanks!
You might be confused because Version 2 has never been a part of the base build. It has always been an option for those who want to install it. The script downloads a pre-compiled binary. -- https://dc502wrt.org/dnscrypt/
I would love to have version 2 instead of version 1, but I was told there was limitations with the way Openwrt builds its packages --- something to do with cross compiling. Let me know if you hear the issue has been resolved.
It's hears very strange for me. I use 3200acm for months, and David's firmware quite good - have no wifi problems so far. Maybe it's good idea to drop settings?
Yes, DFS is a menace - thanks to FCC.
+1. It's NOT pointless.
I check preliminary ax on Asus - it's quite impressive - about 2x speed into same conditions and diapasone! So i'm waiting for it at routers and adapters.
Just installed r9506 on my WRT32X and am seeing these "marvell-cesa f1090000.crypto" kernel errors in my logs now, too.
Six days ago this commit was merged that had changed around some things with devcrypto.
@cotequeiroz can you give any insight into what could be causing this:
Wed Feb 27 08:59:21 2019 kern.err kernel: [16077.021990] marvell-cesa f1090000.crypto: dma_pool_free cesa_cache, dma 0x1cff6040 already free
Could it be caused by an outdated OpenVPN version (2.4.6 was released pre-OpenSSL 1.1.1/TLS1.3)? I can see that 2.4.7 was release just on 21st Feb with better support for OpenSSL 1.1.1 (and probably 1.1.1b).
I'm investigating issues with digest support and forks/threads. I haven't confirmed this, but it seems like there's a problem with processes that copy a message digest context from one process (or thread) to another one. sshd is the one I'm currently looking into. It seems to be creating two instances of the /dev/crypto engine, and then copying an MD context from one instance to the other one, causing an ENOENT error, although I haven't seen those kernel error messages yet, but I haven't run openvpn. Try to apply https://patchwork.ozlabs.org/patch/1049156/ (the patch adds, among other goodies, the configuration options I'll use next) and then disable digests in /etc/openssl.cnf: Add this line before any section (lines with brackets []):
openssl_conf=openssl_def
Then, add the following sections anywhere past the last of the unsectioned commands (I add this to the very end of the file)--notice that you don't need the CIPHERS line to enable all ciphers, I've added it here for reference:
[openssl_def]
engines=engine_section
[engine_section]
devcrypto=devcrypto_section
[devcrypto_section]
CIPHERS=ALL
DIGESTS=NONE
Please tell me if the errors stop. Digests are not efficient anyways, at least not with the wrt3200acm (tested with openssl speed, only with a block size of 16384, they are a bit faster than software). Perhaps with VPN traffic on jumbo frames they may be worth a try, but for most TLS applications, it is very slow. You can use different configuration files, btw, setting the OPENSSL_CONF environment variable with the configuration filename.
I would disable the ECB ciphers as well, since they are used mostly in rng code, in small blocks (I don't recall if it is 16 or 64 bytes), where the cost of the ioctl (context switch) is high. I run mine with
CIPHERS=DES-CBC, DES-EDE3-CBC, AES-128-CBC, AES-192-CBC, AES-256-CBC
Note that, without the patch above, the engine is used for algorithms implemented in the kernel without hardware acceleration, which slows them down not matter what.
I will try to fix the copy issue, or else disable digests by default (probably best anyway).
That commit backs out patches that were added in the original 1.1.1a push, but had since been up-streamed; or, they were and are still there. I would suggest that a response from the author is more likely if you pose your question in PR1547 where the cryptodev enhancement was kicked around to debug things. But by way of a data point, I have not seen this message on either a mamba or rango with openvpn in play.