TL;DR:

My adventures with Mercusys MR80X AX3000 Router..

Background info

I wanted to use this router to simply be a repeater bridge to get WIFI6 signal from my main router and relay it to ethernet devices (SmartTV and STB) connected to it.

Here is my home network that I wanted to setup:

I assumed that MR80X could support running as a bridge repeater mode. I got the device, open it web interface and bang. Sadly it wasn’t supporting this mode. I contacted with Mercusys technical support, asked how to achieve this, and they simply replied that this model doesn’t support this mode and they suggested me to buy another one.

So I wondered if it is possible to install an open source firmware, such as openwrt or ddwrt that would allow me to run in this mode?

Searched the internet, found a thread on openwrt forum, asking for this firmware. Commentors said it need to teardown the device and find hardware info.

I did that, and here are some photos below:

MR80X teardown

Here are some photos of my teardown process:

MR80X Hardware Info

SoC: Qualcomm IPQ0509

RAM: 256Mbyte

Flash: Gigadevice 128Mbyte SD-NAND

Ethernet Switch: Realtek RTL8367S

AX WLAN: QCN6102

MR80X Serial UART

As seen above, I only connected RX/TX/GND pins, and connected to my USB-UART adapter, and then I get a shell with minicom.

Note: It is default 115200 baud 8-N-1 .

Here are the bootup logs and some command outputs for the ones interested: MR80X-Serial-UART LOGS & COMMAND Outputs

Next Steps

If I read correctly, if the system memory is around 256Mbyte, there is no way to install OpenWRT on this device. But I see many devices are running OpenWRT perfectly with 256Mbyte and I even see following logs from the MR80X factory firmware itself:

...

   Using 'config@mp02.1' configuration
   Trying 'fdt@mp02.1' fdt subimage
     Description:  ARM OpenWrt qcom-ipq50xx-mpxx device tree blob
     Type:         Flat Device Tree
     Compression:  uncompressed
     Data Start:   0x442c3788
     Data Size:    60224 Bytes = 58.8 KiB
     Architecture: ARM
     Hash algo:    crc32
     Hash value:   cd42104d
     Hash algo:    sha1
     Hash value:   79ea0dcfd0c95782d67c4cca1b1490eec2b30228
   Verifying Hash Integrity ... crc32+ sha1+ OK
   Booting using the fdt blob at 0x442c3788
...

Why shouldn’t this be possible??

Will investigate more…