An important note from @gwlim:
1 Like
Thanks, I didn't know it would drop that much performance. Anyway, considering this build uses FastPath I think the performance penalty is neglectable.
1 Like
Agreed; I think it should be enabled by default.
A suggestion I have is adding another FAQ entry saying that anyone not on a PPPoE connection can disable MSS Clamping for a slight speed increase.
1 Like
Good idea. Done! 
1 Like
Can someone point me to on how to mount an external ntfs hard drive that can be accessible by the LAN?
@r00t Is the slower Wi-Fi performance on your build due to hardware NAT not being supported? On stock FW I can achieve 850Mbps + via iperf on 5GHz (80MHz, 1300Mbps connection rate) but only about 650Mbps on your firmware.
Yes, that's likely the reason. 650Mbps is pretty awesome already compared to stock LEDE, which is doing about half as much I think.
If I read the last two messages correctly:
Stock LEDE: supports hardware NAT
This Build: doesn't support hardware NAT and is slower than stock?
@jackiechun No, stock LEDE doesn't support hardware Nat. Stock TP-Link firmware does. This firmware speed is between stock LEDE and stock TP-Link.
Stock LEDE: +- 300Mbps
R00t's: 650Mbps
TP-Link: 850Mbps
(As per informations found on this thread)
1 Like
Many thanks! I've spent so much time on OpenWRT/LEDE that I've forgotten about stock TP-Link firmware 
I've flashed this firmware on my two Archer C7v2s and they are absolutely purring. Thanks @r00t!
Sorry, but when you say mtu_fix fixed to 1, you're referring to /etc/config/firewall file and the WAN zone?
Thanks everyone!!
I'll let @r00t confirm this, but yes I think so.
I believe it's adding the last line in the snippet below under the WAN zone to /etc/config/firewall, which is consistent to the fix mentioned over in the Fast Path thread (Qualcomm Fast Path For LEDE - #188 by SorinFCS):
config zone
option name 'wan'
option mtu_fix '1'
The equivalent GUI approach would be ticking MSS Clamping for the WAN zone and Save + Apply.
Of course only do this if you experience issues or are on a PPPoE connection.
Firts I installed LEDE 17.01.2 and then sysupgraded to @r00t optimized firmware.
Later, when I checked my firewall config file I realized mtu_fix was set 1.
Maybe the LEDE 17.01.2 version comes with that feature by default, I don't remember changing it.
Yes it was made default in the optimized nightly since ~July 7th 
@r00t added a new FAQ entry in the first post in this thread regarding this new default setting:
The slower WiFi compared to stock has to be a driver issue as the extensive research I've done suggests hardware NAT has no effect on WiFi speeds.
@root it seems that there is a solution fot the problem with the fast-classifier. Will you apply the patches from @dissent1 when its solved?
@r00t: Why would you need to switch architectures to install 24kc packages? You can just add 24kc as a opkg architecture, and the processor will run it.
@corrideat It says switched to 24kc... Because he was building on 74kc before as you can read in the changelogs
I know he was building on 74kc and that he switched back to 24kc so that people could install the pre-built 24kc packages. What I'm saying is that one can run both 24kc and 74kc binaries (and opkg will happily abide by this with the right config), and so that I don't see the need.
If I understand it right, it's like running i686 and i386 binaries on a i686-capable machine: both run, but the i686 binaries might benefit from additional features.
I know because I'm currently running stock LEDE on my C7 (24kc), with a 74kc hostapd.
That didnt work because it was custom, it gave architecture errors when 24kc opkg was added..