I managed to brick my router when trying to revert to factory firmware.
I have lost my own mtd blocks, and used those posted by ka2107, and confirmed by dangowrt to be good, but I edited mtd3 before writing it, to include device data of my router, taken from the stickers at the back (serial no, mac, wifi pass, etc.). Now I have a blinking power, no ping. I wonder if anybody would like to take a look? I'm happy to send the router via post, or any suggestions on how to fix it?
The documentation has been updated by @loyukfai and me:
@Octi Did you complete these steps including the final step, uploading the vendor firmware via TFTP?
That's a bit scary then indeed. You may need to wire up serial console to see what has happened.
Which LED is blinking and at which frequency (approximately)?
The power LED is blinking, in white colour, approx twice a second.
You should've also edited the mtd2 (factory partition) if you restored it from another device backup because MAC-s are also there in hex form. But I think that mtd2 (i.e. original mtd4 partition) should NOT be restored anyway because it is not touched by upgrades or conversion to UBI. Also this factory partition keeps very important data specific to the router, it should definitely not be loaded from another router as it is.
When you say you cannot ping the router, which address have you tried? I think both original and UBI loaders expect a tftp server at 192.168.1.254 (which should be the fixed IP assigned to your computer). Try then to serve by tftp an original factory firmware renamed to "lede-mediatek-mt7622-MTK-AX3200-MT7531-squashfs-sysupgrade.bin". Even if the router will be revived the wireless part could be affected by the different factory partition.
twice per second sounds like reboot loop, that's not good...
There must be a way to fix this situation, no?
Perhaps we should all chip in to an OpenWrt brick insurance. We all chip in $5 and next person to brick device can claim.
Yes. Attaching serial console is the first step to know what's going on.
If you don't get anywhere from there (because bootchain fails very early) you got two more options:
Thanks for all of the effort @daniel et al.!!!
I experienced a bad flash (blinking power light) from factory firmware a few weeks back, and just sat down to try and restore the beast. Fortunately, U-boot was functional in the serial interface, and I eventually flashed the recovery initramfs, restored my (backed up) original mtd partitions, and from there flashed the latest-and-greatest installer while watching the console. All of that is well documented in here and elsewhere. Ubi installed correctly this time, and I am happily now running the latest snapshot from the Luci interface to auc.
I'm a happy camper!
However, I have one question (maybe a FAQ?). Given that this might be a (slightly) nonstandard firmware route from OpenWRT's viewpoint, is this UBI-based firmware approach for this router going to be pushed "upstream" into the main OpenWRT repo? Or is this something that will be dependent on @daniel continuing to maintain this approach externally to OpenWRT mainline?
Again, thank you for all of the HARD WORK so far!
So I installed openwrt on my belkin rt3200 and it was working fine until I did a sysupgrade on it. after 2 hours of it saying "installing upgrade" and whatnot with the circle going around and around i figured it was done upgrade and just froze. So I unplugged it and plugged it back in. Now I have no power light that comes on and the internet light comes on as orange no more than 5 seconds after power goes to it. I've tried installing firmware to it, it won't work. So i listened on a tcpdump and it wants a ubi-recovery file so i set up a tftp server and made sure that the file was named the exact same and still no luck it just kept repeating the same thing. That was in linux and now i am in windows because i was trying to fix it using windows hoping that will help. no luck so far. im not sure what to do though, i can ping it but i cannot ssh to it unless im doing it wrong, can someone please help. thanks
What happened is most likely that you flashed a sysupgrade file which didn't match the UBI flash layout (ie. file without -ubi- in it's name).
To recover you need to setup a TFTP server listening at address 192.168.1.254/24.
You should download openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb and let the TFTP server serve that file.
The router will download it (you can watch in tcpdump, you should see data transfer happening) and then come up with OpenWrt initramfs/recovery.
Once LEDs stop flashing, open LuCI in Web browser 192.168.1.1. From there proceed and flash sysupgrade file openwrt-mediatek-mt7622-linksys_e8450-ubi-squashfs-sysupgrade.itb.
It already is upstream on git.openwrt.org and was from day 1.
However, the OpenWrt build system currently doesn't allow generating the installer (which is only needed once), so this is done using the script in my repository on github. All artifacts used by the script are built by OpenWrt's buildbots and so are up-to-date nightly snapshots.
Fantastic!!!
Thanks again!!!
i set up a tftp server using atftpd and it says its serving the file to the router but nothing happens after that. not sure what im doing wrong though. it keeps repeating itself over and over again. here's the output of tcp dump
192.168.1.1.4060 > 192.168.1.254.tftp: [no cksum] TFTP, length 96, RRQ "openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb" octet timeout 5 blksize 1468
18:24:02.834036 IP (tos 0x0, ttl 64, id 43810, offset 0, flags [DF], proto UDP (17), length 47)
192.168.1.254.45491 > 192.168.1.1.4060: [bad udp cksum 0x847c -> 0x78e1!] UDP, length 19
18:24:03.876772 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.1, length 46
18:24:03.876787 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.254 is-at 6c:02:e0:82:5b:a0 (oui Unknown), length 28
18:24:03.876823 IP (tos 0x0, ttl 255, id 1074, offset 0, flags [DF], proto UDP (17), length 124)
192.168.1.1.2031 > 192.168.1.254.tftp: [no cksum] TFTP, length 96, RRQ "openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb" octet timeout 5 blksize 1468
18:24:03.877257 IP (tos 0x0, ttl 64, id 44035, offset 0, flags [DF], proto UDP (17), length 47)
192.168.1.254.51948 > 192.168.1.1.2031: [bad udp cksum 0x847c -> 0x6795!] UDP, length 19
18:24:04.919467 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.1, length 46
18:24:04.919482 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.254 is-at 6c:02:e0:82:5b:a0 (oui Unknown), length 28
18:24:04.919518 IP (tos 0x0, ttl 255, id 1075, offset 0, flags [DF], proto UDP (17), length 124)
192.168.1.1.3074 > 192.168.1.254.tftp: [no cksum] TFTP, length 96, RRQ "openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb" octet timeout 5 blksize 1468
18:24:04.919918 IP (tos 0x0, ttl 64, id 44243, offset 0, flags [DF], proto UDP (17), length 47)
192.168.1.254.34327 > 192.168.1.1.3074: [bad udp cksum 0x847c -> 0xa857!] UDP, length 19
18:24:05.761626 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.254, length 28
18:24:05.962462 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.1, length 46
18:24:05.962478 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.254 is-at 6c:02:e0:82:5b:a0 (oui Unknown), length 28
18:24:05.962512 IP (tos 0x0, ttl 255, id 1076, offset 0, flags [DF], proto UDP (17), length 124)
192.168.1.1.1045 > 192.168.1.254.tftp: [no cksum] TFTP, length 96, RRQ "openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb" octet timeout 5 blksize 1468
18:24:05.962906 IP (tos 0x0, ttl 64, id 44367, offset 0, flags [DF], proto UDP (17), length 47)
192.168.1.254.46001 > 192.168.1.1.1045: [bad udp cksum 0x847c -> 0x82aa!] UDP, length 19
18:24:06.781920 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.254, length 28
18:24:07.005423 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.1, length 46
18:24:07.005446 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.254 is-at 6c:02:e0:82:5b:a0 (oui Unknown), length 28
18:24:07.005490 IP (tos 0x0, ttl 255, id 1077, offset 0, flags [DF], proto UDP (17), length 124)
192.168.1.1.2088 > 192.168.1.254.tftp: [no cksum] TFTP, length 96, RRQ "openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb" octet timeout 5 blksize 1468
18:24:07.006072 IP (tos 0x0, ttl 64, id 44518, offset 0, flags [DF], proto UDP (17), length 47)
192.168.1.254.32781 > 192.168.1.1.2088: [bad udp cksum 0x847c -> 0xb23b!] UDP, length 19
18:24:07.805838 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.1 tell 192.168.1.254, length 28
18:24:08.048389 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.1, length 46
18:24:08.048400 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.254 is-at 6c:02:e0:82:5b:a0 (oui Unknown), length 28
18:24:08.048434 IP (tos 0x0, ttl 255, id 1078, offset 0, flags [DF], proto UDP (17), length 124)
192.168.1.1.3131 > 192.168.1.254.tftp: [no cksum] TFTP, length 96, RRQ "openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb" octet timeout 5 blksize 1468
18:24:08.048770 IP (tos 0x0, ttl 64, id 44594, offset 0, flags [DF], proto UDP (17), length 47)
192.168.1.254.53888 > 192.168.1.1.3131: [bad udp cksum 0x847c -> 0x5bb5!] UDP, length 19
18:24:09.090270 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.1, length 46
18:24:09.090290 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.254 is-at 6c:02:e0:82:5b:a0 (oui Unknown), length 28
18:24:09.090312 IP (tos 0x0, ttl 255, id 1079, offset 0, flags [DF], proto UDP (17), length 124)
192.168.1.1.1101 > 192.168.1.254.tftp: [no cksum] TFTP, length 96, RRQ "openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb" octet timeout 5 blksize 1468
18:24:09.090633 IP (tos 0x0, ttl 64, id 44811, offset 0, flags [DF], proto UDP (17), length 47)
192.168.1.254.37914 > 192.168.1.1.1101: [bad udp cksum 0x847c -> 0xa209!] UDP, length 19
18:24:10.132278 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.1, length 46
18:24:10.132301 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.254 is-at 6c:02:e0:82:5b:a0 (oui Unknown), length 28
18:24:10.132351 IP (tos 0x0, ttl 255, id 1080, offset 0, flags [DF], proto UDP (17), length 124)
192.168.1.1.2143 > 192.168.1.254.tftp: [no cksum] TFTP, length 96, RRQ "openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb" octet timeout 5 blksize 1468
18:24:10.132963 IP (tos 0x0, ttl 64, id 44882, offset 0, flags [DF], proto UDP (17), length 47)
192.168.1.254.34161 > 192.168.1.1.2143: [bad udp cksum 0x847c -> 0xaca0!] UDP, length 19
18:24:11.154187 IP6 (flowlabel 0xb00c8, hlim 255, next-header ICMPv6 (58) payload length: 8) fe80::8115:1b49:4fa6:34d0 > ip6-allrouters: [icmp6 sum ok] ICMP6, router solicitation, length 8
18:24:11.175286 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.254 tell 192.168.1.1, length 46
18:24:11.175309 ARP, Ethernet (len 6), IPv4 (len 4), Reply 192.168.1.254 is-at 6c:02:e0:82:5b:a0 (oui Unknown), length 28
18:24:11.175353 IP (tos 0x0, ttl 255, id 1081, offset 0, flags [DF], proto UDP (17), length 124)
192.168.1.1.3186 > 192.168.1.254.tftp: [no cksum] TFTP, length 96, RRQ "openwrt-mediatek-mt7622-linksys_e8450-ubi-initramfs-recovery.itb" octet timeout 5 blksize 1468
18:24:11.175974 IP (tos 0x0, ttl 64, id 44931, offset 0, flags [DF], proto UDP (17), length 47)
192.168.1.254.58873 > 192.168.1.1.3186: [bad udp cksum 0x847c -> 0x4805!] UDP, length 19
once again thanks let me know what im doing wrong, my roomate is already pretty upset haha
This looks like your local TFTP server is sending a very short reply to the device asking for the image. Could be "File not found!" or "Permission denied!" or something like that...
ya thats exactly what it was i put the file in the wrong directory oops. hey thanks daniel i appreciate it. seems to be working just fine now. just gotta do that fix for the 5ghz not working.
The small pads make this approach hard for a beginner, along with the fact that a large number of those dongles have the wrong voltage going out on logic, threatening to fry your nand without a level changer or modifying your dongle.
I also ponder whether the vcc output from one of these adaptors would suffice if the component was still on the board, since might get voltage sagging under the min for that winbond spi-nand?
As for the ECC, I think you can get snander to dump the OOB as well, but calculating it would probably end up being up to one whipping something up.
Goes back to attempting to attach wires to said tiny pads without correct tools
It's 1.27mm pitch pins, so quite a challenge. If you want to avoid soldering, get one of those PCB probe clamps with pogo pins:
Yes, the JTAG header is a much easier solution for most people.
