GL-MT6000 - Massive PPPoE performance regression on OpenWrt 25 firmware (TIM FTTH 2.5 Gbps)

Router
1

Hi,

I think I found a significant performance regression on the GL-MT6000 between the old SDK4 firmware and the new OpenWrt 25 based firmware.

Hardware

  • Router: GL.iNet GL-MT6000 (Flint 2)

  • WAN: 2.5GbE

  • ISP: TIM Italy FTTH

  • Connection: PPPoE + VLAN 835

  • ONT: External ONT (2.5GbE)

Expected performance

With the previous GL.iNet firmware based on OpenWrt 21 (SDK4 / MediaTek HNAT), I consistently get:

  • Download: 2200-2250 Mbps

  • Upload: 950-980 Mbps

The exact same hardware, cables, ONT and ISP have been used.

Problem

After upgrading to the latest GL.iNet firmware based on OpenWrt 25:



OpenWrt 25.12.5
Kernel 6.12.94
mediatek/filogic

download speed drops to:

  • Download: 1250-1270 Mbps

  • Upload: 950-980 Mbps

Upload remains normal while download is almost cut in half.

The speed is extremely consistent (~1260 Mbps), regardless of the Speedtest server.

Tests already performed

WAN link



ethtool eth1

Speed: 2500Mb/s
Duplex: Full
Link detected: yes

PPPoE

Running on VLAN 835.

Hardware acceleration

Hardware Flow Offloading enabled.

PPE is active:



cat /sys/kernel/debug/ppe0/bind

returns multiple active BND entries during traffic.

Speedtest

Tested with:

  • LuCI NetSpeedTest

  • Official Ookla CLI

Both produce the same result:



Download: ~1260 Mbps
Upload: ~970 Mbps

CPU

Router is not CPU limited.

Downgrade test

Downgrading back to the previous GL.iNet firmware (SDK4 / OpenWrt 21) immediately restores full speed:



Download: ~2200 Mbps
Upload: ~970 Mbps

No other configuration changes were made.

Old firmware information



OpenWrt 21.02-SNAPSHOT
Kernel 5.4.238
Target: mediatek/mt7986

Kernel modules include:



mtkhnat
mtk_warp
mt_wifi

HNAT initialization:



mediatek_soc_hnat
PPE0 hwnat start

New firmware information



OpenWrt 25.12.5
Kernel 6.12.94
Target: mediatek/filogic

PPE is active and binds are correctly created, but download throughput is limited to approximately 1.26 Gbps.

Conclusion

Since:

  • the same router,

  • the same ONT,

  • the same ISP,

  • the same PPPoE credentials,

  • the same Ethernet cable,

all return to full 2.2 Gbps simply by downgrading the firmware, this looks like a regression introduced somewhere between the SDK4 (HNAT) implementation and the new OpenWrt 25 based firmware.

Has anyone observed similar PPPoE performance degradation on MT6000 / MT7986 with the new firmware?

If needed, I can provide:

  • full dmesg

  • ethtool

  • ip link

  • ppe0/bind

  • uci export network

  • additional benchmarks.

Can you please let me know if full speed will be restored on new branches?
Thanks!

2

Hi,

It sounds like this may be due to the difference between the proprietary driver and the open-source driver.

If you have a chance, could you try the following?

  1. Does this issue also occur on the OP24 firmware?
  2. What about with a vanilla OpenWrt installation?
4

Hi Will,

thanks for your reply:

  1. Yes, issue also occur with the OP24 firmware, I noticed when I tried to use OP24.

  2. I never tried with a vanilla OpenWrt, I'm lazy and I like the GUI from Gl.iNet

let me know if you think can be useful try with a vanilla, but I think that need to be fixed also in the official Gl.Inet release no?

You didn’t thought to implement the proprietary drivers in OP/2425? It’s in plan?

5

Hi,

If the issue occurs on both OP24 and OP25, but not on the stock firmware, then it is most likely caused by the difference between the open-source and proprietary drivers.

If you're willing, you could also test with a vanilla OpenWrt installation to further confirm this.

Since the open-source drivers is maintained by the upstream OpenWrt community, we may not be able to provide much assistance in this case. We recommend reaching out to the active OpenWrt community for further support.

The proprietary driver depends on the vendor-provided SDK and we may not be able to integrate it into the OP24/OP25 builds.

6

Thanks for your reply.

I performed additional testing to isolate the issue.

Test setup:

  • Router: GL.iNet GL-MT6000 (MT7986)

  • WAN: TIM FTTH 2.5 Gbps

  • PPPoE over VLAN 835

  • ONT connected directly to the 2.5G WAN port

  • Ookla CLI using the same TIM Milan server

Results:

  • GL.iNet SDK4 firmware (OpenWrt 21): ~2200 Mbps download

  • GL.iNet OP25 firmware: ~1260 Mbps download

  • Vanilla OpenWrt 25.12.5: ~1490 Mbps download

On the SDK4 firmware:

  • mtkhnat / WARP modules are loaded

  • mediatek_soc_hnat initializes correctly

  • /sys/kernel/debug/ppe0/bind is populated during traffic

On vanilla OpenWrt 25:

  • no mtkhnat module is present

  • only nf_flow_table / nft_flow_offload are loaded

  • /sys/kernel/debug/ppe0/bind always remains empty, even during an active speedtest

Therefore the difference seems consistent with the proprietary MediaTek HNAT implementation versus the upstream networking stack.

However, one thing is still interesting:

Vanilla OpenWrt reaches ~1490 Mbps while GL.iNet OP25 only reaches ~1260 Mbps under the exact same conditions.

Is there any known reason why OP25 performs noticeably worse than vanilla OpenWrt?

7

At the moment, we're not sure why there is a performance difference between OP25 and vanilla OpenWrt.

In theory, they should be using the same driver, so we would expect their performance to be very similar. We'll ask our team to investigate this internally.

In the meantime, would you have a chance to compare the performance of GL OP24 and vanilla OpenWrt (based on OpenWrt 24) as well?

We'd like to determine whether the difference was introduced after integrating the GL SDK into vanilla OpenWrt, or whether it's related to our OP25 adaptation.

8

Hi,

We've made some adjustments and built a new op25 test firmware, which we'll send to you via private message.

Could you please give it a try and let us know whether there is still a performance gap compared to vanilla OpenWrt?