Could you please share the output of MT7981> help
so we can analyze the available capabilities?
On the DXG21 we do have SSH access though?
MT7981> help
? - alias for 'help'
base - print or set address offset
bdinfo - print Board Info structure
blkcache - block cache diagnostics and control
boot - boot default, i.e., run 'bootcmd'
bootd - boot default, i.e., run 'bootcmd'
bootefi - Boots an EFI payload from memory
bootelf - Boot from an ELF image in memory
bootflow - Boot flows
booti - boot Linux kernel 'Image' format from memory
bootm - boot application image from memory
bootmenu - ANSI terminal bootmenu
bootp - boot image via network using BOOTP/TFTP protocol
bootvx - Boot vxWorks from an ELF image
cmp - memory compare
coninfo - print console devices and information
cp - memory copy
crc32 - checksum calculation
echo - echo args to console
editenv - edit environment variable
env - environment handling commands
erase - erase FLASH memory
fdt - flattened device tree utility commands
flinfo - print FLASH memory information
go - start application at address 'addr'
gpio - query and control gpio pins
gzwrite - unzip and write memory to block device
help - print command description/usage
iminfo - print header information for application image
imxtract - extract a part of a multi-image
itest - return true/false on integer compare
loadb - load binary file over serial line (kermit mode)
loads - load S-Record file over serial line
loadx - load binary file over serial line (xmodem mode)
loady - load binary file over serial line (ymodem mode)
loop - infinite loop on address range
lzmadec - lzma uncompress a memory region
md - memory display
mm - memory modify (auto-incrementing address)
mtd - MTD utils
mtkautoboot- Display MediaTek bootmenu
mtkboardboot- Boot MTK firmware
mtkload - MTK image loading utility
mtkupgrade- MTK firmware/bootloader upgrading utility
mw - memory write (fill)
nand - NAND utility
net - NET sub-system
nfs - boot image via network using NFS protocol
nm - memory modify (constant address)
nmbm - NMBM utility commands
panic - Panic with optional message
ping - send ICMP ECHO_REQUEST to network host
pinmux - show pin-controller muxing
printenv - print environment variables
protect - enable or disable FLASH write protection
pwm - control pwm channels
random - fill memory with random pattern
reset - Perform RESET of the CPU
run - run commands in an environment variable
saveenv - save environment variables to persistent storage
setenv - set environment variables
setexpr - set environment variable as the result of eval expression
sf - SPI flash sub-system
sleep - delay execution for some time
smc - Issue a Secure Monitor Call
source - run script from memory
tftpboot - boot image via network using TFTP protocol
unlz4 - lz4 uncompress a memory region
unzip - unzip a memory region
version - print monitor, compiler and linker version
MT7981>
Oh, I missed that SSH is available on non-OpenWrt firmware, so we can still try to find a way to upgrade without UART.
I've noticed that non-OpenWrt devices use an older version of U-Boot, while OpenWrt (ImmortalWrt) has a slightly newer U-Boot that's capable of web recovery/upgrade.
Could you check if recovery mode can be triggered on the older U-Boot version?
Here's how to test:
- Unplug the power cable
- While holding the mesh/WPS button, plug the power back in
- Monitor the UART console to see if a countdown is initiated
You can also try the same procedure with the reset button instead.
Because we have SSH access, we can see that the reason the image still shows as unsupported ("00's") is that the SUPPORTED_DEVICES
string doesn't include mediatek,mt7981-spim-snand-rfb
in RC1.0:
ssh dg@192.168.10.1
dg@192.168.10.1's password:
BusyBox v1.33.2 (2025-05-31 13:58:33 UTC) built-in shell (ash)
____ ____ _
| _ \ _ __ __ _ __ _ ___ _ __ / ___| | __ _ ___ ___
| | | | '__/ _` |/ _` |/ _ \| '_ \ | | _| |/ _` / __/ __|
| |_| | | | (_| | (_| | (_) | | | | | |_| | | (_| \__ \__ \
|____/|_| \__,_|\__, |\___/|_| |_| \____|_|\__,_|___/___/
|___/
----------------------------------------------------------
r17514-d3cff78755, r17514-d3cff78755
----------------------------------------------------------
PID=DGX21
BUILD_TYPE=debug
BUILD_NUMBER=local
BUILD_TIME=20250605-170902
BUILD_GIT_VERSION=d3cff787
----------------------------------------------------------
root@DGX21:~# sysupgrade -n /tmp/openwrt-mediatek-filogic-creatlentem_clt-r30b1-
squashfs-sysupgrade.bin
Wed Jun 4 23:41:31 IRKT 2025 upgrade: Device mediatek,mt7981-spim-snand-rfb not supported by this image
Wed Jun 4 23:41:31 IRKT 2025 upgrade: Supported devices: creatlentem,clt-r30b1 mediatek,mt7981-rfb
Image check failed.
root@DGX21:~#
I reckon if we put the string in, the GUI will have no problem flashing the image.
Because U-Boot is "unlocked" over UART and Iâve browsed its environment config, I can confidently say this DragonGlass platform will not TFTPBOOT automatically. In fact, itâs difficult to even interrupt U-Boot because it jumps straight into the vendor image almost immediately. If you insist, I can try it, but I donât like the odds.
Added mediatek,mt7981-spim-snand-rfb
and flashed via SSH, webui still didn't like the file though.
Could have just forced your image too I guess
user@workstation:~$ scp ~/Downloads/openwrt-mediatek-filogic-creatlentem_clt-r30b1-squashfs-sysupgrade.bin dg@192.168.10.1:/tmp/
dg@192.168.10.1's password: ivanlee
openwrt-mediatek-filogic-creatlentem_clt-r30b1-squashfs-sysupgrade.bin 100% 18MB 18.2MB/s 00:01
user@workstation:~$ ssh dg@192.168.10.1
dg@192.168.10.1's password: ivanlee
BusyBox v1.33.2 (2025-05-31 13:58:33 UTC) built-in shell (ash)
____ ____ _
| _ \ _ __ __ _ __ _ ___ _ __ / ___| | __ _ ___ ___
| | | | '__/ _` |/ _` |/ _ \| '_ \ | | _| |/ _` / __/ __|
| |_| | | | (_| | (_| | (_) | | | | | |_| | | (_| \__ \__ \
|____/|_| \__,_|\__, |\___/|_| |_| \____|_|\__,_|___/___/
|___/
----------------------------------------------------------
r17514-d3cff78755, r17514-d3cff78755
----------------------------------------------------------
PID=DGX21
BUILD_TYPE=debug
BUILD_NUMBER=local
BUILD_TIME=20250605-170902
BUILD_GIT_VERSION=d3cff787
----------------------------------------------------------
root@DGX21:~# sysupgrade -n /tmp/openwrt-mediatek-filogic-creatlentem_clt-r30b1-squashfs-sysupgrade.bin
Thu Jun 5 01:52:46 IRKT 2025 upgrade: Commencing upgrade. Closing all shell sessions.
Connection to 192.168.10.1 closed by remote host.
Connection to 192.168.10.1 closed.
user@workstation:~$ ssh root@192.168.1.1
The authenticity of host '192.168.1.1 (192.168.1.1)' can't be established.
ED25519 key fingerprint is SHA256:+XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.1.1' (ED25519) to the list of known hosts.
BusyBox v1.37.0 (2025-07-21 22:17:08 UTC) built-in shell (ash)
_______ ________ __
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -__| || | | || _|| _|
|_______|| __|_____|__|__||________||__| |____|
|__| W I R E L E S S F R E E D O M
-----------------------------------------------------
OpenWrt SNAPSHOT, r30511-8bb0dd8aa7
-----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
OpenWrt recently switched to the "apk" package manager!
OPKG Command APK Equivalent Description
------------------------------------------------------------------
opkg install <pkg> apk add <pkg> Install a package
opkg remove <pkg> apk del <pkg> Remove a package
opkg upgrade apk upgrade Upgrade all packages
opkg files <pkg> apk info -L <pkg> List package contents
opkg list-installed apk info List installed packages
opkg update apk update Update package lists
opkg search <pkg> apk search <pkg> Search for packages
------------------------------------------------------------------
For more https://openwrt.org/docs/guide-user/additional-software/opkg-to-apk-cheatsheet
root@OpenWrt:~#
I would respectfully suggest exploring recovery solutions that don't require UART access, as having such options would be beneficial for users who may not have the necessary hardware or technical setup.
That's a pretty cool achievement!
The web UI might be checking the filename. Did you see anything in the syslog after attempting the update?
Ran another test from the webui and looked around for some logs
Didn't pass "check version"
root@DGX21:/# cat /var/upgrade.log
main.c(141),<main>:==>start drop caches
main.c(145),<main>:==>success drop caches
main.c(148),<main>:==>start unpack file:/tmp/sysupgrade.bin ......
unpack.c(373),<unpack>:==>/tmp/sysupgrade.bin file size:19097938
main.c(155),<main>:==>success unpack
main.c(158),<main>:==>start check version......
check_version.c(87),<get_bin_fw_ver>:==>Failed to open file /tmp/tmp_fw_info
main.c(162),<main>:==>failed check version
main.c(198),<main>:==>main EXIT and return :1
Through the web UI, I was able to flash the image successfully. The version check passed and the log shows it wrote to bl2
, fip
, and firmware
:
root@DGX21:~# cat <<EOF > /tmp/tmp_fw_info
> "FW_VER" "0.0.0.2"
> "REQ_VER" "0.0.0.1"
> "HW_ID" "36b0d8b1ee52c282284e2c758717f559"
> "48ed5d2db39237d7ae5e829b17581629" "PRODUCT_ID"
> EOF
root@DGX21:~#
root@DGX21:~# cat <<EOF > /tmp/tmp_ow_info
> "DG_VER" "DXG21"
> "AU" "RETAIL_REGION"
> EOF
root@DGX21:~# cat /tmp/upgrade.log
main.c(141),<main>:==>start drop caches
main.c(145),<main>:==>success drop caches
main.c(148),<main>:==>start unpack file:/tmp/sysupgrade.bin ......
unpack.c(373),<unpack>:==>/tmp/sysupgrade.bin file size:19097938
main.c(155),<main>:==>success unpack
main.c(158),<main>:==>start check version......
check_version.c(515),<check_version>:==>bin_fw_ver:0.0.0.2
check_version.c(521),<check_version>:==>bin_req_ver:0.0.0.1
check_version.c(527),<check_version>:==>bin_hw_id:36b0d8b1ee52c282284e2c758717f559
check_version.c(537),<check_version>:==>bin_product_id[0]:48ed5d2db39237d7ae5e829b17581629
check_version.c(537),<check_version>:==>bin_product_id[1]:48ed5d2db39237d7ae5e829b17581629
check_version.c(537),<check_version>:==>bin_product_id[2]:48ed5d2db39237d7ae5e829b17581629
check_version.c(537),<check_version>:==>bin_product_id[3]:48ed5d2db39237d7ae5e829b17581629
check_version.c(537),<check_version>:==>bin_product_id[4]:48ed5d2db39237d7ae5e829b17581629
check_version.c(544),<check_version>:==>bin_dg_ver:DXG21
check_version.c(554),<check_version>:==>bin_retail_region[0]:AU
check_version.c(554),<check_version>:==>bin_retail_region[1]:AU
check_version.c(554),<check_version>:==>bin_retail_region[2]:AU
check_version.c(554),<check_version>:==>bin_retail_region[3]:AU
check_version.c(554),<check_version>:==>bin_retail_region[4]:AU
check_version.c(561),<check_version>:==>os_fw_ver:20250605_d3cff787
check_version.c(567),<check_version>:==>os_dg_ver:0.0.0.1
check_version.c(573),<check_version>:==>os_hw_id:36b0d8b1ee52c282284e2c758717f559
check_version.c(579),<check_version>:==>os_product_id:48ed5d2db39237d7ae5e829b17581629
main.c(179),<main>:==>success check version
main.c(180),<main>:==>main exit 0
run in ramfs
writing bl2
writing fip
writing firmware
upgrade finished
root@DGX21:~#
But after reboot, nothing changed. No OpenWRT shell, still booting into the stock DG firmware.
I suspect the image format wasnât what the vendor firmware expected, or it was written to the wrong offsets. Luckily, it didnât brick the device.
Realistically, someone would probably have to reverse or modify a vendor update image to stage OpenWRT via the web UI, which feels excessive given that sysupgrade works fine over SSH once you're in.
Maybe a factory image would succeed in bricking the deviceâjust kidding! Thanks for your efforts on this.
I completely get you're just having a joke, no worries at all.
But to take your comment seriously: I think even a factory image would result in the same nothing. This doesn't appear to be using the actual sysupgrade
tool at all.
I've already requested an official firmware image from the vendor. If they don't provide one, I'll reverse-engineer their upgrade tool to figure out what format the file should be in. After that, it should just be a matter of injecting the firmware partition from the OpenWRT sysupgrade image into the expected structure.
Once that's sorted, it should flash cleanly, but yeah, until then, we'll have to find another way to brick our DGX21s.
DGX21 Web UI Bypass (No SSH Needed)
This is a dirty flash method to boot an OpenWRT image on the DGX21 using only the vendor web interface â no UART or SSH access required.
Key Points
- Works even if you donât know the stock root password.
- After flashing, the device still boots the stock config, but with OpenWRT installed.
- Press and hold the reset button after reboot to wipe the stock config and gain access.
- Use OpenWRT 64MB sysupgrade images from andros-ua.
Do not use 112MB images â this method mimics vendor partitioning.
Why This Helps
- You can flash OpenWRT without needing SSH or UART.
- Bypasses version checks by injecting valid
tmp_fw_info
andtmp_ow_info
files. - Great fallback if the vendor locks down credentials or SSH is removed.
Script: make_staged_upgrade_tar.sh
This script builds a valid .bin
file you can upload via the stock web interface:
#!/bin/sh
# Paths
IMG=~/Downloads/openwrt-mediatek-filogic-creatlentem_clt-r30b1-squashfs-sysupgrade.bin
OUT=~/Downloads/staged_openwrt_upgrade.bin
WORKDIR=$(mktemp -d)
# Known-good metadata (adjust if your device differs)
cat <<EOF > "$WORKDIR/tmp_fw_info"
"FW_VER" "0.0.0.2"
"REQ_VER" "0.0.0.1"
"HW_ID" "36b0d8b1ee52c282284e2c758717f559"
"48ed5d2db39237d7ae5e829b17581629" "PRODUCT_ID"
EOF
cat <<EOF > "$WORKDIR/tmp_ow_info"
"DG_VER" "DXG21"
"AU" "RETAIL_REGION"
EOF
# Required placeholders for BL2 and FIP (leave empty or dummy data)
touch "$WORKDIR/tmp_bl2"
touch "$WORKDIR/tmp_fip"
# Add OpenWRT image as firmware blob
cp "$IMG" "$WORKDIR/tmp_firmware"
# Package all files into a tarball
tar -cvf "$OUT" -C "$WORKDIR" \
tmp_fw_info tmp_ow_info tmp_bl2 tmp_fip tmp_firmware
# Clean up
rm -r "$WORKDIR"
echo "Staged upgrade package created at: $OUT"
Brilliantly done. Bravo!
Hi everyone,
I have an EDUP RT2980 AX3000 router that wonât boot after flashing a test OpenWrt firmware.
Symptoms:
â Power supply OK
â LEDs turn on for a second and then all go off
â No IP response on 192.168.1.1 / 192.168.0.1
â No automatic TFTP recovery detected on the network
What I can do:
â I can open the device and solder the 4âpin UART header (TX, RX, GND, 3.3 V)
â I donât have a USBâUART adapter yet, so I need advice on a reliable model to buy (CP2102, CH340, FTDI?) for 3.3 V devices.
Questions:
- What is the correct UART baud rate? (I assume 115200 8N1)
- Should I connect only TX/RX/GND and leave 3.3 V unconnected?
- Which USBâUART adapter works best for this router? Any specific recommendation?
- What are the correct commands to do to unnbrick
Thanks
I think the suggested model of UART / USB suggested is any with the FT232RL chip that supports 3.3V TTL levels. So for example
115200, 8N1 is correct
In my experience most TTL to serial or USB things that are branded as "arduino" style seem to work ok.
I found that I didn't have to solder anything. I just sticky taped two pairs of male dupont connectors then "balanced" them in the holes on the circuit board (might need to fiddle with them a bit). If you want to do that then you'll obviously need some male to female dupont leads (those TTL units normally only come with female to female dupont leads). In my experience you do need to connect all 4 leads.
I'm not sure what the commands will be to unbrick the unit. I guess you'll have to wait until you see what the info you get from the console connection.
You say that the power LED isn't even on any more? I'm not sure what that means because on my unit while u-boot is coming up the led is still on.
Good luck!
Yess thanks man !
Ok one step at a time ... the led is on then turn off then on and off the same for the lan it looks like an infine loop ( i hope) .
But I have to get the output before Thanks
Could you specify which firmware you flashed and on which router version?