Hey everyone. For those wanting to use cloudflare DNS encrypted, you can also use stubby. (Package is in master, so you may need to adjust your package feeds.)
opkg update
opkg install stubby
Note: the default package config uses quad9, but this can be changed to use cloudflare.
I'm not sure, but my guess would be no. I'm not sure what the process is to get packages backported. If someone does, I would be willing to try. However, with a new build of openwrt on the horizon, I'm sure the devs are more focused on getting that buttoned up vs. accepting backports.
Flow Offload -- this is not an option since it's only available on kernel 4.14 and current kernel is 4.9. Performance is similar to FastPath, so no need to consider this, just patiently wait.
Hardware-based NAT -- based on this discussion, use the ar71xx MIPS24k patches. Note: On a closer look, these patches are essentially FastPath, therefore hardware-based NAT is only available in stock firmware.
It strikes me though as interesting that the guy who built the LEDE optimized firmware for Archer C7 v2 although he included in his list of changes both hardware-based NAT and Qualcomm Fast Path, there's no mention of the hardware-based NAT in his summary of changes. Maybe ended up not using it or maybe FastPath was initially mislabelled as hardware-based NAT.
I have also NOT seen any performance results on the Archer C7. One reported result with h/w-based NAT actually shows performance degradation and the original post author hinted at other factors affecting LEDE performance outside the NAT piece. On this post, there's these - unsupported by results - comments:
LAN to LAN is 1gbps for sure. Wan to LAN is about 450-500 without hw Nat which is marginally meet your requirements.
Or you use community build with hw nat enabled, 700-800.
c7 with fastpath will do ~930 mb/s nat on static/dhcp ip and ~650mb/s on pppoe
@nikandriko
The only way to have Hardware NAT enabled is to use the stock TP-Link firmware, that's why FastPath/Offload are the only options for now.
LAN to LAN: you get stock speeds, no NAT involved here, just the switch.
LAN to WAN: using fastpath or offload you get close to 1Gbps. Shapping not compatible so no SQM.
PPPOE: not compatible with fastpath, that's why the speed drop (this has been reported in this forum)
Now, my personal use case, I have a wan connection < 300Mbps, so I unload the fastpath module and enable SQM Cake/piece_of_cake to reduce bufferbloat.
Btw, if you have a 1Gbps wan connection I recommend to buy a better router, even with the TP-Link stock firmware you will have slowdowns.
I recommend you to buy an x86/x64 Fanless PC like:
Install OpenWRT/LEDE and forget the rest of options.
I'm using a Fanless PC as router very similar to the one linked before (running LEDE + SQM + VPN IPSEC + Luci +....) and after 6 six months using it, my performance "problems" are over forever.
My old C7 v2 now is working as dumb AP (running OpenWRT).
How do I know if SQM and Fastpath are active? Because I have both enabled on my Archer C7, but can't tell if they're doing their work. I suppose at least SQM is, because my bandwidth drops about 10% (in average) when it's active, which I believe is expected when any kind of QoS is taking place.
I initially thought that the thread Hardware NAT for LEDE and the referenced MIPS24k GitHub repo had found a way for LEDE to do hardware-based NAT. However, in the referenced repo, FastPath is being mentioned. Did this end up becoming FastPath? Is the thread mislabelled?
@fernandofig
To know if it's loaded you can type "lsmod" and see if fast_classifier is loaded or "lsmod | grep fast_classifier"
if you want to unload the module type "rmmod fast_classifier" and then "dmesg" you should see a message like "fast classifier unloaded" or something like that.
if you want to unload the module permanently delete the file /etc/modules.d/z-fast-classifier (I'm 90% sure of the correct filename)
@nikandriko
I think isn't mislabeled, the developers found the code for the Qualcomm shortcut engine driver, I guess they thought that was the hardware NAT implementation, but it was fast classifier, a "packet forwarding engine".
@Klingon
You can have both enabled, and if you enable SQM, fast path isn't automatically disabled.
@Klingon
Yep, I wrote that.
Maybe I didn't explain myself clear: Yes, you CAN have both enabled, BUT if you use SQM you MUST disable fastpath, otherwise performance will be impacted. Fast path isn't automatically disabled when you enable SQM.
So, I think that hardware-based NAT might NOT exist even in the stock TP-Link firmware. All that exists and has been discovered is the Qualcomm FastPath fast-classifier. Is this right?
@nikandriko
Hardware accelerated nat does exist, only that the code to make it work is not publicly available, offloading and fast classifier are just software alternatives to it.
Stock TP-Link Firmware = Hardware accelerated NAT enabled
@nikandriko
Both are similar in performance, I don't think that even using hardware accelerated NAT you'll get a constant 1Gbps WAN connection, maybe 800Mbps and that's close you will get using fastpath or offload in openwrt.
My understanding is that you can have both enabled together, but the effect of doing so will be counter productive to their purpose - you'll lose performance instead of gain it.
I'll have a try later at disabling Fastpath and see how that goes.
