Sounds like you're using Snapshot?
Have you tried 24.10.0-rc2? I'm not sure if it will resolve the issue, but worth testing:
https://firmware-selector.openwrt.org/?version=24.10.0-rc2&target=mediatek%2Ffilogic&id=glinet_gl-mt2500
Have you tried 24.10.0-rc2
I can test that now.
Should I use the kernel or sysupgrade?
And is the trick with the power cycle and 5 second reset and flash via the internal U-Boot website the right way?
If you install from the standard GL-inet web interface (when normally booted) use the sysupgrade. Otherwise, I think you use the kernel if you use uboot.
I have tried 24.10.0-rc2 but with same result that i've a lot of packet loss on the 2.5 gbit WAN port.
It does sound like it could be a driver issue, then. Hopefully others can chime in regarding possible fixes.
Yes, I hope, or that someone can confirm that it works perfectly for him
on his gl.inet MT2500A with a plain firmware from openwrt.org
and not a pached/customized one from the manufacturer.
I also see on openwrt currently only the 24.10.0 rc2 and a snapshot firmware, not the openwrt version (21.0.2) the original manufacturer is using.
Many thanx for your help.
Regards.
That's because that device wasn't supported by the official OpenWrt project until relatively recently (post 23.05). GL-Inet's version of firmware is a customized fork of 21.02 and is not related to the official OpenWrt project.
But they managed to get both ports working well 
.
I have just reinstalled the customized firmware from the manufacturer and both ports are working now again and I can continue to try out what I want to do with the device using luci and ssh.
Again many thanx four your time.
Regards,
Martin
They had to or they wouldn't have had a product to sell. They may have used closed-source/proprietary code to achieve it, although I cannot say for sure.
I'm happy to try 24.10.0-rc2 on mine as well to see how the WAN port behaves as I want to setup mine up as a Wireguard server. Problem (unrelated) with mine was that I couldn't install Luci-app-wireguard as it wasn't listed in the package manager as the other related Wireguard packages were.
1 Like
Yes... it changed to luci-proto-wireguard at some point in the past.... try that and you should be good.
1 Like
psherman, thanks for the info on luci-proto-wireguard. I'll give it a go.
mhuellwegen, here's the update on my testing on the WAN port.
Flashed 24.10.0-rc2 sysupgrade bin directly from the GL.inet upgrade page, do not keep settings. Flash worked, GL-MT2500A rebooted fine and OpenWrt page loaded right up on 192.168.1.1. GL-MT2500A WAN port connected to my high speed internet LAN port. My Windows 11 laptop's ethernet (via USB-C) connected to the GL-MT2500A LAN port. I generated a 10GB text file from Windows command line and uploaded to Google Drive via browser. It estimated around 12 minutes to complete and it did complete successfully in approximately that time (I just eyeballed that). I did run task manager during the upload and watch the LAN connection graph. Send speed on the interface was 167 Mbps and consistently every maybe 30 seconds it would dip down to about 115 Mbps and the Google Drive progress ring would briefly change to an "X" and the progress ring would disappear. It would quickly recover and continue the transfer. So... I'm not sure if those are the same issues you have with the WAN port or if there's something else you'd like me to try to make it more like your test case - but that was my experience. Hope this helps.
1 Like
Anyone got a 2.5GB or faster switch, the easiest way to prove the WAN port would be to put it behind a switch and a local network and try to retrieve a big file from a NAS, to it's 8GB EMMC.
So a Linux DVD iso for example
most of what you've written also applies to my experiences.
In fact even more extreme, as small pings also could not even get 100% through WAN port to my local router when using 24.10.0-rc2 on the MT2500A and 2.5 Gbit port as WAN port to local gateway. This means I've a loss of packages every 5 - 10 secs.
But i will do some more testing on friday since I have some more MT2500As here.
However, I have also noticed that I don't have these problems with the manufacturer's firmware.
Perhaps once more the question for the experts: Do I need to install a special driver for the 2.5 Gbit WAN port @ MT2500A (Brumme 2) when using the 24.10.0-rc2 or other plain versions of OpenWrt?
2.5Gbit WAN port is a 2500Base-T WAN (MaxLinear GPY211C)
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=12396686484a488dff1c4a1ee8b5197c552572fe
Same issues would surely show up with:
GL-iNet MT3000
Acer Predator W6
Asus TUF AX6000
Asus TUF AX4200
Mercusys MR90X
Zyxel EX5700
Zyxel EX5601
Zyxel NWA50AX
I cannot see any threads about these other devices having issues with WAN throughput and 24.10 rc2, so while we wait, can you check dmesg for anything unusual, for example is the alternate GPT header missing?
Given this, if I had no need for speeds above 1Gbbps and no need for two network interfaces in my application (e.g. setting up the GL-MT2500A as a Wireguard server inside existing LAN and port forwarding), I'm assuming that I should be fine to swap the ports inside OpenWrt to use the 1Gbps port as my WAN port. Does that sound like it should work fine?
That will work fine
During my many tests, I swapped WAN 2.5G and ETH 1.0G once, which was no problem and no longer caused any problems, including no loss of ping packets to the uplink router.
But please also read my next reply as well...
@All: Thank you for your replies.
I did flash once more the OpenWrt RC2 firmware bin 1 h ago and did something different this time:
While now using my well running MT2500A with the original manufacturer's firmware in bridge mode, this time I used the “Reset to factory defaults” option on the gl.inet UI.
After that, my MT2500A started as I used the device for the 1st time and also greeted me with the gl.inet UI and in routing mode on 192.168.8.1.
I then flashed (as suggested by Kilianos709) “24.10.0-rc2 sysupgrade bin” directly from the GL.inet upgrade page on my "problematic" MT2500A (without keeping any settings and now without holding the reset button for more than 5 seconds to get a very simple flash firmware page from "u-boot, I think ?").
This time I got a success message after uploading the bin file from the gl.inet UI, which was the first time I noticed this success message, and I started the sysupgrade process.
After 2-3 minutes I had a good running MT2500A with LuCI as UI and no password as default on 192.168.1.1 (as expected) 
So, YES, there is a way to successfully upgrade a MT2500A to “24.10.0-rc2”.
But now my question to the experts: What whent wrong on the other ways I used to flash my MT2500A before?
And in fact I'll actually wanted to flash a more plain OpenWrt onto my device, so I did NOT used the sysupgrade and the something bigger "24.10.0-rc2" bin before, but the snapshot file from OpenWrt without LuCI.
While successfully flashing the firmware I ran into the 2.5G problem.
And also flashing the "24.10.0-rc2" bin behind my puristic snapshot install did not fix the 2.5G problem on my device (I think).
Only the complete re-flashing the gl.inet firmware, reset to default and flashing the RC2 behind using the gl.inet UI on the device ends for me in a successfull upgrade.
Any ideas about that?
Okay, just rejoiced a little too soon...
After some time I noticed the problem again:
PING 192.168.0.1 (192.168.0.1): 56 data bytes
64 bytes from 192.168.0.1: seq=0 ttl=64 time=1.034 ms
64 bytes from 192.168.0.1: seq=3 ttl=64 time=0.502 ms
--- 192.168.0.1 ping statistics ---
5 packets transmitted, 2 packets received, 60% packet loss
round-trip min/avg/max = 0.502/0.768/1.034 MS
from the LuCI ping diagnostic menu command via WAN 2.5G to uplink router.
And this time I also called the dmesg command (as you, @ hecatae recommended) with this results:
[ 1.132247] GPT:Primary header thinks Alt. header is not at the end of the disk.
[ 1.139666] GPT:1 != 15269887
[ 1.142623] GPT:Alternate GPT header not at the end of the disk.
[ 1.148643] GPT:1 != 15269887
[ 1.151599] GPT: Use GNU Parted to correct GPT errors.
From my point of view, this has nothing to do with the Ethernet ports, but since you specifically asked about it @ hecatae... There are these entries in conjunction with the "GPT header missing" you asked for, when calling dmesg.
Any ideas about this?