Hey,
topic basically says it:
Is there any viable way to get back speeds closer to the 700-900Mbit/s range on todays firmware?
We used to have this, now i need it just to go a little bit faster than the 300ish im gettig right now... router is running fine since forever, dont want to buy a new one yet.
Anyone having faster speeds here?
What's the secret sauce?
P.s. This firmware gave us 700mbit, how to recreate, if possible?
Do you have a v4
From
I'm guessing not FOSS:ed code.
Which version of OpenWrt is now on your C7?
Have you already activated Software Flow offloading in the Firewall settings?
Second it. According to this OneMarcFifty's youtube video, TP-Link Archer C7 should be able to reach higher speed via Software Flow Offloading in Firewall Settings
Yes, it's on.
But unlike the the speed in the video, its barely reaching 300mbit on the local network (via ethernet cable).
Maybe some bug has gotten back into it?
How can we find out?
P.s. It's definitely the router/OpenWrt, other hardware gives me much more speed with the same infrastructure.
RJ45 to RJ45 ?
I did some research, and it appears a bug could be introduced since OpenWrt 22.03.x for Archer C7 device. See below discussions for possible workaround in nft firewall settings :
Although the suggestions are for PPPoE WAN connection, normal IP WAN connection could also be affected as a result.
Thanks for the research.
This is a little bit above my tech understanding, anyone with some practical tips on what to change?
how are the chances this gets fixed in the next versions? some of the discussions are already 2 years old...
This piece of hardware is from 2013, see: https://forum.archive.openwrt.org/viewtopic.php?id=44201
Now 13 years later you can either accept the wireless router performance limitations of this years old single core 32 bit MIPS 74Kc 720 MHz design and use it as a fast Wifi 5 access point. Or you accept the limited performance in wireless router and firewall mode.
Spending hours or days of trying to tune 13 years old hardware designs will not get this old hardware matching today's performance needs above 300 Mbit/s as wireless router with firewall.
What about ARM dual core or quad core SoCs instead of single core 720 MHz MIPS 74Kc? What about SQM? What about 11ax?
It's amazing you can run recent OpenWrt from 2026 on 13 years old hardware.
I bet: chances are around zero if you don't do it by yourself. There will be little or no interest in spending limited life time trying to squeeze more performance of generation 2013 Wifi 5 single core hardware. Consider development of Archer C7 on OpenWrt to be finished.
2016: Even Netgear R7800 dual core 1.7 GHz ARM tuning is now less popular as many users have Wifi 6 11ax stations: Netgear R7800 exploration (IPQ8065, QCA9984)
2021: Belkin RT3200 - Linksys E8450 Belkin RT3200/Linksys E8450 WiFi AX discussion
2023: GL-MT6000: GL.iNET Flint 2 (GL-MT6000) discussions
People are now trying to get Wifi 7 - 802.11be working. 
Someone suggested some possible fix: https://github.com/openwrt/openwrt/issues/12571#issuecomment-1766430811
Give it a try.
The bug is still present in 23.05.0 r23497-6637af95aa.
But it can be fixed setting Software and Hardware flow offloading on, and then adding to /etc/hotplug.d/iface/20-firewall:
nft flowtable inet fw4 ft-bridges { hook ingress priority filter\; devices = { pppoe-wan, br-lan }\;}
nft insert rule inet fw4 forward meta l4proto { tcp, udp } flow add @ft-bridges
I would try that also. Maybe replace pppoe-wan with wan in the first command if it's not PPPoE connection.
PS: Has ath79 SoC already switched to DSA architecture?
This is Archer C7v2 LAN-to-WAN@DHCP using OpenWrt 25.12.4, default settings with only flow offloading turned on:
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.01 sec 112 MBytes 934 Mbits/sec
[ 5] 1.01-2.01 sec 111 MBytes 929 Mbits/sec
[ 5] 2.01-3.01 sec 112 MBytes 944 Mbits/sec
[ 5] 3.01-4.01 sec 110 MBytes 925 Mbits/sec
[ 5] 4.01-5.01 sec 110 MBytes 926 Mbits/sec
[ 5] 5.01-6.01 sec 110 MBytes 926 Mbits/sec
[ 5] 6.01-7.01 sec 110 MBytes 925 Mbits/sec
[ 5] 7.01-8.01 sec 110 MBytes 925 Mbits/sec
[ 5] 8.01-9.01 sec 110 MBytes 926 Mbits/sec
[ 5] 9.01-10.01 sec 110 MBytes 923 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.01 sec 1.08 GBytes 928 Mbits/sec sender
[ 5] 0.00-10.01 sec 1.08 GBytes 927 Mbits/sec receiver
As you can see, close to wirespeed.
When using PPPoE or other IP encapsulation protocols, your speed may(!) be significantly slower than the example above, though.
The gwlim firmwares were more or less just snake oil, since he refused to publish the source code (which is a GPL violation!). When asked to release the source for GPL compliance, he usually replied elusively or not at all.
From my experience, ath79 with flow offloading was always faster than QCA's "HW NAT". It was said that the capabilities of the QCA8327N switch (which would do the hardware NATing) are fairly limited, so in real life, OpenWrt's flow offloading would perform much better. Qualcomm's SFE, on the other hand, is also just a software flow offloading implementation.
ath79 is still swconfig, not DSA. I think I remember reading (here or in the issue tracker) that the DSA driver for QCA switches has issues on big endian platforms like ath79, which nobody felt like fixing yet.
With PPPoE your throughput will be significantly lower, because PPPoE is handled in software on the CPU. Anything close to wire speed would require a PPPoE hardware packet processing engine to offload the CPU, which this SoC doesn't have.
On these old single-core MIPS 74Kc designs (QCA9558 @ 720 MHz), routed throughput with PPPoE realistically tops out somewhere under 200 Mbit/s, depending on the exact load.
And for a usable connection you'll also want SQM to keep bufferbloat low. With SQM enabled, expect to land roughly in the 150 Mbit/s range. The exact figure depends heavily on your SQM config (cake vs. fq_codel, link-layer overhead compensation, etc.).
So it comes down to three options: either those numbers are fine for your needs on this 13-year-old hardware, or you drop some of the load (WLAN, SQM), or you move to recent ARM multi-core hardware with Wi-Fi 6 (AX), more flash and more RAM.
We're talking software, not hardware flow offload here. NFT's conntrack (which is what OpenWrt calls "flow offloading") supports PPPoE. But yes, it adds more load on the CPU and since the 720MHz QCA9558 is running at >90% load for the above example already, performance should drop with any additional encapsulation done.
I don't have a PPPoE testbed running, so I can't post numbers - that's for others to test. Guesswork won't help, though, and nobody was talking about adding additional CPU-intensive features like QoS to this low-end SoC in this thread, right?
The OP was claiming that he's getting ~300Mbps in a LAN-to-LAN setup, but didn't give any more details on his exact device model or setup.
I showed that wire speed is possible in a LAN-to-LAN environment using the latest stable OpenWrt on the lowest-clocked Archer C7 version. Nothing more, nothing less, so q.e.d. 
P.S. WiFi speed is in fact around 300Mbps max on this device (2x2 client on a 5GHz WPA3-SAE SSID), which is what I'd expected. But OP can't talk about WiFi with his "700-900MBps" wish, since I have only seen such speeds for WiFi6 with WED (on Mediatek) so far. Such speeds would be utopic on a WiFi5 Wave1 low-end device.
I used Archer C7 v2 for many years and was satisfied. The real world speed with what OpenWrt is built for: wireless router is a lot lower: under 200 Mbit/s. With SQM and leave some buffer for other tasks you are more in the space of around 120 Mbit/s, all included: wireless LAN, PPPoE, SQM, router, firewall.
You can create best case scenarios for only wired routing, leave wireless LAN out of the equation, no PPPoE, no SQM, no firewall no anything, software flow offloading enabled. Then you could get a lot more speed. Or you just accept the hardware limitations and use these 13 year old designs as a poweful wireless access point and do routing, PPPoE and SQM on more powerful hardware.