Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
openwrt-bot opened this issue Jul 12, 2017 · 9 comments
Labels

Comments

@openwrt-bot
Copy link

openwrt-bot commented Jul 12, 2017

nachogc:

Hello

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 (http://forum.tp-link.com/showthread.php?81684-How-to-use-firmware-recovery-function-of-Pharos-CPE1) 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 0x00000 size 0x20000
partition partition-table base 0x20000 size 0x02000

Firmware partitions
fwup-ptn partition-table base 0x00800 size 0x00800
fwup-ptn os-image base 0x01000 size 0xcbf29
fwup-ptn soft-version base 0xccf29 size 0x00015
fwup-ptn support-list base 0xccf3e size 0x0063c
fwup-ptn file-system base 0xcd57a size 0x3e4001

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

  2. 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 192.168.0.254 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 192.168.0.254 on port 3164 [16/03 07:27:24.831]
Read request for file . Mode octet [16/03 07:27:24.831]
File : 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.

@openwrt-bot
Copy link
Author

openwrt-bot commented Jul 27, 2017

apocalipsis1234:

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 192.168.0.254 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 192.168.0.254 on port 3146 [27/07 23:42:06.986]
Read request for file . Mode octet [27/07 23:42:06.987]
File : error 2 in system call CreateFile El sistema no puede encontrar el archivo especificado. [27/07 23:42:06.987]

@openwrt-bot
Copy link
Author

openwrt-bot commented Jul 27, 2017

apocalipsis1234:

More information here:
http://blog.friedzombie.com/tp-link-restoration-firmware/

@openwrt-bot
Copy link
Author

openwrt-bot commented Dec 14, 2017

bepo:

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
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"

CLI

sysupgrade -n /tmp/firmware.bin

Image metadata not found
Invalid image magic '00366d18'
Image check 'plattform_check_image' failed.

TFTPD
Recover via TFTPD like described [[http://forum.tp-link.com/showthread.php?81684-How-to-use-firmware-recovery-function-of-Pharos-CPE|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.

@openwrt-bot
Copy link
Author

openwrt-bot commented Jan 18, 2018

jon.grossart:

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.

@openwrt-bot
Copy link
Author

openwrt-bot commented Jun 30, 2018

wizbcn:

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?

@openwrt-bot
Copy link
Author

openwrt-bot commented Jan 4, 2019

Funk-me-if-you-can:

Hi!

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.

@openwrt-bot
Copy link
Author

openwrt-bot commented Apr 17, 2020

Snotmann:

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 :)

@openwrt-bot
Copy link
Author

openwrt-bot commented Apr 17, 2020

adrianschmutzler:

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.

@openwrt-bot
Copy link
Author

openwrt-bot commented Apr 17, 2020

adrianschmutzler:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant