Did you find the correct sequence of commands? Sorry, but documentation, that you have posted, does not contain any understandable examples.
When I try to apply the patch I got that error:
...
patching file include/kernel-version.mk
Hunk #1 FAILED at 3.
1 out of 1 hunk FAILED -- saving rejects to file include/kernel-version.mk.rej
contents of include/kernel-version.mk.rej:
--- include/kernel-version.mk
+++ include/kernel-version.mk
@@ -3,10 +3,10 @@
LINUX_RELEASE?=1
LINUX_VERSION-3.18 = .43
-LINUX_VERSION-4.4 = .70
+LINUX_VERSION-4.4 = .70
LINUX_KERNEL_HASH-3.18.43 = 1236e8123a6ce537d5029232560966feed054ae31776fe8481dd7d18cdd5492c
-LINUX_KERNEL_HASH-4.4.70 = c0a8b36ca9044a91eccb475cc1c467cee1f5b296f30ca06db2b91e0589072dfa
+LINUX_KERNEL_HASH-4.4.70 = c0a8b36ca9044a91eccb475cc1c467cee1f5b296f30ca06db2b91e0589072dfa
ifdef KERNEL_PATCHVER
LINUX_VERSION:=$(KERNEL_PATCHVER)$(strip $(LINUX_VERSION-$(KERNEL_PATCHVER)))
any suggestions?
Because LEDE just bump kernel version to .71
For stuff like this I cannot be always updating the patch in realtime, so you need to realise the change and fix it yourself.
Check the Lede changelog and compare the changes
Thanks. Changed 012-update-kernel-version.patch
Patch applied. Will try to compile firmware in the night.
Hi gwilm ! Thanks a lot!
I own Buffalo BHR-4GRV2.
I am testing.
I think NAT performance will be improved by adding "shortcut-fe".
Can you give me advice on how to change patch_LEDE.sh?
1 Like
What hardware is that ?
Doesn't seem to have much info on wiki
Edit: Saw it from the git commits, it should be similar to archer c7.
You can just make menuconfig choose buffalo then choose qca ssdk From kernel module and qca utilities.
It is mips74kc anyway so every should work if you use the mips74kc my repo is not router specific but architecture specific
Is this being (or has been) submitted to master branch? If so, any idea on the revision where this has been implemented?
Which is the "official updated" shortcut fe repo?
Nevermind I saw the README in one of codeauroa repo.
Going to try it this weekend I need this to boost my Non Hardware NAT WR1043NDv1
It's not upstream yet, it's WIP. There's a newer version
https://github.com/dissent1/r7800/commit/49095f185435def1c8bcbafec8c9259dd7cf45b3
I've had to disable 2nd cpu port because in current state DSA doesn't support multi cpu ports configuration and it has caused undefined behavior.
I've tried to apply blogic's January patches for multi cpu port support, but it causes null pointer dereference in line 107 in 999-3.patch
https://github.com/dissent1/r7800/commit/5b0f90fabf46b620895fa231b796dacca30577df#diff-addd0d2fbf0f816bb745ce8803035d6dR107
2 Likes
Damn
Hit this problem
[ 61.647764] fast-classifier: starting up
[ 61.651915] /home/user/wasp/build_dir/target-mips_24kc_musl-1.1.16/linux-ar71xx_generic/fast-classifier-g79d0668/fast-classifier/fast-classifier.c[1737]: ERROR:can't register nf notifier hook: -16
This issue is similar to this
Basically fast classifier need to hook NF_CONNTRACK_EVENTS but over the years it became RCU Lock protected
Any ideas to fix this?
This is not for Hardware NAT but for Shortcut-Fe fastpath
In the old linux it looks like this
int nf_conntrack_register_notifier(struct notifier_block *nb) { return atomic_notifier_chain_register(&nf_conntrack_chain, nb); } EXPORT_SYMBOL_GPL(nf_conntrack_register_notifier);
And Atomic_Notifier looks like this
int atomic_notifier_chain_register(struct atomic_notifier_head *nh,
struct notifier_block *n)
{
unsigned long flags;
int ret;
spin_lock_irqsave(&nh->lock, flags);
ret = notifier_chain_register(&nh->head, n);
spin_unlock_irqrestore(&nh->lock, flags);
return ret;
}
EXPORT_SYMBOL_GPL(atomic_notifier_chain_register);
But now it looks like this
int nf_conntrack_register_notifier(struct net *net,
struct nf_ct_event_notifier *new)
{
int ret;
struct nf_ct_event_notifier *notify;
mutex_lock(&nf_ct_ecache_mutex);
notify = rcu_dereference_protected(net->ct.nf_conntrack_event_cb,
lockdep_is_held(&nf_ct_ecache_mutex));
if (notify != NULL) {
ret = -EBUSY;
goto out_unlock;
}
rcu_assign_pointer(net->ct.nf_conntrack_event_cb, new);
ret = 0;
out_unlock:
mutex_unlock(&nf_ct_ecache_mutex);
return ret;
}
EXPORT_SYMBOL_GPL(nf_conntrack_register_notifier);
If I patch it back to Linux 2.6 will other stuff brick?
Thank you!
I am trying your patch.
by the way,
In the throughput test of "BHR-4GRV2" (AP135 platform)
QSDK stockfirmware gives throughput of about 930 Mbps.
It is about 350 Mbps with LEDE 17.01.1. (iperf 3)
In the stock firmware "shortcut-fe" is running.
If it works with LEDE, I expect it to improve performance.
Fast Classifier is INDEED CRAZY
Qualcomm Fast Path does not require any special hardware
Should be usable on any hardware without any additional configuration at all!
Let me take a break and I will upstream the code in a few hours 
[ 10.991087] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[ 10.995181] ieee80211 phy1: Atheros AR9300 Rev:4 mem=0xb0000000, irq=40
[ 11.131974] kmodloader: done loading kernel modules from /etc/modules.d/*
[ 19.858942] fast-classifier: starting up
[ 19.863107] fast-classifier: registered
[ 21.999683] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 3] local 192.168.1.103 port 47654 connected with 10.1.1.2 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 108 MBytes 906 Mbits/sec
[ 3] 1.0- 2.0 sec 110 MBytes 925 Mbits/sec
[ 3] 2.0- 3.0 sec 104 MBytes 877 Mbits/sec
[ 3] 3.0- 4.0 sec 108 MBytes 906 Mbits/sec
[ 3] 4.0- 5.0 sec 105 MBytes 882 Mbits/sec
[ 3] 5.0- 6.0 sec 110 MBytes 920 Mbits/sec
[ 3] 6.0- 7.0 sec 105 MBytes 882 Mbits/sec
[ 3] 7.0- 8.0 sec 109 MBytes 918 Mbits/sec
[ 3] 8.0- 9.0 sec 107 MBytes 898 Mbits/sec
[ 3] 9.0-10.0 sec 109 MBytes 918 Mbits/sec
[ 3] 10.0-11.0 sec 106 MBytes 891 Mbits/sec
[ 3] 11.0-12.0 sec 110 MBytes 920 Mbits/sec
[ 3] 12.0-13.0 sec 109 MBytes 916 Mbits/sec
[ 3] 13.0-14.0 sec 109 MBytes 918 Mbits/sec
[ 3] 14.0-15.0 sec 106 MBytes 889 Mbits/sec
[ 3] 15.0-16.0 sec 109 MBytes 918 Mbits/sec
[ 3] 16.0-17.0 sec 108 MBytes 909 Mbits/sec
2 Likes
Great!
I expect it!
Thank you for listening to my story in spite of poor English.
I created a new Thread for Fast Path
Great !
I will test on my 1043N v2 for the Fast Path performance!!
Been a while... has anyone determined a gain for the original Hardware NAT on the TP-Link Archer C7? Got busy and never tried it myself. Sounded like it wasn't producing much on the C7, unless I'm reading wrong.
Also, looks like the thread is changing to Fast Path, but as I understand above comments, Fast Path won't do as much on a C7.
I'm interested in unloading the C7 CPU as much as possible, on the home router. Upgraded to a 300/30mbit cable link, and a C7 can't handle that and do SQM. I either get about 220-240mbit DL with the CPU totally hammered at 0% idle time, or disable throttling on the DL and let Cake just handle the 30mbit UL, or throttle the DL down to about 120-140mbit to keep the idle % off 0.
So, I'm interested in anything that will liberate some clock cycles.... 
Instructions on getting semi-literate user to set this up and get it functional, (if it will help me at this time) will be appreciated!
Fast Path already hit Wire speed on WDR4300 with 1500 MTU with no special setting on the Router at all.
You should check the Fast Path thread
And if yours is an Archer C7 v2 firmware already available.
If course I am still trying to optimize the build for better performance as always
There definitely is a difference between the stock Archer C7 V2 and LEDE Fastpath firmware. When bench-marking over 5G Wifi, stock is able to saturate my ~200Mbps ISP and on LEDE w/ Fastpath I get about ~150 Mbps.
Since I've owned the router unless hardware NAT is enabled I can't saturate my link.
1)Hardware NAT is a switch mechanism to accelerate packet forwarding it has NOTHING to do with WiFi
2)Fast Path is similar to Hardware NAT but is not a hardware based solution instead it optimizes Routing Network Stack
3)Wifi is Wifi it doesn't do packet forwarding
Fast Path /Hardware NAT only helps WiFi IF the Processor is heavily loaded by NAT activities and does not have sufficient power to do WiFi at the same time and the activity involves both WiFi and NAT.
And it applies only to weak SoCs like MIPS24kc.
I have tested repeated even on Non-Fast Path/Hardware NAT LEDE stock firmware that MIPS74kc is capable of doing full WiFi NAT transfers especially at a low speed of 200Mbps
Please check your understanding.
Correlation is not causation
1 Like