• Device
  • Specifications
  • Hardware
  • Identification
• Installation
  • Status
• LTE
• Advanced LTE
• Dedicated OpenWrt Build
• Failsafe
• Reverting to OEM firmware
• (Somewhat of a) conclusion

Ever since I got this router I encountered connection stability issues (well reported on the Tp-Link forums here, here, here, here...), so as soon as I took it apart and discovered it uses an OpenWrt supported platform (MT7621 / mipsel_24kc) I searched for a way to bring OpenWrt on it (and hopefully resolve the disconnection issues, or at least find a better workaround than scheduled daily router reboots).

The MR500 v1 (EU) is identical on first look with its (already supported) brother MR600v2 but uses a different (cheaper) LTE modem.

MR600v2 photo thanks to kernelpanic1

• SoC: Mediatek MT7621DAT 880MHz
• RAM: 128MB DDR3
• Flash: 16MB SPI NOR flash (EN25)QH128A-104HIP
• LTE Modem: Fibocom FG621-EA
• WiFi 5GHz: Mediatek MT7613BEN
• WiFi 2.4GHz: Mediatek MT7603EN
• Ethernet: MT7530, 4x 1000Mbps
• UART: Serial console (115200 8n1) @ J1
• Buttons: Reset, WPS.
• LED: Power, WAN, 4G+, single WiFi, LAN, Signal1, Signal2, Signal3

Board photos: front, back, serial pins.

# lspci
00:00.0 PCI bridge: Device 0e8d:0801 (rev 01)
00:01.0 PCI bridge: Device 0e8d:0801 (rev 01)
01:00.0 Network controller: MEDIATEK Corp. MT7603E 802.11bgn PCI Express Wireless Network Adapter
02:00.0 Unclassified device [0002]: MEDIATEK Corp. Device 7663

# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux 6.6.67 xhci-hcd xHCI Host Controller
Bus 001 Device 002: ID 2cb7:0a05 Fibocom FG621 Module
Bus 002 Device 001: ID 1d6b:0003 Linux 6.6.67 xhci-hcd xHCI Host Controller

Since Tp-Link really enjoys versioning out their devices and mix-matching the hardware used in them, it's necessary to identify your device properly.

Software signatures:

Hardware label:

My device came with operator-specific firmware, hence the (ROORG) designation.

1. Start a TFTP server - Tftpd64 will do just fine.

Configure the computer's network adapter and the TFTP server to listen on 192.168.0.5/24. Connect to the router using one of the 3 LAN ports (preferably LAN1 since that's the only one active in OpenWrt's failsafe mode, if needed).

2. Download the MR600v2 OpenWrt initramfs (kernel) image from the OpenWrt Firmware Selector (either 23.05.x or 24.10.x will do)

Place it into the TFTP server's root directory and rename it to test.bin

3. Connect to the router's serial console with a USB/UART adapter.

Attach power and interrupt the U-Boot boot process by quickly pressing 4 or typing tpl at the correct moment (see below).

U-Boot 1.1.3 (Nov 22 2023 - 16:37:42)

Board: Ralink APSoC DRAM:  128 MB
relocate_code Pointer at: 87fa0000

Config XHCI 40M PLL
******************************
Software System Reset Occurred
******************************
flash manufacture id: 1c, device id 70 18
find flash: EN25QH128A
*** Warning - bad CRC, using default environment

============================================
Ralink UBoot Version: 5.0.0.0
--------------------------------------------
ASIC MT7621A DualCore (MAC to MT7530 Mode)
DRAM_CONF_FROM: Auto-Detection
DRAM_TYPE: DDR3
DRAM bus: 16 bit
Xtal Mode=3 OCP Ratio=1/3
Flash component: SPI Flash
Date:Nov 22 2023  Time:16:37:42
============================================
icache: sets:256, ways:4, linesz:32 ,total:32768
dcache: sets:256, ways:4, linesz:32 ,total:32768

 ##### The CPU freq = 880 MHZ ####
 estimate memory size =128 Mbytes
#Reset_MT7530
set LAN/WAN WLLLL                                                             

				 <--- around here press 4 or type 'tpl' quickly

4: System Enter Boot Command Line Interface.

U-Boot 1.1.3 (Nov 22 2023 - 16:37:42)
MT7621 #

The default U-Boot menu is hidden (and quickly bypassed) but still partially available by pressing the corresponding number keys at the proper time:

1: System Load Linux to SDRAM via TFTP.
2: System Load Linux Kernel then write to Flash via TFTP.
3: System Boot system code via Flash.
4: System Enter Boot Command Line Interface. <--- triggered by the 'tpl' prompt

4. Transfer the firmware through TFTP and then instruct U-Boot to boot OpenWrt from ram:

# tftpboot

...transfer happens here...

# bootm

The router will boot the kernel image and start OpenWrt in recovery mode.

5. With OpenWrt booted in recovery (initramfs) mode, use the web interface or console to install the sysupgrade OpenWrt firmware (which you can also obtain from the ImageBuilder).

After another reboot you should find yourself in the permanently installed OpenWrt firmware.

What works:

• WAN and LAN 1-3 ports are correctly identified and work as expected.
• Both 2.4Ghz and 5Ghz wirelesses are recognized and appear functional (I didn't do throughput tests as I mostly focused on getting the mobile connection up and running, which provides nowhere near the wireless bandwidth capabilities).
• LEDs are all functional (and also configurable through LuCI):
  • Power, WAN, LAN and WIFI work out-of-the-box. The single WIFI led is attached to the 5Ghz wireless by default, but can be reassigned in LuCI.
  • The 4G+ led can be configured to indicate WWAN status (but no longer differentiates between 4G and 4G+ connectivity as with the retail firmware).
  • The mobile signal leds are a task for another day.
• Individual signal numbers seem in the correct range, but I have no exact method of confirming them.
• At least some of the LTE status info is confirmed correct (Operator, MCC, NMC, Cell ID, Primary band, Modem firmware model and version).
• Carrier aggregation and second band info works ((1), (2) (3)) with the patched 3ginfolite script.
  • Speeds are on par with another MT7621-based router running a Qualcomm EM12 modem placed side by side and on the same mobile operators and identical data plans and similar to mobile phones tested in the same location.

What doesn't work:

• So far everything seems to work for basic functionality. Advanced LTE monitoring and band selection require additional steps as described below.
  • Secondary band functionality and reporting need to be tested with a CA-capable SIM/operator.
  • 3ginfo status page can fail randomly if being left open and refreshing for a while. Force refreshing or logging out of LuCI and logging back in seems to return it to functioning order. I assume either the modem is slow to respond or randomly returns unexpected or garbage data. The status page will be empty or garbled if 3ginfo data collection overlaps the LEDs status script (provided below).
• Stability improvements remain to be tested... Watchcat can handle the modem restarts if it misbehaves like with the official firmware.
• With some OpenWrt releases (24.x ?) the router may experience random freeze on boot after power failures / cold boots. Investigating the serial console shows that it does complete the boot but the network subsystem is completely non-functional. Link status messages are displayed in the console but running ifconfig or service network restart results in multiple Command failed: Request timed out errors and no result.
• As of April 2026 the wrong offset for the radio (mtd7) partition affecting the original MR600 hasn't been fixed. The (clean or customized) MR600 images will try to use wireless calibration data from the wrong location, which results in low performance for 2.4Ghz and very low power (barely usable) for 5GHz. Restoring the (wrong) "radio" partition with this binary (or my local copy) fixes the problem. The router's original radio data (found at the different location in flash) remains intact for when OpenWrt will correct the offset or for returning to the TP-Link OEM firmware.

Installing packages requires a functional uplink (wired WAN can be used for the next steps)

For RNDIS mode use the package manager to install

kmod-usb-net-rndis

For NCM mode install

luci-proto-ncm

Which will in turn also install required dependencies:

chat
comgt
kmod-usb-serial
kmod-usb-serial-wwan
kmod-usb-serial-option
kmod-usb-net-cdc-ether
kmod-usb-net-cdc-ncm
kmod-usb-net-huawei-cdc-ncm
comgt-ncm

Reboot the router. After the reboot there is a new network device usb0 or eth1 (depending on NCM / RNDIS) available.

Use LuCI to delete or edit the pre-configured wwan0.
Create/edit the wwan0 interface with protocol DHCP and attach it to the new usb0 or eth1 device. Or do this manually in /etc/config/network:

config interface 'wwan0'
	option proto 'dhcp'
	option device 'usb0'

The modem should automatically work out the required APN from the SIM/network (at least it did for me - but I had it configured and working with this network operator in the official firmware before so that may play a part).
To see the existing APN/PDP configuration, the AT+CGDCONT? AT command in picocom /dev/ttyUSB0 can be used.

At this point the mobile connection should be up and running (check if the wwan0 interface receives an IP address from the ISP, usually in the 10.x.x.x range). This process may take up to several minutes after a (re)boot or a modem restart.

For signal monitoring and band selection/locking 4IceG's awesome luci-app-3ginfo-lite and luci-app-modemband will do miracles.
However, the Fibocom modem is not supported in the current builds (as of April 2026) and will require some manual tinkering.

The install processes for both are best described in their respective repos, but for convenience I have included the versions I successfully tested and modded in the lte-advanced/ folder on this repo (in the appropriately numbered order). Download and use random files off the internet at your discretion.

In the same folder are also the necessary changed and new files that are required for modem support.

On this modem /dev/ttyUSB0 is the AT commands interface.

1. Install the appropriate architecture sms-tool package.

2. Install luci-app-3ginfo-lite package.

Force refresh or logout/login to LuCI and navigate to the Modem > Information ... submenu.
Switch to the Configuration tab and set:

• Interface option to wwan0
• Port for modem to /dev/ttyUSB0

Save and Apply.

You'll notice there is still no information on the Details tab (or even a message about a missing modem at the top of the screen).

3. Patch /usr/share/3ginfo-lite/3ginfo.sh with these changes.

4. Inside the /usr/share/3ginfo-lite/modem/ subfolder create a new file 2cb70a05 (the VID/PID of the modem) with this content, or from the console run:

   wget -O /usr/share/3ginfo-lite/modem/usb/2cb70a05 https://raw.githubusercontent.com/thezedt/mr500v1-openwrt/refs/heads/main/lte-advanced/usr_share/3ginfolite/modem/usb/2cb70a05

Once both files are edited/created successfully, the details should finally be displayed in LuCI after a refresh.

1. Install the modemband apk.

2. Install luci-app-modemband apk.

Force refresh or logout/login to LuCI and navigate to the Modem > Prefered Bands submenu.
Switch to the Configuration tab and set:

• Interface option to wwan0
• Port for modem to /dev/ttyUSB0

If you choose to enable modem restart after bands change, to ensure successful change adjust the preset restart command to:

AT+CFUN=15

Save and Apply.

You'll notice an error message and lack of information on the Preferred LTE bands tab.

3. Use SCP or the console to explore the router's filesystem and navigate to /usr/share/modemband/. Inside create a new file called 2cb70a05 (the VID/PID of the modem) with this content, or from the console run:

   wget -O /usr/share/modemband/2cb70a05 https://raw.githubusercontent.com/thezedt/mr500v1-openwrt/refs/heads/main/lte-advanced/usr_share/modemband/2cb70a05

Complete modem initialization after a band change can take up to several minutes, so be patient if the information pages don't work for a while (even if the mobile connection is working).

Probably starting from this script, it can be adapted to read signal level with AT commands instead of (unavailable) uqmi. 3ginfo-lite should be able to provide the inspiration for this.

The defaults script detailed below creates the necessary LED handling and gcom helper scripts and cron job that update signal and 4G+ LEDs according to current conditions.

Customize the packages list to:

apk-mbedtls base-files ca-bundle dnsmasq dropbear firewall4 fstools kmod-crypto-hw-eip93 kmod-gpio-button-hotplug kmod-leds-gpio kmod-nft-offload libc libgcc libustream-mbedtls logd mtd netifd nftables odhcp6c odhcpd-ipv6only ppp ppp-mod-pppoe procd-ujail uboot-envtools uci uclient-fetch urandom-seed urngd wpad-basic-mbedtls kmod-mt7603 kmod-mt7615e kmod-mt7663-firmware-ap kmod-usb3 -uboot-envtools luci kmod-usb-serial-option kmod-usb-net-cdc-ncm luci-proto-ncm comgt comgt-ncm

Packages marked in bold are the extra ones needed. Remove the existing qmi packages (kmod-usb-net-qmi-wwan, uqmi and luci-proto-qmi) to save some flash space for future use. With OpenWrt 25.12 and newer luci-app-attendedsysupgrade should also be removed as the attended sysupgrade would (re)install a non-customized MR600 image.

Use the first boot (uci-defaults) script below for minimal interface configuration:

uci set network.wwan0=interface
uci set network.wwan0.proto='dhcp'
uci set network.wwan0.device='usb0'
uci commit network

Or use the advanced uci-defaults script for advanced pre-configuration of a sysupgrade image that:

• tweaks the device name and default hostname to TL-MR500v1
• configures the correct interface for the modem's WWAN
• configures wireless SSIDs and enables (password-less!) wireless functionality
• configures interface LEDs
• adds helper script and cron job to handle the extra 4G+ and signal LEDs functionality

Download the custom generated sysupgrade image and use it to flash the router at the second step (or later as an upgrade). The builder does not generate a custom kernel image so you'll need to rely on the default MR600 kernel image for the initial TFTP boot.

If you need to boot the MR500 in failsafe mode, press the Reset/WPS button once or twice while the power led is blinking quickly after power-on. After a few seconds the led should start blinking even faster.

Plug the network cable into the LAN1 port as that is the only one active in failsafe mode and connect to 192.168.1.1 via SSH.

My device (supplied with custom ISP firmware) doesn't appear to support TFTP recovery by pressing any of the buttons (WPS/Reset or Wifi On/Off) at power-on.

If you ever want to revert back to the Tp-Link firmware, reset the modem mode back to RNDIS and disable autoconnect beforehand:

AT+GTAUTOCONNECT=0

AT+GTRNDIS=0

AT+GTUSBMODE=38

If you have perhaps enabled IP (by)pass to prevent double NAT under OpenWrt (like me), remember to also undo that. Check status and reset to 0 (default) if necessary:

AT+GTIPPASS?

AT+GTIPPASS=0

Finally restart the modem to apply changes:

AT+CFUN=15

You can then use the recovery image I prepared (or make your own) to flash directly from within LuCI (use the force option to bypass metadata check) or using mtd -r write /tmp/mr500v1_recovery_rel42593.bin firmware after copying the file over.

For those who have completely messed up their flash, I have also uploaded a full flash chip firmware dump of an OEM retail release (it's an older beta build that can be updated to a newer release). Keep in mind this contains device-specific information so I've removed my MAC address and IMEI in it. Use a hex editor and look for F0F1F2F3F4F5F6 at address 0xFCF100 and replace that with your MAC, and 001122334455667 at address 0xFCF500 with your IMEI (this is most likely used just for displaying in the administration interface).

• 17 days in, the router remains online, but carrier aggregation doesn't seem to kick in anymore (similar to what the router does with the official firmware). Restarting the modem with AT+CFUN=15 restores carrier aggregation and improves speed slightly.
• 25 days in, the router is still online, wwan lost connection and reconnected a couple of times (and reset its uptime) but didn't completely become unresponsive as with the default firmware (yet). One oddity is that the modem appears to do some kind of half NAT-ing of its own, with the wwan connection always using a gateway of 10.0.0.1 (which also appears as a hop in traffic). This doesn't happen on other routers with the same SIM/ISP. The LTE speed doesn't appear to degrade with uptime, varying mostly depending on time of day and network congestion.
• 100 days later, the router appears to work fine, although it doesn't have a 100 days uptime due to some power failures (and dataplan expiry). However, it didn't exhibit the failure mode I was experiencing with the OEM firmware (but that may be just due to the beta modem firmware it is running).
• Later note: Somehow I managed to lose the content of my device's mtd7 "radio" partition (and what else?) The OpenWrt build for MR600 uses the wrong offset for the radio (mtd7) partition and this applies to MR500 as well, which results in low performance for 2.4Ghz and very low power (barely usable) for 5GHz. I haven't noticed this until I actually tried to use the wirelesses while on decent LTE coverage. Restoring the "radio" partition with this binary restored full signal and speed for both radios (I was too lazy to extract the device's original radio data from the full flash backup dump. I might still do that at some later date).
• Aproximately 6 months later: The modem seems ot run fine with 2 of the 3 operators available in the area. One of the working operators does not provide Carrier Aggregation (4G+), while the other does (the one I also used for testing the OEM firmware). The modem eventually lost connection and required a reboot with a third operator (that also supports CA/4G+).
• Aproximately 8 months later: The router started randomly freezing on boot on power failures / cold boots. Investigating the serial console shows that it does complete the boot but the network subsystem is completely non-functional. Link status messages are displayed in the console but running ifconfig or service network restart results in multiple Command failed: Request timed out errors and no result. Additionally, at the times when it does boot fine it eventually starts experiencing out-of-memory errors (with various services on it getting killed by the kernel) and finally soft reboots. The memory crashes appear resolved after a clean update to OpenWrt 24.10.2. The random broken network on cold boot persists with 24.10.2.
  The modem stability seems to have improved either in time (thanks to the firmware update installed by the beta build) or thanks to OpenWrt management, however the random network issues on boot prevent me from using this device in remote locations where access over its LTE link is needed for management.
  So for now I have decided to revert back to the OEM firmware (which has received two new releases in the meantime, including one that changes the modem firmware - perhaps also resolving/improving the LTE stability) and plan to use this router as one of several uplinks for a more stable OpenWrt device that I can remote into using the (still functional) uplinks.
• Over 1 year later: I'm giving it another go with the current (25.12.2) OpenWrt release - so far none of the previously experienced issues returned.