I installed OpenWrt 24.10.0-rc4 on my mt2500a. It runs, but SpeedTest is slow -- about 10% of what I see with GL.iNet's firmware. Capped around 35 mbps, whereas my connection routinely gets over 300 mbps. Any ideas?
p.s. I found this with a previous snapshot release, too -- it does not seem to be specific to this particular release.
It's working fine on OpenWrt 24.10.0-rc5
Thank you for those that are testing the MT2500. I want this router but have been waiting for it to be included in a stable OpenWrt release.
Regarding rc5 working fine but rc4 and previous releases having problems, I didn't notice any changes in the changelog that would explain the improvement.
I wonder if the problems people have been seeing here are related to the many cases of bricked/dead MT2500s reported in the GL-iNet forum, which GL-iNet think might be a hardware problem (see link below).
This happened to me but on a NanoPi R5C, now it’s a brick because it doesn’t even turn any led on, I was running the latest snapshot and it suddenly died after a few days, I didn’t even changed any settings when it happened, my MT2500 has been working fine.
I did some testing with my MT2500 and OpenWrt 24.10.1 and unfortunately still has the same issue with the packet loss on the WAN port that @mhuellwegen already mentioned.
There is one thing I’d like to add though. In my case I had connected that MT2500 WAN port to a mikrotik switch. In the statistics the switch reported frequent ethernet packages with RX FCS Errors (received frames with incorrect checksum) Furthermore, there were a lot of fragmented frames (ethernet frame level, not fragmented on IP level). Both only occurred on the MT2500 WAN -> mikrotik switch upstream connection. The LAN port was working fine. I switched ports and cables, but in any case the same output, so it looks the MT2500 WAN port is the culprid.
There's potentially a MT2500A V2, awaiting GL staff to confirm
han@han-B85M-D2V-SI:~/build/openwrt-m-mt2500$ cat .config|grep 8811
CONFIG_PACKAGE_airoha-en8811h-firmware=y
CONFIG_PACKAGE_kmod-phy-airoha-en8811h=y
I am getting similar errors on my Brume 2 with the 2.5Gbit port plugged into a UniFi US-8 switch. I have the alloy case model (GL-MT2500A) but the thermal_zone0 sensor is reporting no higher than 41 C.
I have switched my LAN and WAN ports around so the 2.5Gbit (eth0) is for LAN.
Running iperf3 client on the router to another LAN host gives a low bitrate with lots of TCP retries:
[ ID] Interval Transfer Bitrate Retr
[ 5] 0.00-10.00 sec 45.6 MBytes 38.3 Mbits/sec 1804 sender
[ 5] 0.00-10.00 sec 45.1 MBytes 37.8 Mbits/sec receiver
In UDP mode it has lots of loss even when at 1Mbit (higher speeds have higher loss):
[ ID] Interval Transfer Bitrate Jitter Lost/Total Datagrams
[ 5] 0.00-10.00 sec 1.19 MBytes 1.00 Mbits/sec 0.000 ms 0/864 (0%) sender
[ 5] 0.00-10.00 sec 1.14 MBytes 954 Kbits/sec 0.095 ms 40/864 (4.6%) receiver
When I first used this router (mid January) it was great, this issue has only just started happening the last few days.
I've tried a new cable and changed to a different port on the switch but neither of these changes made any difference.
I am still running OpenWrt 24.10.0-rc5 but the router was previously functioning well on this release.
The 1Gbit port seems to continue to behave well, running speedtest-cli from the router shows the full expected speed from my ISP, and is abysmal when routing traffic to/from the 2.5Gbit port.
Some more data points:
I then thought the system was fixed as it was exhibiting no symptoms, but then as the system reached 40 degrees again the issue came back. I'm not saying the heat is the cause of the problem but it an interesting correlation.
With other words, its not really an option to flash it with openwrt at all ?
Plugging directly into my laptop and bypassing the UniFi US-8 switch still has the same outcome, so I don’t think the switch is the issue.
I can confirm there are MT2500A units with the Airoha EN8811H. I purchased one off Amazon a few days ago and it has that PHY.
root@GL-MT2500:/sys/devices/platform/15100000.ethernet/mdio_bus/mdio-bus/mdio-bus:05# ls -l
lrwxrwxrwx 1 root root 0 Mar 28 01:56 driver -> ../../../../../../bus/mdio_bus/drivers/Airoha EN8811H
lrwxrwxrwx 1 root root 0 Mar 28 01:56 of_node -> ../../../../../../firmware/devicetree/base/ethernet@15100000/mdio-bus/phy@5
-r--r--r-- 1 root root 4096 Mar 28 01:56 phy_has_fixups
-r--r--r-- 1 root root 4096 Mar 28 01:56 phy_id
-r--r--r-- 1 root root 4096 Mar 28 01:56 phy_interface
drwxr-xr-x 2 root root 0 Mar 28 01:56 power
lrwxrwxrwx 1 root root 0 Mar 28 01:56 subsystem -> ../../../../../../bus/mdio_bus
-rw-r--r-- 1 root root 4096 Mar 28 01:56 uevent
It does live at reg = <0x0d> according to initialization kernel log messages by the PHY driver.
[ 2.812362] Airoha EN8811H mdio-bus:05: PHY(0xd) = 3a2 - a411
[ 2.818523] Airoha EN8811H mdio-bus:05: Bootmode: Download Code
[ 2.840144] Airoha EN8811H mdio-bus:05: EthMD32.dm.bin: crc32=0x9658cbc2
[ 3.100840] Airoha EN8811H mdio-bus:05: EthMD32.DSP.bin: crc32=0xca79d6c4
[ 5.269504] Airoha EN8811H mdio-bus:05: EN8811H PHY ready!
[ 5.275443] Airoha EN8811H mdio-bus:05: en8811h_of_init: start
[ 5.281865] Airoha EN8811H mdio-bus:05: Tx, Rx Polarity : 01a01501
[ 5.288234] Airoha EN8811H mdio-bus:05: MD32 FW Version : 24030702
[ 5.294404] Airoha EN8811H mdio-bus:05: Surge Protection Mode - 0R
[ 5.302788] Airoha EN8811H mdio-bus:05: LED initialize OK !
[ 5.308353] Airoha EN8811H mdio-bus:05: EN8811H initialize OK! (v1.2.5)
I applied the DTS change from https://forum.gl-inet.com/t/gl-mt2500a-wan-issues-openwrt/57835/2 and included the firmware and PHY driver packages. With those changes and packages, I do see the PHY under OpenWrt.
[ 21.175497] mtk_soc_eth 15100000.ethernet eth0: PHY [mdio-bus:0d] driver [Airoha EN8811H] (irq=POLL)
[ 21.184684] mtk_soc_eth 15100000.ethernet eth0: configuring for phy/2500base-x link mode
any chance you can make a pull request:
https://github.com/openwrt/openwrt/pulls
How would V1 hardware be handled? V1 hardware has the WAN Ethernet PHY at register 0x5 rather than 0xd.
Should I submit a WIP PR and let the maintainers decide how to work this out in the comments?
Best to do that, maintainers will advise how's best to proceed
I submitted the draft PR. Thank you for the encouragement.
Asked in the pull request, but will post here as well for possible additional insight. Is there any way to identify externally which PHY a particular device is using? For example is there a difference in the model identifier on the label and/or a serial number range that would indicate which PHY is used? If there is a way to externally identify which PHY is used they should be treated as two different devices with separate PHY, DTS file and image.
Is it worth demarking as Maxlinear and Airoha variants, instead of V1 and V2?
@walterwhite4 I know you own a Brume 2, can I check with you on external details that differentiate it from the newer Airoha model.
I don't have and don't feel like making a Github account right now, but I have an original-version MT2500A.
The model number is simply GL-MT2500A.
As mentioned in the PR thread, it appears that the last 5 digits of the Device ID match the last five digits of the factory MAC address.
The first two digits of my Device ID are cn.
The UPC on the box is X003KR7ZJ5.
My serial number is 9de8db71676993d9.
The box and device sticker are marked with the CE, FCC, UKCA, and IC standards labels.
Hopefully these are of some use for identifying the revision.
I'm not sure, but I think i also have an original-version MT2500A purchased a year ago from Amazon.es.
I'm willing to put my unit at the service of this community. If anyone would like me to run any tests using my device, I'm available.
If a build environment is required for this, I'd appreciate help building one in VirtualBox.
Regards
Juan Belmonte