Flint 2 (GL-MT6000) — intermittent per-client WAN throughput cap (~50 Mbps) due to hardware offload / HNAT, not cleared by reconnect; "Network acceleration" GUI toggle does not actually disable the offload

Router
1

Device / firmware

  • Model: GL-MT6000 (Flint 2)
  • Firmware: 4.9.0 (OpenWrt 21.02-SNAPSHOT, kernel 5.4.238, closed mt_wifi driver)
  • Topology: GL router WAN (DHCP) behind an upstream router (double-NAT). WAN link negotiated 2.5 Gbps full-duplex, 0 errors.
  • Affected client: laptop with Intel Wi-Fi 6E AX211, connected 5 GHz, 160 MHz, 2 spatial streams (the only 160 MHz client on the network).

Symptom
Intermittently, one Wi-Fi client's internet (WAN-forwarded) throughput collapses to ~50 Mbps and stays there for extended periods. During the throttle:

  • Wi-Fi link rate is a healthy 2402 Mbps, signal ~97%, RSSI ~−50, 0% packet loss, ~0 TCP retransmissions.
  • The station's PHY stats are byte-for-byte identical to the healthy state (HE, 160 MHz, 2SS, MCS11) — so it is not RF/signal/rate related.

Isolation / measurements (same server, near-simultaneous)

  • Router → internet (Cloudflare): ~1,040 Mbps (healthy)
  • Affected client → internet (Cloudflare): ~42–52 Mbps (throttled)
  • Affected client → router (LAN, HTTP from router): ~700–786 Mbps (healthy — proves the Wi-Fi link and client adapter are fine)
  • ⇒ The bottleneck is specifically the WAN→Wi-Fi forwarded path for that station, i.e. the hardware offload/HNAT, not the radio, the client, or the ISP.

Kernel evidence
During the throttle the log floods with:
skb_to_hnat_info: callbacks suppressed

What does NOT clear it

  • Client Wi-Fi re-association (disconnect/reconnect)
  • Router-side wifi restart (down/up)
  • conntrack -D flush for the client
  • PPE binding-table flush (hnat_entry)
  • /etc/init.d/mtkhnat restart

What DOES clear it

  • Full router reboot (reliable)
  • Occasionally a long client Wi-Fi radio off/on
2

Hi there,

Please note that the wifi advertised phy speed is only on the wifi chip, but will be not entirely hold true because that is only weighted against wireless to wireless directly.

If it touches wan or lan it will go over the cpu chip eventually which is slower.

However, 50MB speed seem to be broken, and I wonder if there are various things going on in your network not reported in your post.

Do you have somewhere a instance of torrenting or DHT running?

^ these two can fill up conntrack extremely fast, and eventually start discarding packets causing time outs on the network, I had this with bitmagnet recently and learned that this is what DHT can do, in luci I have added a traffic rule to not track the traffic, but you can also limit it to 120/hour (120 connections per hour).

This looks awfull similar to the conntrack message in vanilla firmware, although it is Mediatek sdk driver message... If you have conntrack installed can you look for me into this:

cat /proc/sys/net/netfilter/nf_conntrack_count

^ you can use the arrow up key to spam it a few times over time, in the cli to see some more changes, give it some time to see if it also decrease back, a value over 9999 can be already a warning of to many connections, I have 50 device and I see no more than 400 here maximum 1000 maybe :smiley:

And I also want to know the limit.

cat /proc/sys/net/netfilter/nf_conntrack_max

And if the case of conntrack is indeed ramping up or exceeding max, and not clearing can you look for me which client comes up the most frequent in conntrack -L?

A too full table can cause NAT exhaustion and can have these symptoms you are describing, it can make the network slow, hardware accerelation can give frequent time outs or even full outtages, these two things can listen very close to each other.

3

Thanks — I don't run any torrent client, and I checked the conntrack data you asked for:

nf_conntrack_count: sampled 459, 459, 459, 459, 353 over ~10s (stable, not ramping)
nf_conntrack_max: 16384

So the table sits at ~2.8% of max, nowhere near exhaustion, and it's not climbing.
Breakdown of the current table: 244 TCP / 99 UDP entries, busiest client is 163 entries, no DHT/torrent UDP flood (only 99 UDP entries in total across all clients).

So during the actual fault, conntrack was 522 / 16384 = ~3.2% and not spiking, not exhausted.

NAT/conntrack exhaustion doesn't appear to be the cause.
The skb_to_hnat_info flood appearing only during the fault, is what points me at the HNAT/WED per-station offload rather than conntrack. I could be wrong though.

For context on why I don't think it's a CPU-throughput limit either: during the fault the router itself still pulls ~1-1.8 Gbps from the internet, and the affected client does ~0.8 to 1.8 Gbps to the router over wifi. It's specifically the WAN>client forwarded path for that one station that caps at ~50 Mbps.

This is something I have seen since at least a year ago.
I connect to wifi, normally get 1.8 Gbps from internet, no issues.
It’s a very lean laptop, only minimal software.

The issue is intermittent and it simply reduces my internet speed to around 40 to 50 Mbps.
I have tried everything I could think of on the device side, but I have another router from my ISP and the issue doesn’t happen, so the issue is that somehow, wan to my device via wifi, gets limited.

Even claude or codex cannot seem to understand the issue.
I had both of them doing exhaustive tests, and both can only confirm the bug.

It’s not something easy to replicate because once I connect, it is very fast and stays fast for several hours. Sometimes however, I notice the slowdown, and when I check, I am again limited at 50 Mbps.

Sometimes just disconnecting from wifi and back, solves it, but most of the time it doesn’t.
Rebooting laptop doesn’t fix it. Rebooting router fixes it.

Found a few reports… may be related.

There is a MediaTek HNAT/WED hardware-offload bug, with several matching reports, including one on this exact device:

Given I'm on firmware 4.9.0 (OpenWrt 21.02 base, kernel 5.4.238, MediaTek SDK mt_wifi driver), my questions for support:

  1. Have the recent MediaTek HNAT fixes — specifically the skb_to_hnat_info entry-state fix and related WED/HNAT patches from the mtk-openwrt-feeds SDK — been pulled into 4.9.0? If not, could they be included in an upcoming build?
  2. Can you reproduce or confirm the WLAN↔LAN / WAN→WLAN offload issue from #18589 on the GL-MT6000?
  3. Separately: the "Network acceleration" GUI toggle does not actually disable the offload on my unit. It was showing OFF, but mtkhnat.global.enable was still 1, the mtk_warp/mtk_warp_proxy (WED) modules were loaded, and mtkhnat was running. Toggling it in the UI produced no change. Please check whether that toggle truly disables HNAT/WED and persists across reboot, since it would give me a workaround while the driver issue is investigated.

Summary of the fault for reference: intermittent, one 5 GHz client (Intel AX211, 160 MHz/2SS) capped at ~50 Mbps on internet-forwarded traffic; Wi-Fi link stays 2402 Mbps, 0% loss, ~0 TCP retransmits; router's own WAN ~1 Gbps and client→router LAN ~780 Mbps at the same time; skb_to_hnat_info floods the log only during the fault; cleared only by a full router reboot.

1 Like
4

Thank you for confirming this so indeed this is not a exhausted NAT, it seems to be a hardware offloading bug but not a super common one.

So this pushes me into the direction, that this AX211 card may could hold certain features which could be incompatible with the hardware offloading from the MT6000.

Do you use this card on a windows system?

If so, could you screenshot the features it has by using win+r and then typing devmgmt.msc, go to network adapters, then click on properties, there should be a tab named advanced settings.

Could you screenshot these options?

There are maybe a few options which you can try to uncheck, such as anything related to big jumbo packets, or super packets, enhanced wifi, and as last the offloading ones, green wifi/or related, just try them for each.

What I suspect is that these propetairy designs clash with each other, and Flint 2 then fails.

On OpenWrt vanilla I had the same familar issue... But my B650 board had also Mediatek yet I was forced to disable alot of features because the Flint 2 completely became unrecoverable everytime I download on steam and also very random.

5

Hi,

Device is an Asus Vivobook S16 with Windows 11.
Here are the full advanced settings for the Intel AX211:

  • Throughput Booster: Enabled, I already tested this Disabled.
  • Receive Segment Coalescing (RSC): Enabled (IPv4 + IPv6), tested.
  • Packet Coalescing: Disabled (already off)
  • U-APSD support: Disabled (already off)
  • MIMO Power Save Mode: No SMPS (off)
  • Transmit Power: Highest
  • Roaming Aggressiveness: Lowest
  • 802.11 Wireless Mode: 802.11ax
  • Channel Width (2.4 / 5 / 6 GHz): Auto
  • Preferred Band: 5 GHz + 6 GHz
  • Fat Channel Intolerant: Disabled
  • Mixed Mode Protection: CTS-to-self Enabled
  • WoWLAN wake features (ARP/NS/GTK offload, Wake on Magic/Pattern): Enabled

This card exposes no jumbo-frame, "green Wi-Fi," or TWT options, so Throughput Booster and RSC are the only "super-packet"/offload-style toggles available.

Since WED/hardware offload only engages on forwarded traffic (not router-originated LAN traffic), an AX211 feature that the WED engine mishandles on the forward path , would explain that LAN-fast/WAN-slow split exactly. So a client-feature ↔ WED interaction is plausible.

Client Wi-Fi driver details (Intel AX211): Intel driver v24.40.0.4, dated 2026-04-13 (Netwtw14.sys, NDIS 6.60), so this isn't an outdated-driver issue in principle. I have seen this for a while, through different versions.

A client Wi-Fi reconnect does not fix it usually, only a full router reboot does.
That suggests the stuck state lives in the router's WED/HNAT per-station binding, not in the client card.
However, the card could be the trigger that pushes WED into the bad state, after which only clearing the router resets it.

6

Thank you for the detailed post, I'm out of ideas at the moment, the driver features seem to be ok.

I was hoping to see some kind of ipv4 offloading or things like large receive offloading or large sent off loading or other vague ones, but your wifi features look rather clean.

There is one more thing you might can try depending where on the port it traverse to on wifi, I guess wan?

try this:
ethtool -K eth1 tso off gro off gso off it is not persistent after reboot it is old behaviour again.

gro for example wants to put multiple small packets into a large one, it is discussed in quite some communities that Mediatek can have issues with them, tso and gso are for sending and gro is for receiving.

You may aswell try this ethtool command directly on the phy to see if that works, if you know its name with ip link show just to be sure your wifi card is not accidentally sending special large packets even when it isn't shown as option.

@will.qiu do you have any ideas here?

7

Thanks! Tried it, no effect, and I was able to test it during an active slowdown.

I disabled TSO/GRO/GSO on all relevant interfaces (eth1 WAN, eth0 switch, and the rax0 Wi-Fi phy via ethtool -K), and the throttle persisted unchanged:

  • PC → internet: 49–50 Mbps (capped)
  • PC → router (LAN): 875 Mbps
  • Router → internet: ~991 Mbps
  • conntrack during the fault: 400 / 16384 (again, not exhaustion)
  • All of tcp-segmentation-offload, generic-receive-offload, generic-segmentation-offload confirmed off on eth1/eth0/rax0 at the time of the test.

So GRO/TSO/GSO aren't involved, which makes sense, since with hardware offload (HNAT/WED) enabled, forwarded packets bypass the kernel stack where those settings apply.

Everything continues to point at the WED/HNAT hardware offload engine itself: it's the only component in the WAN→Wi-Fi forwarded path (which is slow) that isn't in the LAN or router-local paths (which are full speed).

I disabled hardware acceleration and rebooted and normally, my full speed is back after a reboot always… but this time it didn’t.

Switched from Auto to Software, speed came back. Will see how it goes.

1 Like
8

I have another idea to test :wink:

Is the mt6000 running as routing mode or as extended mode / having a dumbap design?

I learned on the OpenWrt forums WED does not work correctly or barely have results in such dumbap setup.

It is advised to use bridger for offloading, this as replacement to WED.

Or... Use routing mode, but its not clear which mode your router is.

9

A dumb AP would have one subnet, everything bridged, and no NAT.
My setup is in routing mode, not dumb-AP/extended.

  • LAN: br-lan = 192.168.8.1/24 (its own subnet)
  • WAN: eth1 = 192.168.1.51/24, proto dhcp, behind my upstream router
  • Firewall WAN zone masq=1, so it's doing NAT/routing between the two subnets (double-NAT overall).

So it's a normal routed+NAT setup, not a bridged AP, which is exactly the scenario WED/HNAT is designed to accelerate, so that shouldn't apply here.

What the timing of this issues point to, is for something that builds up or gets tripped over time in the forwarding/offload state.

Or the hardware flow table slowly accumulating stale entries until a collision/overflow corrupts the station's binding,which takes hours/a day depending on how much traffic has cycled through.

Both point back to the same subsystem (WED/HNAT), with a time/event trigger, which is also why a reboot fixes it: it resets the accumulated/corrupted state, and it takes hours/a day to re-trigger.

For now I will check with software mode, if it comes back.

1 Like
10

Yup, from all the answers to my questions I think you are correct in your foundings, I hope GL-iNet can help​:+1:, other than this I can't see a other way why it slows down but clearly it is WED related.

11

Thanks for helping though!

1 Like
12

Hi,

Thank you for your feedback.

Could you please try or provide the following information so that we can investigate this issue further?

  1. As you've been testing, does the issue still occur if you completely disable network acceleration or switch to software acceleration?
  2. Does this issue affect all wireless clients, or only a specific device?
  3. If it's only one device, please also provide its wireless adapter model (we think should be AX211), driver version, and operating system version.
  4. Please export the system logs while the issue is occurring and send them to us via private message so that we can investigate further.
How to export logs:

image
image1430×911 87 KB

How to send private messages:

image
image632×233 19.1 KB

14

Unfortunately, with WED disabled (whnat_en=0) it still throttled a few hours later.
I checked my phone when this happened, a S23 Ultra, and it’s also throttled to around the same speed.

Wan to router is fast.
Router to devices is fast via wifi.
Internet to devices gets limited to about 50 Mbps.

I have excluded this being client side.
Also not the first reset done on this router, same issue.
Latest firmware, but this happened for a least several version upgrades.

Apparently, when it throttles, every client is capped at ~50 Mbps simultaneously, while:

  • the router's own WAN throughput stays 1+ Gbps (curl from the router to Cloudflare),
  • LAN (client→router) stays 1+ Gbps,
  • CPU is 100% idle, conntrack ~5% of max, no QoS/SQM/rate-limit configured.

So it's a router-wide degradation of the forwarded (WAN↔LAN) path, not the AX211 and not per-station.

I disabled hardware offload every way available.
mtkhnat software mode (actype=2), Network acceleration off (enable=0), and WED wireless off at the driver level (WHNAT=0, confirmed whnat_en=0 in dmesg) and it still throttled after ~11 hours. It only clears on a full reboot, then returns after few hours.

Given all client-forwarded traffic degrades identically while the router's own traffic and the LAN bridge stay full speed, with the CPU idle, this looks like the hardware forwarding/PPE path corrupting over uptime.

Can you reproduce a router-wide forwarded-throughput decay on the GL-MT6000 over ~a day of uptime on a 1+ Gbps internet wan?

Maybe confirm whether the current MediaTek HNAT/PPE fixes are in 4.9.0?

Will send the logs privately, thanks

15

Hi,

Thank you for providing the logs and additional information.

We need some time to discuss this internally and will keep you informed of any further updates or developments.

16

Hi,

The issue persisted, so I have decided to reset the router, reinstall the latest firmware again and just use defaults as much as possible.

I’ve done this a few times before on previous versions of the firmware, and the issue was persistent. However, for the previous update a few months ago, I did keep settings instead of doing a full factory reset.

This time I opted for a full factory reset, and for now, speeds are holding on at 1.7 Gbps over wifi, so lets see how it goes. I will monitor for a few days and confirm if it comes back, or if this reset solved it.

Thanks

17

Hi,

We checked the logs, but unfortunately there aren't many useful clues.

Could you please help us with the following?

  1. We forgot to ask previously: when the issue occurs, does it also affect the speed of devices connected via Ethernet?

  2. After the issue occurs, could you please follow the guide below and share your device with us via GoodCloud so that we can check it remotely?

    Technical Support via GoodCloud - GL.iNet Router Docs 4

    Kindly send us the MAC address and the router password via private message so that we can access the device.

18

It happened again, one of my devices got limited to 50 Mbps internet, others are fine at the moment. I don’t have devices plugged via ethernet.

Note that the limit is from internet to device over wifi.
I can download from internet to router at full speed.
I can download from router to device at full speed.
I get limited if I download from the internet via wifi, and this only happens after hours or in this case, a couple of days.

Not sure about giving access for remote access, because I am actively using it, so I need to reboot it. But I can make a full backup and share it to you, if that is alright.

Otherwise, I can ship it to you and you can run tests.

19

there is something you can try, ironically it is something I had yesterday.

have you tried a different cable?, I know that you have said there is no error, but sometimes a bad cable only goes bad at negotiation rather than creating packet errors, this is also called port flapping.

yesterday I was cappped at 100M and my unifi switch aswell, but this only happened once I replaced a cable to my isp fiber mediabox with faulty ez rj45 plugs even though it was working flawless, when done a completely different place this new issue got appeared.

then I instantly backtraced a other bunch of cables and figured I forgot those too, over wifi I had a similar 50mbps due to overhead.

if you did not tried this, please do :slight_smile:

1 Like
20

Getting exactly 50mbps does draw suspicion towards the cable negotiating at 100mbps or a faulty qos setting somewhere.

1 Like
21

Thanks, but unlikely to be the cable (cat 7), because as I said,

Internet to router 1+ Gbps
Router to device is wifi, not cable, also 1+ Gbps.
It’s only internet to device via wifi that becomes 50 Mbps (speedtest), but speed is negotiated at 2.4 Gbps.

If it was the cable, then router wouldn’t be able to download stuff directly, or other devices at over 1+ Gbps. This is definitely some bug on mediatek drivers or firmware somewhere.

I have a travel GL-AXT1800, no issues whatsoever.

The only thing left testing for me, is to reduce wifi frequency from 160 Mhz to 80 Mhz and see if it makes a difference.