EAP245 (US) V3 - Soft bricked

Hi Team,

So it seems that TP-Link Sell the US version of the EAP-245 V3 into NZ, which means only 2 channels of 80mhz in the 5GHz band.

I installed OpenWRT to test that this device could actually use the other channels in 5GHZ and it can.

The fun started when I tried to roll back to the official TP-LINK firmware via the GUI.

Initially, the device was very much bricked, not even the factory system on HTTP was launching, this was resolved via the SFTP recovery option. Since loading stock firmware, it now loads the HTTP recovery option.

But it seems every firmware I try to load doesn't complete, shows a failure after getting to 100%

Stuck in the HTTP recovery mode, how to proceed from here. I do have a USB TTL adapter coming, so hopefully, this will enable other recovery options.

I have another stock EASP245(US v3) to hand, maybe this could be a doner for missing firmware parts or assist in this recovery effort.

Ideally, I'd like to remove the US personality lock from the device, so I can use DFS 5GHZ channels here in NZ.

From my investigations, it would appear the US and EU firmware are the same, I expect its MTD2 that has the localisation hardcoded so it always presents as US locked device.

I have read here, the same might be true for US/CA versions.

Any help is appreciated.

Regards WelshWizards

I don't think that US and EU devices are marked as such, and OpenWrt provides one firmware image which is accepted by both. This is why some users have been able to write a CA firmware (which does have a region lock), and then aren't able to go back because the other (US) firmware doesn't list any region.

Any region lock on your device should be in the same place as the region=CA seen on firmware images for the Canadian market. Unless they use yet another region locking mechanism, but that seems unlikely to me.

If you want to use the DFS channels, and they aren't supported by the stock firmware, I would suggest you just use OpenWrt. You could use the ath10k driver, instead of the default ath10-ct driver, to work around the 40MHz Tx bandwidth issue.

Hi Sander,

It seems my ch340 USB<>TTL dongle is non-working or I have bigger issues, serial into uboot only shows gibberish information. Will order a new dongle with a FT232RL, as I have read people often have issues with the ch340 chip.

I think this device is stamped USA like the CA issue.

841 is USA country code, also says no DFS supported

.tplink.omada.device.message.discovery.eap.EapDeviceMisc@3659af[support5g=true,support11ac=true,supportLag=false,supportMesh=1,**customizeRegion=841**,minPower2G=6,maxPower2G=24,minPower5G=6,maxPower5G=24,supportChannelLimit=<null>,channelLimitMode=<null>,**supportDfs=0** ,lanPortsNum=<null>,lanVlanPorts=<null>,lanPoePorts=<null>,supportRoaming=1,additionalProperties={maxTxPower=0}],

Where did you get this information? The only similar thing I can find are numeric ISO 3166 codes, but there USA is 840. The region-locked Canadian devices have "region=CA" in their product-info partition, can you check if there's something similar on your device?

1 Like

If you look at the GPL source code for the AP there is a REGION/Country file along with allowed radio frequencies for each radio. The number in here matches the number seen, and a text name for country.

The partial log in previous post is from enabling more verbose logging inside the controller, that message is during the device boot/registration with the controller. Basically it’s letting the controller know it’s capabilities.

Fingers crossed I can revive it.

Ok, I found it too now, in the files from the stock firmware.

My (EU) device has "EU276" in the product-info partition, I suppose yours has US841 then. Perhaps you could try modifying those bytes to the NZ values.

Although, this being the OpenWrt forum, I would actually propose you just switch over to OpenWrt to not have to deal with this kind of nonsense :stuck_out_tongue:

1 Like

True, but it's all a learning experience.
With it being soft-bricked I can't do much without a working UART/Serial connection.

My reason to load OpenWrt was to see if this was just a software limitation, it seems tp-link for whatever reason have hobbled it.

I would suspect having it set into UE mode would be enough to open up the DFS channels in 5GHz band.

Hi Team,

I finally have a working UART connection to my soft-bricked AP.
I'm facing this problem as seen below, any way to get back to OpenWRT via serial?

Firmwave supports EAP245(TP-Link|UN|AC1750-D):3.0, check OK..
Firmware Recovery check ok!
[NM_Error](nm_updateDataToNvram) 00652: memory malloc failed.
[NM_Error](nm_upgradeFwupFile) 01666: updateDataToNvram failed.
[NM_Error](nm_tpFirmwareRecovery) 01627: upgrade firmware failed!

Now that you have serial access, you should be able to follow the debricking instruction (same as for the EAP245 v1):

  • Interrupt bootloader by holding CTRL+B during boot
  • Load initramfs via TFTP
setenv ipaddr # default, change as required
setenv serverip # default, change as required
tftp 0x80800000 initramfs.bin
bootelf $fileaddr
  • Flash OpenWrt (or the converted vendor firmware) with sysupgrade, or the LuCI web interface (if included in the initramfs)

Thanks for that, booted the initramfs.bin and got to LuCI.

When trying to write [openwrt-ath79-generic-tplink_eap245-v3-squashfs-sysupgrade.bin] it fails as seen below

Writing from <stdin> to firmware ...
Tue Aug 31 22:22:32 UTC 2021 upgrade: Upgrade completed
Tue Aug 31 22:22:33 UTC 2021 upgrade: Rebooting system...
umount: can't unmount /dev: Resource busy
umount: can't unmount /tmp: Resource [  154.080428] reboot: Restarting system

U-Boot 1.1.4--LSDK-10.2-00082-4 (Mar 19 2018 - 14:55:50)

board956x - Dragonfly 1.0DRAM:
ath_ddr_initial_config(287): (ddr2 init)
ath_ddr_initial_config: DDR_EMR2_ADDRESS=0x180000bc, EMR2 value=0x80
ath_sys_frequency: ref_clk 25000000
ath_sys_frequency: cpu 775 ddr 650 ahb 258
Tap values = (0xf, 0xf, 0xf, 0xf)
128 MB
Top of RAM usable for U-Boot at: 88000000
Reserving 454k for U-Boot at: 87f8c000
Reserving 192k for malloc() at: 87f5c000
Reserving 44 Bytes for Board Info at: 87f5bfd4
Reserving 36 Bytes for Global Data at: 87f5bfb0
Reserving 128k for boot params() at: 87f3bfb0
Stack Pointer at: 87f3bf98
Now running in RAM - U-Boot at: 87f8c000
Flash Manuf Id 0x1c, DeviceId0 0x70, DeviceId1 0x18
flash size 16MB, sector count = 256
Flash: 16 MB
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Setting 0x181162c0 to 0x40802100
Hit Ctrl+B to stop autoboot:  0
[NM_Error](nm_api_checkInteger) 00373: factory boot check integer flag is not 1.

I think we solved this issue before. Check out this post and the ones following it:


Super, I now have a backup of all my MTD partitions, and my MTD5 was also the same as the other poster.

I've modified a copy of the MTD5 and the next step would be for me to copy and write this back, in the thread doesn't detail the steps.

How would I do this?

Thanks for your help

Have a look at this page: https://openwrt.org/docs/techref/mtd

With the mtd tool you can manipulate mtd partitions, which is what you'll need to rewrite the extra-para partition.

@svanheule progress has been made, I can now boot into OpenWRT after modifying/writing the MTD5 partition.


Thank you for all your help, it's been a learning experience, One of my AP is now an EU model so this opens up the DFS channels for me.

Now, to think up a way to automate the modification of the mtd3 partition, without connecting via serial.

You modified the partition from OpenWrt, so you don't need serial unless the device is bricked. Automating flashing and MTD modification won't be as straightforward, I guess.

1 Like

Yes I did perform the mod via Openwrt, but trying to figure out if this mode can be made on a system with stock firmware.

Will try and update the MTD3 with the NZ country code as I only get 4 80Mhz channels in 5Ghz and should see 6 when using NZ code.

I think the safeloader firmwares can contain any of the partitions on the device. If you extract MTD3, edit it, and create a custom firmware with it, you might be able to reflash from the vendor firmware (using the same stopcs trick).

That would be pretty awesome, but probably quite a challenge, would be some learning curve.

I’ll attempt to flash a NZ region MTD3 today, if I have the time.

Might order some 4 pin headers to put a permanent socket in the AP.

Shame I can’t get a real root on the device, life would be simple then.

@svanheule It would seem that the AP only has two regions inside the Firmware EU/US, this setting then causes the firmware to load boarddata_eu.bin or boarddata_us.bin on boot.

1 Like