OpenWrt/LEDE Project

  • Status Closed
  • Percent Complete
  • Task Type Bug Report
  • Category Base system
  • Assigned To No-one
  • Operating System All
  • Severity High
  • Priority Very Low
  • Reported Version lede-17.01
  • Due in Version Undecided
  • Due Date Undecided
  • Private
Attached to Project: OpenWrt/LEDE Project
Opened by Jose Ignacio Guzman - 12.07.2017
Last edited by Adrian Schmutzler - 17.04.2020

FS#902 - Unable to restore stock ROM in TP-Link CPE210 HW 1.1 after flashing LEDE


Has anybody tried to restore stock ROM in CPE210 hardware version 1.1. after flashing LEDE? I have reviewed TP-LinkĀ“s forum and it seems it is not possible. People has tried the Pharos OS TFTP recovery ( as well as from the OpenWRT/LEDE web GUI, and both fail.

Everybody labels flashing to OpenWRT or LEDE as “one-way” action because they suspect that OpenWRT/LEDE “changes something” in the flash, so it breaks a restore to stock ROM . Bellow I list them:

1) OpenWRT/LEDE misses partitions of the stockROM partitions. Bellow is the partition table with stock ROM:

U-Boot partition
partition fs-uboot base 0×00000 size 0×20000 partition partition-table base 0×20000 size 0×02000

Firmware partitions
fwup-ptn partition-table base 0×00800 size 0×00800 fwup-ptn os-image base 0×01000 size 0xcbf29
fwup-ptn soft-version base 0xccf29 size 0×00015 fwup-ptn support-list base 0xccf3e size 0x0063c
fwup-ptn file-system base 0xcd57a size 0x3e4001

2) OpenWRT/LEDE changes something in the environment of the SafeLoader, which breaks the standard recovery mode.

3) Log from an attempt to transfer recovery.bin (the recovery.bin file is firmware pharos-up-ver1-3-3-P9[20160705-rel52453].bin). Safeloader request a “vmlinuz” file from the TFTP ad, of course, it does not exists.

Connection received from on port 4011 [16/03 07:27:19.543]
Read request for file <recovery.bin>. Mode octet [16/03 07:27:19.543]
OACK: <timeout=5,blksize=512,> [16/03 07:27:19.823]
Using local port 49447 [16/03 07:27:19.823]
<recovery.bin>: sent 9643 blks, 4936747 bytes in 2 s. 0 blk resent [16/03 07:27:21.708]
Connection received from on port 3164 [16/03 07:27:24.831]
Read request for file <vmlinuz>. Mode octet [16/03 07:27:24.831]
File <vmlinuz> : error 2 in system call CreateFile Das System kann die angegebene Datei nicht finden. [16/03 07:27:24.831]

I think it is important to check and solve it, because this behavior avoids warranty.

Closed by  Adrian Schmutzler
17.04.2020 19:17
Reason for closing:  Won't fix
Javier commented on 27.07.2017 21:53

I can confirm this bug... and is even worse, you cannot upload even lede fimware...+

Trying to upload lede firmware as recovery.... log:

Connection received from on port 4009 [27/07 23:41:57.485]
Read request for file <recovery.bin>. Mode octet [27/07 23:41:57.485]
OACK: <timeout=5,> [27/07 23:41:57.486]
Using local port 64947 [27/07 23:41:57.486]
<recovery.bin>: sent 6965 blks, 3565777 bytes in 6 s. 0 blk resent [27/07 23:42:03.914]
Connection received from on port 3146 [27/07 23:42:06.986]
Read request for file <vmlinuz>. Mode octet [27/07 23:42:06.987]
File <vmlinuz> : error 2 in system call CreateFile El sistema no puede encontrar el archivo especificado. [27/07 23:42:06.987]

Javier commented on 27.07.2017 23:10
Benjamin Poppe commented on 14.12.2017 10:18

I can confirm this bug to. Also CPE510 HW 1.1 the same problem.

On both, CPE210 HW 1.1 and CPE510 HW 1.1, we try the same:

LuCI reject lede-17.01.4-ar71xx-generic-cpe210-220-squashfs-factory.bin also after chorting name to firmware.bin with red infobox:
"The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your plattform"

# sysupgrade -n /tmp/firmware.bin
Image metadata not found
Invalid image magic '00366d18'
Image check 'plattform_check_image' failed.

Recover via TFTPD like described here:

The CPE grab the firmware (see via journald and tcpdump) and reboot, but no new firmware was flashed. System came up (or not when bricked) with old firmware and settings.

Jon Grossart commented on 18.01.2018 04:18

I've run into this problem on the TP-Link Archer C2600. With 17.1.2, I couldn't revert back to stock either – same issue with doing the reset and it just comes back with LEDE from the TFTP recovery. I have not tried it on 17.1.3/4.

Edit: 2018-03 I tried returning to stock from 17.01.4, and it worked correctly on the C2600.

Hector commented on 30.06.2018 15:18

Anybody has successfully went back to the original firmware with Pharos OS TFTP recovery?
I want to do it but I don't want to brick my device. Can someone confirm the procedure works?

matthias commented on 04.01.2019 08:20


Same here with CPE510 V1.1, recovery.bin containing current PharOS gets pulled via tftp successfully but the machine boots its old openwrt firmware afterwards.

Do we need to flash a stripped firmware for these old models as well? If so, how do you strip PharOS?

Thank you.

Snotto commented on 17.04.2020 19:06

Same here ... put all my 15 CPE210 in trash as they are unsellable with a custom firmware on it witch got a limited spectrum analyer on it. This bug was the reason I sell all my OpenWRT and LEDE euqipment. Now its Ubiquiti and works like charm :)

Project Manager
Adrian Schmutzler commented on 17.04.2020 19:12

I actually found there seem to be different bootloader versions among the CPE210 v1.1.
I had two devices which were undistinguishable, but one had perfectly working TFTP and the other one was broken.

Project Manager
Adrian Schmutzler commented on 17.04.2020 19:15

Since this is specifically about LEDE-17.01, which is EOL, and from my experience with newer firmware this is a uboot issue, I close this bug report.

Feel free to reopen for a newer release if you can link the issue to OpenWrt.


Available keyboard shortcuts


Task Details

Task Editing