TP-Link Archer MR600 exploration

rkrol-dev · June 15, 2025, 7:25pm

I'm still experiencing some issues with my TP-Link Archer MR600 V2 EU and would appreciate any insights from the community.

Issue 1 - OpenWRT Flash Attempt: I attempted to flash OpenWRT secound time on the device but encountered a critical issue:

The flash process appears to complete without errors
However, after reboot, the LAN interface becomes unresponsive
Computer cannot obtain IP address via DHCP from the router
The device appears to boot but network functionality is completely broken

Issue 2 - LTE Connection Problems (Stock Firmware): After recovering to stock firmware via TFTP, I have the following LTE issues:

System logs show:

1538352027 WARN: Network selecting failed, mostly rejected.
1538352029 USER: Network type is WCDMA.
1538352018 ERROR: [band scan] Modem band seletion : 0x1a0080800d5. config band : 0x1a0080800d5
1538352033 USER: The service status is limited.
1538352018 USER: lte_sms_status_valid invalid .
1538352033 USER: Not registered, searching!
1538352019 ERROR: 0x0000004A QMI_ERR_INFO_UNAVAILABLE
1538352019 WARN: Sim card is inserted.
1538352019 ERROR: 0x00000010 QMI_ERR_NOT_PROVISIONED
1538352019 ERROR: Get sim card number failed (0).
1538352019 USER: GET_SMSC_ADDRESS response, value = +48602951111

I can find LTE network names when sim card is not inserted. When sim card inserted no network can be found....

Questions:

Has anyone similar lan failure? this seems like a common issue but I haven't found a solution.
LTE connection issues after firmware recovery - has anyone seen these specific QMI errors? The modem hardware seems fine but something in the provisioning/calibration data might be missing.
Missing calibration data? During the recovery process, the romfile partition was erased. I've restored MAC and IMEI manually, but there might be other calibration data needed for LTE functionality.

stefandoesinger · June 16, 2025, 7:25am

I had issues booting the device at the start. The serial port showed that the device was running, but the network wasn't there. It sounds very similar to what you describe. When trying to boot a few times it would eventually come up.

I don't have a solution though. The issue went away magically when I switched to flashing self-compiled builds from the openwrt-24.10 rather than prebuilt builds from the firmware selector.

Another pitfall is that if booted to recovery mode, only one of the ethernet ports is operational. That was mentioned in the instructions, but I missed it when following the steps. That showed up in the way that I could load the image from tftp, boot it, but then would have no connection once the ram image was booted.

Re your LTE issues: There are two more partitions after romfile, config and radio. I looked at my config partition, but couldn't make sense of the data. It looks mostly like random or encrypted data, except for a few 0 bytes at the start and 0xff towards the end. It is possible your earlier failed attempt wiped it as well.

Radio contains wifi-related stuff. For openwrt I flashed the blob posted in an earlier comment here, but I have a backup of my original radio partition.

rfo · June 16, 2025, 11:03am

Hi ! Nicely done !

Is it possible to write the rom from the ssh console of the router (already under openwrt) or is it mandatory to use the serial interface ?
I'm not really good a this low level stuff

My goal is to change the imei to the one of an old android phone I have so the network provider allows ipv6 and public ip ... !

Thanks !

stefandoesinger · June 16, 2025, 11:19am

I think it should be possible to write the romfile partition from ssh. You might need mtd-rw though. Look up the earlier posts about writing the radio partition.

If that successfully changes your IMEI is a different question though. It is likely that the modem (a different computer running Android!) has its own copy of the IMEI and the number stored in romfile is only used for displaying the IMEI on the Web UI.

In any case make a backup first. You might also run afoul of integrity checks. There is data in romfile and certainly config that we don't understand.

rfo · June 16, 2025, 1:44pm

Thanks !
Will look into that then as I have already flashed the radio file with the one in this thread.

I’m don’t understand why the hardware architecture of the router is so complicated Oo
Having another independent cpu for the modem itself seems over engineering to me !

stefandoesinger · June 16, 2025, 6:59pm

I am half guessing here, but I think it is built that way because they had a ready to go modem module and just plugged it into the router rather than trying to merge the functionality into one system. With anything radio related there's also a complicated certification process for devices. Dumping an existing "phone" into the router probably allowed re-using the LTE certification for the baseband rather than re-certifying the entire device. Even on real phones the baseband processor is usually a separate CPU+RAM.

rfo · June 16, 2025, 7:14pm

Thank you for these details

If only AT commands were working, it'll be much simpler
But i'm guessing they made them locked or something like that to avoid issues or maybe as you said to pass/keep a certification

Do you have more informations about the "dumped phone" in this router ? Maybe we can serial connect to it or something else, too bad i'm more into c++ than into electronics

stefandoesinger · June 16, 2025, 8:33pm

You can adb shell into it. You need to install the android debug bridge on the main openwrt image and make sure that you do not have the /dev/ttyUSB* nodes you get through the "option" usb to serial driver (because ADB talks to the USB endpoints via libusb).

I looked around a bit in it previously. adb is running as root, so your chances of being able to change (and break!) something are pretty good. Post number #102 in this thread has some instructions on how to run commands in the adb shell to talk to the modem behind the modem. If it'll allow you to change the IMEI no idea. The IMEI isn't supposed to be changeable in the first place.

I haven't found anything noteworthy on that mini-android though. An earlier comment suggests that there's a HTTP server running, but I couldn't find any open ports. It seems to use an ARM CPU with 32 mb ram. The modem in the modem appears to be MBIM (rather than QMI) based. I concluded that whatever I can reasonably do on there I can also do via the uqmi command line tool or mmcli and decided to free space by removing adb again.

rfo · June 17, 2025, 12:36pm

Thanks I'll have a look when I can

rfo · June 17, 2025, 3:09pm

I made some tests to see and was able to use adb (needed to remove the lib that allows ttyusb* and install libusb to make adb to work).

Doing this allowed to see the content of the modem os filesystem and following post 33 of this link I tried to do :

1- login to the LTE using adb shell
2- active executable bit for cgi files: chmod +x /WEBSERVER/www/cgi-bin/*
3- run httpd daemon: httpd -h /WEBSERVER/www/
4- access the webserver via your browser: http://192.168.225.1/login.html (user/pass: admin/admin)

Commands worked but was not able to connect to the httpd through openwrt / adb.
It appears that this is the internal web interface used to configure the modem but I have no clues how to access it from "outside".

A quick search in the modem filesystem showed a clear IMEI stored in misc/imei that can be changed and don't reset after restarting but I guess its just a debug one.

Need to investigate a bit more but I'm not an expert in Android / networking stuff so if someone has time to help

stefandoesinger · June 17, 2025, 3:55pm

You'll most likely have to set up a port forward with adb: https://developer.android.com/tools/adb#forwardports

something like adb forward tcp:8880 tcp:80

And then open http://192.168.1.1:8880 in your browser. Replace the IP address with whatever LAN IP you are using for the router.

I don't know if adb port forwards are accessible from the outside, they might just be accessible on the loopback interface. If that's the case maybe there are some options you can pass to adb to change that. Worst case you can port forward to your main computer via ssh, e.g. ssh root@192.168.0.1 -L8880:127.0.0.1:8880 and point your browser to http://localhost:8880.

stefandoesinger · June 17, 2025, 9:12pm

I was able to access the internal web interface with the instructions you copypasted + adb forward + ssh forward. adb forward only binds to localhost (= the openwrt device's internal loopback interface), so the extra ssh forward is needed.

There is no index.html, but QCMAP.html seems seens to be the main entry point. After logging in it asked me to set a new password.

But the actual options are underwhelming. It looks like a mini router setup (NAT, UPNP, WIFI, ...). Since the modem already passes through the ISP-supplied IP I don't see what I could reasonably do there. And there is no telling if changing settings there has any effect. The best thing the web UI does is write to some config files. Some other component will need to read those files and act according to the setting for this to do anything.

Also beware of kernelpanic1's misfortune. Changing some setting might trigger an unexpected codepath in the modem and you can't go back to the original setting.

rfo · June 18, 2025, 7:38pm

Ah crap ... ! I had bigger hopes !

Will try as you did just to explore this, but its sad
Still moving forward at least

Thanks for trying !

I really wonder how they set the imei from factory, they do flash each router with a specific rom ? Seems overwhelming to me

stefandoesinger · June 19, 2025, 6:39am

I have no idea how the actual assembly of those devices works, but yes, individual data needs to be written onto them: Not just IMEI, also MAC, serial number. Also the individual labels need to be printed with those numbers in human readable form and put on the matching device.

shankarinece · June 23, 2025, 11:06am

Right after flashing the Modified (using the commands dd if="official_firmware_filename.bin" of=firmware.bin bs=$((0x100)) skip=$((0x202)) count=$((0xfa00)), send to unit's /tmp using SCP and execute mtd write firmware.bin firmware) Original firmware, leave it to boot. Once the boot process is complete, reset the unit using reset button at the back to bring all the original functionalities.

stefandoesinger · June 29, 2025, 9:23am

@rfo , did you ever try changing the IMEI in the romfile partition? If so, what were the results?

thekief · July 6, 2025, 12:45pm

Sorry for following up so late.

After getting back to this issue I was able to fix it using the way you described, thank you very much. I got two questions in this context:

Do you happen to know what causes this issues?
I thought about adding a startup script that repeats the command until, e.g. a ping 1.1.1.1 succeeds. What do you think of this idea? Do you maybe have a better one?

AndrewZ · July 6, 2025, 12:58pm

I didn't offer a solution, I just suggested how to gather information that might help find a solution.

If the SIM cannot be read from the first attempt then some timer probably needs to be added or adjusted in the connection script.

rfo · July 8, 2025, 2:46pm

Hi !
I did not try that as I don't know which romfile to edit and where to edit it
I'm really not familiar with linux I'm afraid !
But if you have some general guidance I can try it as I think I can sort it out

stefandoesinger · July 13, 2025, 9:47am

I noticed that this router has a crypto engine that can accelerate some cryptographic operations. To use it, install/enable kmod-crypto-hw-eip93 and enable HW acceleration in your SSL library (e.g. WOLFSSL_HAS_DEVCRYPTO_{CBC/AES/FULL} for wolfssl).

According to the wolfssl benchmark it is working:

With wolfssl software:

AES-128-GCM-enc             10 MiB took 1.551 seconds,    6.449 MiB/s
AES-128-GCM-dec             10 MiB took 1.552 seconds,    6.443 MiB/s
AES-192-GCM-enc             10 MiB took 1.696 seconds,    5.895 MiB/s
AES-192-GCM-dec             10 MiB took 1.704 seconds,    5.867 MiB/s
AES-256-GCM-enc             10 MiB took 1.838 seconds,    5.441 MiB/s
AES-256-GCM-dec             10 MiB took 1.921 seconds,    5.206 MiB/s
...
AES-128-CTR                 15 MiB took 1.388 seconds,   10.809 MiB/s
AES-192-CTR                 10 MiB took 1.068 seconds,    9.367 MiB/s
AES-256-CTR                 10 MiB took 1.213 seconds,    8.241 MiB/s

With HW acceleration:

AES-128-GCM-enc             15 MiB took 1.223 seconds,   12.269 MiB/s
AES-128-GCM-dec             15 MiB took 1.224 seconds,   12.257 MiB/s
AES-192-GCM-enc             15 MiB took 1.276 seconds,   11.757 MiB/s
AES-192-GCM-dec             15 MiB took 1.268 seconds,   11.832 MiB/s
AES-256-GCM-enc             15 MiB took 1.311 seconds,   11.442 MiB/s
AES-256-GCM-dec             15 MiB took 1.316 seconds,   11.397 MiB/s
...
AES-128-CTR                 55 MiB took 1.056 seconds,   52.086 MiB/s
AES-192-CTR                 50 MiB took 1.107 seconds,   45.160 MiB/s
AES-256-CTR                 40 MiB took 1.005 seconds,   39.789 MiB/s

However, at least in my case it doesn't matter in practise. Dropbear has its own crypto code and doesn't call wolfssl. uhttpd uses CHACHA for TLS, which is not accelerated by this HW and gives 30MiB/s in plain software - which is way faster than HW accelerated AES GCM - and the same cipher is used for wireguard. The crypto acceleration on the access point would also only matter for things you transfer to/from the AP, not something that's forwarded e.g. from WAN to LAN.

It might help with certain kinds of VPNs though. The kernel driver help specifically mentions IPsec. To check if the crypto hw is actually used, see if the interrupt counter for 1e004000.crypto is ticking up in /proc/interrupts.