@cybernook - Managed to fix my VPN issue eventually - although slightly confused as to what the problem was - it went away when I linked from the config file to an .ovpn file rather than have the same settings listed in the config. Maybe the order of the settings mattered?
Anyway, was interested as to why you took out HW acceleration in your latest builds - one of the reasons I was using them was that I understood that the acceleration would feed through into better openvpn performance?
@phil_atk, it was discovered that HW acceleration was made to help to unload the CPUs (not use as much CPU processing power), which it did; but also actually resulted in much slower throughput speeds.
A comparison of values on devices using / not-using cesa unit. Whether to use it is dictated by your use case; large data packets==greater reward. At any rate if your use case allows it you may want to take a look at wireguard
Interesting stuff. The VPN provider I use (AirVPN) uses quite strong encryption - am I correct in understanding that the benefits of HW encryption in my specific case could be relatively borderline, and ultimately come down to how I saw the balance between CPU usage and throughput?
Awesome Build! Working great on my WRT1900ACS v1 
Yes I think you are correct in your analysis. I personally use PIA, and with them I can use between AES-128 or AES-256 with a SHA1, 256, or 512. With these options, and now disabling HW acceleration. I am noticing about a 15 - 20 Mbps improvement on my bandwidth over the pipe, at the expense of CPU cycles. Still not as fast as I had hoped for, so I will likely continue to use "clients" on my network devices for the time being.
Thank you, I am glad to hear positive feedback.
@All, I am working on an incremental update 1.1 => 1.2. Only changes will be some incremental updates to adblock (2.01 => 2.02) and some smaller package updates ( Japanese translations for stats). As well, I modified the log_level for hostapd to 3 to try and cut down on the white noise in the system log. Should only log now on notifications and warnings.
You can always increase it again (default level is 2):
https://wiki.openwrt.org/doc/devel/debugging
Incremental 1.2 release is up, so far so good.
I will look into it.
In the meantime, I did leave the trunk repo in the builds. So as long as we are on kernel 4.4.39, you should be able to install from source.
Seems like I'm the only one who doesn't use VPN
And the only one who uses Luci-SSL 
Not alone 
I'm still using my clients as my VPN devices. And I did also want to use Luci SSL, but I noticed the default cert that comes with it out of the box, iirc, expired in the 2000's. The exact year I can't recall, but it was way out of bounds. If it was a recent cert, good for a few years, I would be using SSL out of the box for us all.
That's odd. Whether I use Luci-SSL or Luci-SSL-OpenSSL, the certificate generated is current (The browser still bitches because it's not from a trusted certificate authority).
Check /etc/config/uhttpd, there should see " config cert 'defaults' "
I set days to 730 (2 years), bits to 2048 (I think the default was 1024, but it may have been 2048). The values for country, state, and location don't matter (it's just what appears on the certificate generated). The important option is codename. It should be set to whatever address you use to access Luci in your browser, in my case (and probably 99% of people) simply 192.168.1.1 (or the browser will bitch about the certificate even more -- there is a way to get around the browser bitching about the trusted certificate authority, but no way to get around if codename isn't set to the address/IP used to access Luci).
Then, if you look up in the " config uhttpd 'main' " section, you'll see the location where the certificate is being stored (I left it as the default '/etc/uhttpd.crt') Simply delete that file, then restart uhttpd and a new certificate will be generated.
So my guess is when you are building, an old certificate is being generated at /etc/uhttpd.crt by the build env (Sorry if I'm using the wrong terms; I know nothing about building). If I were you, I'd include Luci-SSL or Luci-SSL-OpenSSL, have it so in /etc/config/uhttpd that codename is set to 192.168.1.1 (other cert settings are up to you), and make sure no old /etc/uhttpd.crt is being built/included in the build. It'll generate a new, fresh one on first boot when uhttpd runs.
I will look into it. I need to see if there is a sub menu to the ssl luci option. Out of the gate though, when I am in the menu choosing the options to compile, luci-ssl it seems is either on or off. So not too much room to configure it prior to distributing it to you guys (at which point would be an old cert). I will do some wiki searching on it to see is there is a way to generate a more current cert prior to compiling......
It's not luci-ssl you'd be configuring, it'd be uhttpd or specifically /etc/config/uhttpd
I wonder if the normal process is I have to write a small script to run on "first run" to generate a new self signed upon the flashes first boot.........
Hmmmm:
https://wiki.openwrt.org/doc/uci/uhttpd#https_enable_and_certificate_settings_and_creation
Did I just not "reboot" when I was testing it? 
You shouldn't have to write a script -- uhttpd automatically causes the certificate to be created on boot.
The thing is, if a certificate already exists at /etc/uhttpd.crt, a new one won't be created on reboot. So maybe when you are building it, an old uhttpd.crt is being generated.
Edit: Also that page is either out of date or incorrect -- uhttpd-mod-tls isn't required at all.(but the majority of it is good -- that's what I read about a week ago
@cybrnook, one last suggestion, since you are now adding some defaults to the builds, might I recommend for Adblock enabling the blocklist backup feature. I chose the same directory as where the whitelist and blacklist files are stored, simply /etc/adblock/ (seemed logical)
Incremental update as to stay current with trunk, r2687 CAPRICORN R1.3:
changes:
added samba network shares (I agree this would be nice to have)
added some default cleanup rules for upnp
added default of "lan" for dropbear listening
Great work as always!
Since you secured dropbear by setting it to LAN, might I recommend doing the same for Luci? (edit /etc/config/uhttpd to make the IP 192.168.1.1).
Also, there is a Luci app to easily edit uhttpd that you may want to consider adding in future builds.
Hi,
just to give you quick feedback on your build:
Running it on a WRT3200ACM (LEDE CAPRICORN 1.2 r2640-08db3e1 / LuCI Master (git-16.358.28306-df0d765)
Only using the 2,4GHz WIFI with a couple not so demanding devices, 5GHz is off.
Still had WIFI crashes with your older builds / davidc's older builds using older versions of mwlwifi.
Starting with your 1.2 build / mwlwifi 10.3.2.0-20161222 WIFI is pretty stable. Speeds are OK for 2,4GHz. Haven't seen any crashes for a couple of days yet.
Your build as a whole runs fine, only removed some packages I don't need.
Only annoying thing so far with the WRT3200ACM (besides the WIFI issues of course) is that the LEDs don't work properly (WIFI LEDs don't seem to work at all, Power LED keeps blinking even tho the router runs fine). Only the WAN / LAN LEDs seem to work properly. But that is not an issue specific to your build (Davidc's build behaved the same, didn't try any other builds).