Hardware NAT For LEDE

Thanks @lucize

I remember looking at switch UI with two CPUs and I thought this was a dual core. I guess the only benefit is faster and newer CPU would do faster bit-banging to give me a better performance on ethernet till this forum's effort gives me the real hardware NAT in the next release. I am already using another AC access point that connects to this router.


as mentioned a a previous post, I have a wdr 4300 v1, with stock v17.01.4, I get ~100mb download on my 1gbps fiber connection (tested with speedtest, the isp's router provides full speed on the same test) , so I've decided to be adventures, checked out lede from git (last commit hash is 175538ffdb6605f7485750f9058f3815eb07bb89). I've took shortcut-fe's patch from dissent, configured the following config, changed the optimization from size to level 2, fixed the nfs-utils compilation bug and generated an image.
upon running speedtest, I get less than 10 mbps which is less than stock.
I've configured sqm too.

what might be wrong? do I need to see any hints on the kernel's dmesg?

There were some very interesting stuff happening in this thread a few months ago, for example @blogic's qca8k patches (especially with multiple CPU port support) and @philjohn's QSDK porting.

Are there any updates on these or are these projects abandoned now?

Check your "sirq" when doing the backup. Faster CPU will help.

Also look at "idle", if idle gets too close to 0 you know that you are running out of CPU cycles... (often the cycles missing in idle are showing up in sirq, but not always...)

I had to port a crazy number of patches across, but even with all that I couldn't get SSDK compiling properly - until and unless Qualcomm track upstream closer it's a non starter tbf.

Thanks for the update. I'm sorry to hear that.

I think that's the issue.
shortcut doesn't work too well with SQM.

thanks, will try without sqm

I think you effectively do this with sqm, with gwlim's patch I believe shortcut will have precedence over sqm, with dissent1's patch sqm will have priority. It should be generally okay to use sqm on other interfaces than the wan interface even though I believe features like cake's de-NATing will not work in that case (but I never tested shortcut myself, not my cup of tea).

well, I think this path is a bust, I've removed sqm, tried to test the speed, not good at all.
I'm using lede from yesterday's git, added dissent1’s patch, no sqm at all (few more patches like compile system with -O2 and fix nfs issues), this is what I get with the ISP's router:
with the lede firmware:

I'm out of ideas.

Why not try the upstream offloading implementations that recently hit the Lede master branch?

  1. Make sure you compile with kernel 4.14 (older is not supported)
  2. In make menuconfig make sure you select the new kernel module called "kmod-ipt-offload", which will automatically also include "kmod-nf-flow"
  3. Add the offloading rule to the forward chain in iptables:
    iptables -I FORWARD 1 -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD
  4. If you want to disable offloading again, you can revert if by using:
    iptables -D FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j FLOWOFFLOAD

@Mushoz this rule is causing connection drops on Spotify, IRC and certain other applications which are using TCP. Im not quite sure why though. We had an user with similar issues in this forum.

Isnt netflow only compatible with nftables?

No ipt = iptables

Which rule? The offload rule in the forward chain? @nbd might know why that is happening. I think it would be helpful if we help him test and debug these kind of issues :slight_smile:

Exactly, well im certain that it isnt the direct cause but something in Flowoffload is breaking established connections.

Seems that the flow offload code has some agressive timeouts and is missing some TCP state tracking functionality. I'll will work on fixing this soon.


Good news everyone, I've added some fixes for the connection drops. Please test the latest version :slight_smile:


Self hosted services still dont work for me. (i found out about today)

Port forward of port 443 (ssl) to internal device (WAN->LAN)
Access from other device in internet returns Connection Reset, as soon as it gets accessed.

When i disable the above iptables rule everything magically works again.