EAP245 v3 bricked - TFTP transfer works, but every file causes immediate reboot. Need working initramfs or UART guidance

The device's bootloader (U-Boot) is alive and accepts files via TFTP in recovery mode. However, there is a strict size limit of ~4.6-4.7 MB for the transferred file. While I can successfully transfer a ~4.8 MB initramfs-kernel.bin file after network optimization, the device immediately reboots after any successful transfer, whether it's a firmware kernel or a U-Boot script. The standard recovery procedure is non-functional.

Detailed Timeline & Evidence

  1. Initial State: Device was bricked while trying to revert from OpenWrt to the stock TP-Link firmware.
  2. TFTP Recovery Mode is Active: The device correctly requests the file EAP245v3_up.bin from 192.168.1.1. This confirms the recovery mode logic in U-Boot is running.
  3. Discovered Hard Size Limit: Files larger than ~4.7 MB (stock TP-Link firmware at 7.3MB, OpenWrt factory images) never finish transferring. The transfer consistently times out at ~60% completion.
  4. Breakthrough on Transfer: By disabling all competing network interfaces (Wi-Fi) on the TFTP server PC and using optimized settings (Block Size = 1428), I achieved a 100% complete transfer of an initramfs-kernel.bin file (~4.8 MB). The TFTP log confirms: sent 9665 blks, 4948112 bytes in 4 s. 0 blk resent.
  5. Core Problem - Instant Reboot: Despite the successful transfer, the device reboots instantly after the TFTP session ends. It does not attempt to boot the kernel. The same immediate reboot occurs when transferring a valid U-Boot script (boot.scr) โ€“ the script is accepted and executes a reset command, proving script execution works, but it cannot chain-load another file.
  6. HTTP Recovery Inaccessible: The web recovery interface at http://192.168.1.1 is unresponsive during this process.
  7. File Analysis: The initramfs-kernel.bin file in question is a valid MIPS ELF kernel (confirmed by file and readelf). It contains the standard sections (.text, .symtab, .strtab).

Conclusion from Testing

The bootloader's TFTP client works but is fundamentally "broken" or stuck in a loop. It accepts data but lacks the subsequent logic to validate, decompress, or jump to the received image. The ~4.7 MB window is open, but "empty". The problem is not the transfer mechanics but the bootloader state.

Request for Community Assistance

I have exhausted all standard software recovery methods. I am seeking help in two specific areas:

  1. A Known-Good "Golden" Initramfs Image: Does anyone have a verified, working initramfs-kernel.bin image for the EAP245 v3 that is under 4.7 MB? My current file might be corrupted or from an incompatible build. A working image from a stable release (e.g., OpenWrt 22.03.x) could be the "trojan horse" that finally boots.
  2. Hardware Recovery via UART (Primary Need): Guidance is needed for the EAP245 v3 specifically:
    • UART Pinout: Location of TX, RX, GND, VCC on the main PCB.
    • Terminal Settings: Recommended baud rate (likely 115200).
    • U-Boot Commands: Specific commands for this model to interrupt autoboot and initiate a TFTP flash procedure once serial access is gained.

Data Available Upon Request

  • Full TFTP server logs showing successful/unsuccessful transfers.
  • Output of file and readelf -S for the initramfs file.
  • Exact filenames and versions of all tested firmware files.

Any detailed guidance or file sharing would be immensely appreciated. Thank you.

  1. 21.02 images for EAP245 exists - https://firmware-selector.openwrt.org/
  2. https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=9dd4ba3d7ed56413399b1e36f810813c1dcf7473
  3. tftpboot and bootm
1 Like

Try to build your own image using the image builder. Choose latest 21.02 and strip unnecessary packages (wifi, luci). Goal is to have the lightest image. See if the initramfs file is light enough. That being said, to my idea, to file should already be stripped of all unnecessary packages, but it's worth trying.

1 Like

I did it. Now another task opens http boot. When loading the main OEM firmware, it gives an error.

1 Like

Is the error message "Error" ?

"System error. The router cannot start up normally. Please upgrade your router. You can download the firmware file from www.tp-link.com" i try is, but it not effecting. All firmware upgrade. A little background. I actually installed the OEM version via the Luci web interface... That's when all this mess started. Do you have any other solutions? I think it could all be done via TFTP. But with my level of knowledge and understanding of systems, it's unlikely to work without your help.

If everything else fails, use serial.

2 Likes

Unless explicitly available, this behavior is biohazard ! :skull_and_crossbones:
I read that the OEM image has 1KB of signed data that Luci can't handle. Hence all the image is shifted in memory.

Factory images for these devices are RSA signed by TP-Link. While the
signature verification can be disabled, the factory image still needs to
have a (fake) 1024 bit signature added to pass file checks.
1 Like

If you didn't use the tplink-safeloader tool from firmware-utils to convert the OEM image, you will have loaded an incompatible image. Those OEM files are more of a container with multiple partitions that need to be unpacked, while sysupgrade files are written to flash pretty much as-is.

You should be able to load and boot an initramfs with the u-boot console, from which you can flash a known-correct sysupgrade file again.

If you don't have working console access, TP-Link also lists these recovery methods:

You seem to have the TFPT-method working already, so I would suggest to follow the steps as laid out in TP-Link's guide.

1 Like

thanks, i try serial... :cry:

2025-12-30 09:34:03 Configuring baud rate 115200
2025-12-30 09:34:03 Configuring 8 data bits
2025-12-30 09:34:03 Configuring 1 stop bit
2025-12-30 09:34:03 Configuring no parity
2025-12-30 09:34:03 Configuring no flow control
โ–’โ–’Qโ–’๋งด;3Fโ–’=โ–’โ–’4Pikโ–’โ–’kโ–’Iโ–’{Oaโ–’{โ–’โ–’,โ–’โ–’*โ–’]โ–’โ–’โ–’+ฯชโ–’mโ–’zโ–’โ–’5#โ–’j7โ–’:-โ–’jโ–’โ–’~โ–’โ–’โ–’โ–’Rโ–’lZ5โ–’Vโ–’;โ–’S!
                                                                       !+ๅฝฒโ–’iโ–’=โ–’โ–’โ–’โ–’โ–’โ–’P+โ–’โ–’โ–’โ–’โ–’โ–’โ–’-โ–’โ–’Eโ–’Z#โ–’iโ–’โ–’โ–’Qโ–’7[โ–’*โ–’โ–’โ–’โ–’e'โ–’โ–’]U(โ–’โ–’e-=Rโ–’]mโ–’e5โ–’-
                                                         :Gy=VMโ–’Qiโ–’zโ–’โ–’ึ–โ–’!โ–’}pโ–’Yโ–’VoZโ–’]mโ–’-!โ–’e!โ–’โ–’Qโ–’[HZโ–’โ–’โ–’โ–’โ–’โ–’โ–’โ–’+โ–’R*ีญโ–’cโ–’m*(=-
                                      9โ–’)JmAํŸ™โ–’โ–’*โ–’3F!cโ–’หฆโ–’UNโ–’kโ–’โ–’Sโ–’โ–’โ–’โ–’:โ–’โ–’โ–’kโ–’โ–’โ–’]^yU(โ–’โ–’โ–’A1Iโ–’
       5#โ–’โ–’QหฃQโ–’:โ–’iโ–’โ–’=โ–’M=Rโ–’Wโ–’โ–’Z-#โ–’'โ–’iโ–’%-โ–’โ–’Rโ–’โ–’โ–’โ–’โ–’โ–’โ–’Oโ–’)1I
                                                      5#!หงQโ–’Z55+โ–’i,โ–’โ–’โ–’โ–’+โ–’Oโ–’iโ–’โ–’Mโ–’โ–’โ–’*โ–’uโ–’_โ–’โ–’โ–’UOโ–’imaโ–’
                 โ–’tโ–’โ–’]โ–’-โ–’
                         โ–’โ–’โ–’โ–’โ–’
                              โ–’Sโ–’]i1

R
e%โ–’โ–’)e5Qโ–’โ–’โ–’โ–’]โ–’โ–’Yuโ–’zโ–’โ–’โ–’โ–’Oโ–’โ–’โ–’หšRโ–’โ–’zโ–’โ–’โ–’vGy=Mโ–’โ–’ัŸzโ–’โ–’I,6Zโ–’jโ–’โ–’Zโ–’Mโ–’โ–’โ–’Tโ–’]โ–’โ–’*โ–’m#Dโ–’โ–’โ–’โ–’Vโ–’Mโ–’โ–’Fโ–’Qโ–’Qiโ–’k-โ–’โ–’jโ–’Sโ–’lโ–’kโ–’]โ–’โ–’โ–’โ–’โ–’5โ–’โ–’cSโ–’WC+โ–’7โ–’
//connected via serial

  • This usually occurs when the parameters are incorrect or the wiring is mixed
  • You provided no information on the terminal software used

i use putty

I agree with @lleachii, try diff speeds.

not work((((

what USB TTL are you using ?

post a photo of your connection point on the PCB.

Chipset: WCH CH340
Interface: USB 2.0, RS232




RS232 <> USB TTL, different voltages.
hope you didn't fry it.

1 Like

If I had burned it, it wouldn't have shown anything) But I checked the lines with a multimeter, everything works

then you should still be able to recover it, as long as you use the correct tool(s) ?

2 Likes