OpenWRT 19.07 and bcm53xx target + flow offloading

Hello community,

I'm having troubles with my Phicomm K3 router:

It works really well with 19.07.0 version in all areas except it's WAN->LAN routing performance is sub-optimal: I'm getting only ~500Mpbs of my 1gpbs link (no QoS, etc) where my other router (Netgear R6300V2 with FreshTomato 22019.4) is able to achieve ~940Mbps (with CTF enabled). I read the whole story about flow offloading and hardware NATs and was hoping that enabling 'software flow offloading' would help. However it seems to have no effect at all.

I tried to flash a forked version from here which has 'Turbo ACC' options; those do not help either.

Any ideas how to fix this? I could assemble my own custom OpenWRT build if needed;


I'm aware of flow offloading for certain ramips and ar71xx/ath79 boards, but not for any Broadcom targets. The github link you shared does not seem to talk about offloading either at first glance, nor does the OpenWrt wiki entry.

Long story short: Broadcom doesn't care about FOSS - which is particularly visible in their wireless drivers, but also translates in other areas.

I was referring to software flow offloading, which is a kernel feature, and doesn't need any hardware support, afaik. With 2x1.4GHz ARM cores it should handle 1gbps link decently; for some reason it doesn't.

p.s. wireless performance is completely irrelevant in this case as I'm testing using wired connections only; besides, wifi drivers situation is not that bad anymore, latest firmware blobs allow 160Mhz and DFS channels

My bad, software offloading seems to be supported on all hardware indeed. MT7621 (ramips) has hardware support for it.

I would just settle on software offloading working. This router has some flaws but for $40 shipped it has no competition. It's only weak point I found is NAT speed, which affects me, unfortunately.

Up. Anyone with experience with this topics?

Could you please share the exact procedure for flashing the trx file to the router with default firmware? I also want to try openwrt on this hardware but have read some users complaints at the chinese forums about the 5ghz transmission flaws. Have you tried using the wifi continuously and if yes - what is your impression so far besides the slow WAN to LAN performance?

Thanks in advance

I was basically using last post from this thread.

Didn't have to use TTL.

So, seems like I found a solution which restores full wire speed for NAT for broadcom routers.

TLDR: turn off GRO.

More details here.
Apparently it is a regression triggered by missing hardware acceleration in bgmac driver.
Not sure why this is not fixed in the openwrt or Linux kernel still.

With the following changes this router becomes a beast:

  1. 'GRO off' (ethtool -K eth0 gro off) restores 1gpbs NAT
  2. Irqbalance moves wifi and switch irqs to different cores - CPU never overloads.
  3. New brcmfmac4366-pcie.bin driver (Mar 2020) allows for 160mhz channel (actually works)
  4. Tweaked latest regdb allows for txpower tweaks, dfs channels, and serves as a workaround for luci dfs problem.

Hope this helps.

P.s. seems like this router is now sold as QUANTUM DAX/WL-WN538A8 for $20-50 in bulk. A new cheap openwrt hit?

1 Like

Hi, can you please share your setup in more details (like where did you get the brcmfmac4366-pcie.bin ; i was planning to use the ones from
I got a k3 a while ago but it was dead (no serial), just yesterday I managed to soldier a spi and put CFE on it so i can fix the nand - seems ok now (still in bits but with 19.07.3).
I have this topic - maybe we can merge them and put some structure into it, i will post some photos of the debricking process. There is tons of info on but even with the translator it is hard to understand and lots of it is hidden because i can't reg.


I extracted driver blob from the latest Asus firmware. There is also one (same) in the forum discussing 160mhz channel. I only replaced driver, added irqbalance, turned off GRO and removed dfs from reg db. That's basically it. Driver txpower for 5ghz should be around 23-25.

There are some glitches still - dfs is not working in luci, 160mhz channel is not advertised correctly (however Intel ax200 connects at 1.7ghz rate to it still)

Maybe that's the problem I'm facing too, I'm getting tested. Builds for Linksys WHW03 V2 + V1

Different chipset... Easy to test though. It seems like optimizations in kernel made to speed up 25gpbs+ links are actually hurting performance of slow links with slow CPUs and/or poorly supported switches.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.