Qualcomm Fast Path For LEDE

Update: during the week I tested this from another site, not from within my home-network.
Result: does NOT work: I can connect to the NAS in my home network, but when I try to transfer a large file, the download start with normal speed (about 2 Mbytes/sec but after a few seconds the download becomes very slow: only several kbytes/sec. So it seems the shortcut-fe doesn't work once it start the offloading.
When I disable fast-classifier, the download is successful, at the normal speed.

I also have another patch in the sfe_ipv4.c file which bypassed acceleration for IPSEC traffic. Just remembered that patch as well. Try patching that file and see if it works.

Update: wait, I see that this function is already in the patch I've used. So, your bypass is not working?

Where can I find that patch?

sfe_ipv4.c is part of the entire SFE package. I've made a patch to it to stop accelerating IPSec UDP traffic. Try comparing the file you have against mine:

The changes are from line 2580 - 2594 in the file shown by the link above.

Hi @quarky :slight_smile:
I was looking on your patch. I think that's not enough because:
Probably it isn't problem with offloading IPsec packets - udp 500,4500, ESP (ip protocol 50, btw. your patch not included that). In my opinion the problem is in offloading packets going through the IPsec tunnel (inside the tunnel).

What worse, I considering if your patch don't disabling offloading packets in scenario when client inside local network establishing IPsec connection to remote vpn gateway. This is a different case from case with our tunnels terminated on our router.

In previous posts I was showing that I can see in /sys/fast_classifier/debug_info connections connection established through IPsec tunnel. Example below:

o=1, p=6 [b8:af:67:70:86:7f]:192.168.1.30:59609 192.168.0.3:80:[84:3d:c6:73:d4:58] m=00000000 h=128

This is connection inside IPsec tunnel which shouldn't be offloaded, but it is

If the problem was in offloading IPsec packets - udp 500,4500 and ESP it would be visable in Strongswan logs, tunnel should be disconnecting. But there wasn't such sytuation.

I have also TL-WDR4300 and I tested you scenario. I tested it by run iperf test through ssh connection to my remote server.
After 5 minutes I did not notice any degradation in speed. CPU usage was the same, at low level. Please check your connection in /sys/fast_classifier/debug_info. My looks as follows

root@OpenWrt:~# cat /sys/fast_classifier/debug_info | grep ":22"
o=1, p=6 [dc:a9:04:88:84:52]:192.168.0.64:49569 my_remote_server_IP here:22:[b8:af:67:70:86:7f] m=00000000 h=128

o=1 means that connection is offloaded. You can check this state before and after performance is degrading

Hi @jtaczanowski,

SFE is designed to bypass the netfilter stacks processing once it has been established (i.e. after netfilter has determined that the connection is allowed.) This is similar in design to the first rule you see in the INPUT netfilter rules:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

The 'acceleration' is achieve by not going through the same netfilter checks for every incoming/outgoing network packets, as it is redundant, if it has been established previously to be safe.

So it doesn't really matter whether the traffic is going thru your router WAN link or through a tunnel to another location, SFE is supposed to 'accelerate' the connection.

I patched the fast-classifier code as the original codes does not work properly when it is used in conjunction with a not-physical network device and non-default routing table (in my case, an OpenVPN tunnel with Policy-Based-Routing.) The original code fails to find the correct output interface and when SFE kicks in, the network packets is discarded as it was sent to the wrong network interface.

I also encounter issues when using IPSec going through my router, whether it is directly via the router's WAN interface or via the OpenVPN tunnel. So I had to patch the IPv4 SFE code to bypass the IPSec traffic. AH traffic appears unaffected as far as I can tell. I guess it is because AH is done periodically, while IPSec traffic is more frequent and the SFE code does not track IPSec connection properly. Didn't spend too much time in this area tho. Planning to do it something in the future :stuck_out_tongue:

My router is accelerating (it's running my custom DD-WRT build with my patched SFE codes, as it is a Broadcom router) traffic via OpenVPN tunnels just fine. A sample of the connection that goes to the WAN port and another that goes thru the tunnel is shown below from my router:

o=1, p=17 [40:cb:c0:xx:xx:xx]:192.168.28.134:37905 x.x.x.x:37905:[00:00:0c:xx:xx:xx] m=00000000 h=751
o=1, p=17 [00:00:00:00:00:00]:192.168.27.154:37905 x.x.x.x:37905:[00:00:00:00:00:00] m=00000000 h=8088

Both connections are IPSec traffic connections. First line is from local router (192.168.28.0/24) to WAN, while second line is from remote site (192.168.27.0/24) via an OpenVPN tunnel to WAN. What I noticed is that when traffic goes thru a tunnel, the MAC address is always 00:00:00:00:00:00, which makes sense as a virtual interface does not have MAC addresses.

For your case, it looks like the SFE code is still routing traffic through a physical interface, which is incorrect. So when SFE kicks in, the network packet gets discarded. I'm not too familiar with IPSec traffic routing in the Linux kernel so I'm not sure if I can help in your problem.

Maybe someone in the forum can help shed some light into how IPSec traffic are routed and we can collectively figure out how to solve this problem.

An upstream version of offloading is ready in @nbd 's staging tree. More details can be found in his comment: https://github.com/lede-project/source/pull/1269#issuecomment-367056477

this is the commit
https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=commit;h=8d0c933b19dfa1f1fc38f685ca5925e0de7f83ce

That is one of the commits that is needed. There are quite a few commits before that that are also needed for this to work AFAIK. Simplest would be to simply clone his staging tree and compile from there.

I've installed the new image (Feb-2018) but SQM doesn't seem to work (again).
Speedtest and DSLreports results show full speed even though I throttle. Bufferbloat is awful.
Regular build works just fine.
Am I missing something?
(PPoE/VDSL)

Is this confirmed that mwan3 will not work with fast-path acceleration?
Didn't find more info in this thread.

I am using mwan3 currently without fast-path enabled and it's working fine.
Question is: Does mwan3 work alongwith fast-path?
The comment I replied to claimed "mwan3 does not work with sfe".
On this I wanted more details if someone else tried it. Does it work for you?

I went back to the version without fasth-path. I have overclocked the router

I'm using mwan3 on 1043nd with this fastpath and is working

From 51fb6dbeecd0049b51776e7f3c13c31b80230244 Mon Sep 17 00:00:00 2001
From: Tan Hong Hui <hhtan72@yahoo-com>
Date: Sat, 27 Jan 2018 10:48:26 +0800
Subject: [PATCH] shortcut_fe: add sfe kernel module

Signed-off-by: Tan Hong Hui <hhtan72@yahoo-com>
1 Like

@gwlim when using make menuconfig I see some packages which you use and are included. Could you please tell me which packages are included which are not necessary to get Fast Path working?

I'm talking about packages like: DDNS, 3G support, UPnP thanks in advance.

Doubtful - MWAN needs conntrack, SFE bypasses conntrack.

the commit I posted help me achieve ~500mb/s while the 1043nd normally does only ~270mb/s

the PR @dissent1 posted is not working anymore after some time
Regards

Did you create a new build recently?

I'm trying to create a build a firmware for the WNDR4300 but it keeps failing with both GCC 5 and GCC 6 on 17.01. What I did is following the "Patchset for MIPS74Kc AR71xx For LEDE Project" instructions and I only choose the packages I want to use plus kmod-fast-classifier, kmod-shortcut-fe and kmod-shortcut-fe-cm like @build000 did.

I think some thing changed in the latest kernel.

GCC 5 is giving me the errors described in the following Open Issue:
https://github.com/gwlim/mips24k-ar71xx-lede-patch/issues/12

Also the following PR didn't help:
https://github.com/gwlim/mips74k-ar71xx-lede-patch/pull/25

With GCC 6 i'm getting the errors described in the following Open Issue:
https://github.com/gwlim/mips24k-ar71xx-lede-patch/issues/9

If someone has any idea thanks in advance.