Hardware NAT For LEDE

First of all, thanks again for your work to enable use of this...

I understand 1, but of course as you said, if your switch bandwidth, or I should better say, your switch/CPU bandwidth is the bottleneck, your wifi and everything else suffers. I see this on my C7 when running SQM, with my 300/30mbit cable modem service.

I also notice I hit 0% idle time at a lower data rate with my wifi link, than thru the ethernet.
I assume handling data thru the wifi uses up some more CPU than when it's idle.

I don't run out of CPU with WAN - Eth with my cable connection, but do if I run SQM. I can get up to 250-280mbit on the ath10k radio with no SQM, doesn't look HW limited by lack of 0% idle times. Gets close sometimes though, so I think even 74kc routers could benefit from some offloading.

As I said, with SQM running, I run out of CPU about 110-120 over the wifi, and 130-140mbit out of the LAN. Other users of CPU intensive items (OpenVPN, etc) would also benefit if it saves a heap of CPU to apply to other tasks.

For me personally, I'll be happy if it unloads things enough to set my cake limits up to my cable service speed without running out of CPU. If it's much better, might even try OpenVPN...

I'll try to do some CPU load benchmarking... so, what's needed to run this? Sysconfig over current latest LEDE? Any config after you load the patched FW? Or does it just work after the reflash?

Following questions can be considered:
Is your wireless properly configured?
Is 40MHZ(wireless n)/80MHZ (wireless ac) enabled?
Did you enable noscan to force the link to fat channel regardless of the neighbour wifi?
Did you choose a non congested channel?
Is the wireless client able to communicate at the same maximium data rates?
If you are using speedtest are you sure at the time of testing speedtest is not overload?
If you are testing over ISP are you sure at the time of testing it is not peak hours and the ISP throttle your network?
Did you log out if the router config page during testing?

Btw how SQM works is by CAPPING data rates below maximium so it will not be congested and cause latency issues.
Analogy you cannot have a max out the road capacity and ensure smooth traffic at the same.
It is not a magic bullet that gives you everything

Also Hardware NAT is NOT WORKING at the moment.
But Fast Path is, so you should head on to Fast Path thread.
Fast Path IS NOT Hardware NAT although they are supposed to perform similar functions.
I need to say this because a lot pple are confusing Hardware NAT and Fast Path


Owsome, I try the fast path firmware for my tplink 1043N v1 router,
i got about 600mbps NAT throughput by iperf
for non fast path firmware, only < 200mbps NAT before

Why all the questions? A lot of the time I'm testing my connections speed thru the ethernet, not the wifi. When I do, I am aware of how the above settings and conditions will help or hurt, and have taken them into account in my testing.

I know my C7 will handle my internet connection speed without the SQM on, but won't handle when SQM is enabled and working. I happen to want SQM, for what it does, I don't think it's supposed to help with speed. I know it slows things down a bit. I want to use it, and hopefully help with some of the C7's load so it might be able to work and run SQM at my connection speed without a large sacrifice.

So, hardware NAT is not working... anyone doing some work on that, or is progress stuck for some reason?

It can route Gigabit bandwidth on MIPS74kc!

ladys and gentlemen,


i've rewritten the qca hwnat patches from scratch built upon rev-eng knowledge derived from ssdk. currently this only works on the ipq806x + qca8337N combo. i'd love to know of a router with 8327N inside so i can make qca8k + hw nat work on that too.

with the patches i am able to reach wirepseed. i am using iperf3 for testing with 256 byte frame size udp/tcp and 10 parallel streams

there seems to be an issue with udp once frame size goes above 1472 bytes, at which point the traffic hits the sw path. i've pinged my contacts at qca and asked them to hook me up with someone that can help figure out if this is a a hw or sw bug.

apart from that ipv4/6 routing, ipv4 nat and multicast offloading work fine. hw QoS support is also functional.

these patches will go upstream soonish, once pablo from the netfilter.org team has completed his flow table offloading patches. right now the my tree still relies on a more than ugly conntack hack, which is doomed to be replaced asap....


Sounds great.

apparently it craps out if wifi is enabled, i'll look into that next week

TL-WR1043ND V2,V3


Yes! Looks like I don't need to hack on Hardware NAT anymore :joy:

@gwlim i'll try to find time to rebase the code ontop of the swconfig 8337 driver the next week. i have the netgear nand ar71xx router here which has a builtin 8337n chip


This is amazing, the TL-WR1043ND V2-V4, TL-WDR3600, TL-WDR4300 will now have hardware NAT ?, can something like this be ported to a previous version like 15.05.1 ?

I am constantly keeping an eye on this discussion. I just can't wait to see this feature integrated into LEDE official releases.

1 Like

It's great and we should document it in an official HOWTO. I will take care of that today.

It is funny to believe that a simple TL-WDR3600 behind fiber offers the bandwidth of a data center. With the development of small devices and fiver, I would not put a dime in those companies providing hosting and consuming huge amounts of electricity. The future of hosting is for very low consuming platforms...

Owsome !!
I will waiting for the Hardware NAT rather than fast path since HW NAT working with low CPU usage

Is there some way to donate, and speed things up, for adding Hardware NAT into LEDE official release?

FastPath is fully compatible with SQM. There are so smaller issues but I believe they will be resolved soon. You are saying that HW QoS support is functional. What does that means? Will I be able to use SQM with your implementation of HW NAT?

Can you clarify this please?

Please correct your answer. According to the WR1043ND Wiki ONLY hardware versions V2 and v3 are using QCA8327N. Version v4 uses QCA8337N

If I understand correctly. The v4 (QCA8337N) is already supported by those patches @blogic mentioned?

1 Like

@blogic TL-WDR4900 also has ar8327 inside.
I can test it.

If I understand correctly, fastpath can be tested here:

But how do i test hardware-NAT acceleration?
For the TL-WDR3600 is faster than fast-path, which relies on software optimization.

Can I test hardware acceleration on the TL-WDR3600?

Kind regards,