If you boot with a serial terminal connected to the uart, you can catch the displayed version and date string from the bl2 preloader. If it's v2.9, then you used installer 1.0.3 or newer. Given that the only "newer" is v1.1.1 and also means you would have everything else in UBI and are running the recent snapshot, you'd probably remember having recently done so. If the bl2 is v2.4, then you used installer 1.0.2 or older. If you don't have easy access to the uart, you can also extract bl2 (mtd0) from the device from command line or from the "backup" feature in luci and then use a hex editor to look for the version string within the binary.
Of course, the above relies on the assumption that you have not manually updated the preloader/bl2 after running the installer.
edit: To include jkdf2's solution, you can pass the string 'OpenWrt' as the search pattern for the grep command to pull out the build version details from bl2 (preloader; mtd0).
For instance, the router I recently re-flashed with the same payloads installed by v1.0.2 includes the string v2.4(release):OpenWrt v2021-05-08-d2c75b21-3 (mt7622-snand-1ddr) in the bl2 (mtd0) partition.
My Belkin RT3200 is suffering from the issue of not booting up after upgrading to the latest stable firmware. Usually, I keep it turned off for 10 minutes or so and then I turn it on and it starts booting. Now I find out it was reading the WAN port at only 100MbpS. I unplug/plug the WAN cable multiple time with no luck, so I had to turn it off. After 10 minutes it's no longer booting, so I am now trying what been mentioned here to put it into the refrigerator to cool it down. Just wanted to ask when I try next time shall I switch the power button to ON after plugging the power cable or before or it doesn't make any difference? Thank you.
When you say the WAN port was reading at 100Mb/s, this stands out as potentially a different issue. First of all, do you mean:
The router always reports as 100Mb/s (or slower) even when no cable is connected.
The router only connects at 100Mb/s (or slower) even when connected to a known good 1000Mb/s device.
Something else (please clarify further).
If #1, this indicates the hardware is probably physically damaged, likely due to electric shock. Did you feel a static discharge at some point when connecting a cable?
If #2, check your cable. Cables can go bad for a number of reasons, and 1000Mb/s requires all 8 conductors be in good order. Yes, a cable can be bad even if it works on some devices but not others. Make sure you're using a known good cable, preferably Cat6, and from a reputable supplier.
If #3, please describe the problem in more detail. Have you tried connecting the router to other devices? Does this change the way it responds? Have you tried different cables? Sometimes, like in #2, this can make a difference.
When the router is connected and booted, is it still able to transmit and receive data through the port?
The fact that you're also having boot troubles might indicate a number of things, so we can't yet be sure if it's related to the WAN port issue described. If the router was able to transmit and receive data through the WAN port at the reported speed, then it might be time to skip over that part of the issue for now and look into the boot issue. To prepare for that, do you have a USB to 3.3v serial cable that you can use to connect to the router's serial port? This would mean following the instructions in the wiki to open up the device and connect to the UART so we can see any messages the device is sending out.
Thank you for the detailed reply. Actually I was referring to the speed issue as the cause of the need to reboot my router while suffering from the boot issue being discussed here. I swapped the router cable with my NAS cable and now both ports (WAN and NAS LAN) reading at 1000mbps! So it's #2. Thanks! I have no idea why the NAS is not being affected by this while using the same cable used for the WAN port, but I am happy to report they're both reading at full speed.
I have also now ordered the USB to 3.3v serial cable and will try the steps in the wiki, hopefully I will be able to fix the boot issue as I really want to restart my router regularly. Thanks again.
Answering my own question: I have connected the power plug first, then switch the power button to ON and it took few seconds then it start blinking and working.
That's excellent news. Thank you for the update. Ethernet cables are not made equal, even if they are listed as Cat5e or Cat6. Due to different tolerances and different qualities of hardware, you can find some cables that are borderline in quality that work between certain devices and not between others. This (aside from greed) is part of the reason that trusted manufacturers' cables are more expensive than others. The bargain brand may appear to work well between device A and B but not between B and C, because the bargain cable wasn't put to higher standards of quality. Sadly, even in devices that appear to work, borderline cables often experience issues including speed drops from time to time. These quality issues become more noticeable when the link involving said cable is placed under heavy load.
As for the NAS, consider the hardware in use. Where is the resource bottleneck? Is the network connection faster than the NAS' ability to read and write to its drives and then relay the data to the client? If so, packet loss and/or speed drops might not be as visible. For instance, I have an old Seagate GoFlex Home that I converted to running OpenWRT a few years back. It has a gigabit network port, but the CPU, memory, and single rotational drive are slow. Even using an optimal file transfer protocol, it can't reach 100Mb/s let alone approach 1000Mb/s. Therefore, even if the network link slows down to 100Mb/s, the difference wouldn't ever be noticed.
Glad to hear you have the adapter on the way. The recovery instructions are well written, and the process is surprisingly easy once you've gotten used to the commands. Even if you never need to use it again, it's a compact and cheap tool to keep around in case things go wrong at some point in the future. As always, try to take and safeguard a backup of your router's factory partition if you can, too. That one chunk of data is all you really need to fully recover the router from even the worst case of data corruption.
How can i update? Or should i not?
I'm building always the firmware by myself from "master" branch. My current image is 3 months old (begin Jan 2024)
And i've installed recovery 1.0.2
Do not run the newer master builds without first performing the changes to partitioning. If you do update without the partition changes, your device will be left unable to boot.
The installer v1.1.1 itself is not the issue. All the installer does is simplify the process of updating the partitioning, the preloader image, the .fip with ARM TF-A + U-Boot, and the compatible recovery image.
The real issue behind OKD is something far deeper. Although the newer OpenWRT snapshots set a few parameters that will hopefully solve the issue in part, the full fix (assuming the current theory is the correct one) is waiting on a set of patches that need to be applied to the preloader and U-Boot. Until this happens, the risk will still be there. If you're always building the images yourself, then you may be in a better position to relay valuable data in case something goes wrong. However, the risk of something going wrong is definitely there.
If you wish to accept that risk and move forward anyway, then please take an additional backup copy of the factory partition before you do anything else, especially since it's easier to back it up prior to applying the necessary changes. The content of that one partition will be your key to recovering from even the worst case of data corruption. After that, using the v1.1.1 installer is indeed the easy solution to moving to the newest snapshots.
Thanks, i'm not yet sure if i should proceed with testing. As a replacement i have an old raspberry with openwrt, but without wlan.
My main goal is to test if it helps for my problem Pppoe can't connect unitl i stop it!? (but its unlikely).
... I think i should not change the e8450 but configure the rpi for testing
I suspect that the proposed answer in the other thread is likely correct, but I have very limited experience with PPPoE connections in general. If said answer is indeed correct, I have seen no patches in the snapshot that would alter the behavior.
As an alternative to the solution you proposed there, have you considered using a scheduled task to disconnect the connection for a period of time every night when it is not expected to be in use? If you use a cron job to disconnect, wait x time and then reconnect rather than editing the internal code, that may be enough to make luci happy.
That reads to me like the classic symptoms of OKD. Everything looks good, the preloader found the .fip in UBI space, but it fails to load it successfully. You should be able to recover with the steps listed on the wiki article linked in the post
Follow the instructions in the wiki guide linked in the post. A sysupgrade isn't going to replace the inaccessible fip. It only replaces the base image that is the OS itself. The error you're seeing is that the preloader (bl2) can't load the .fip which contains the full trusted firmware and U-Boot bootloader. bl2 can't directly load OpenWRT. Since it thinks U-Boot is corrupted, it doesn't know how to boot the system and it stalls with the error. This is in essence what OKD (OpenWRT Kiss of Death) is. The funny thing is that the data is almost always there. It's an issue with the technology getting a case of digital dyslexia, so it reads the data wrong and stops. However, when you cleanly read in the data with the commands listed in the wiki and re-write the data into flash, it usually solves the problem.
You are absolutely right, the suggested command on the wiki fixed things perfectly. Many thanks for that.
I really like the RT3200 in so many ways, and I just secured a 5th one, but it is frustrating that it seems rather unreliable. I also have an MT6000 and I have to say that feels like a very nice piece of kit which might be a better choice for reliability.
I have a cable permanently hanging out of the bottom of the RT3200 giving me easy access to the serial port now (based on the idea I saw by somebody else in this thread), and I got myself the clip to connect to the JTAG pins. You can tell how confident I am about the RT3200. On the other hand at least it is possible to get it booting again as you said! Hopefully that JTAG clip isn't really going to be needed, but I got one anyway.
This hardware is more reliable than it appears. Yes, it's a pain that we're dealing with this now, but issues do come up on other systems from time to time as well. The good news is that despite the quirks of the hardware, it takes some serious effort to really kill one of these routers. As long as you have access to mtk_uartboot, the serial adapter, and you have a copy of the factory partition, you can recover the router from any data corruption out there save that resulting from physical damage.
Please try to also keep in mind that this is a running thread handling multiple issues and a lot of discussion around not only the issues, but the device and its capabilities as well. We do have some people with OKD and others that have done damage to the data by fiddling around or by installing something that doesn't match the rest of the flash (i.e. newer snapshots on older bootloaders, etc.) Because most of the issues end up here in the end and it's in our nature to worry about problems we see, it does feel like the risk is higher than it really is.
There is no regular/daily reconnect, the line sometime is connected for more than 100 days. So i does not help to manual reconnect.
German Telekom has an "Assi-A" function which does customer-experiments nightly 3-5am - and sometimes you dont get. These experiments reduce sometime you bandwith "to make it better", but you still have to pay full price
For me my line is now limited to 16mbit upstream even it should be 10 (sync ~12)
But i can not tell if the 5minutes sleep works all time, last night was no reconnect
Had two Linksys E8450s OKD due to a power outage a few weeks back. The restore via mtk_uartboot thru serial adapter restored both of them. I believe I'm running v1.0.2 installer and on 23.05.3.
Few days ago one of the routers had another OKD. This time, I just put it in the freezer for 30 mins to see if that would work based on others success with that method. Surprisingly it works and it booted up again. So that seems to be another way to restore these from OKD.
Telekom calls this 'dynamic port optimisation', Assia is the name of the company the created and sold that system (likely DSLExpresse) to DZS...
The core idea is IMHO pretty sound, most users having suffrred from an instable DSL link will accept trading in some potential throughput for fewer unsolicited resyncs... But the system really operates on a set of heuristics and hence has its share of false positive and negative classifications...
But be that as it may thanks to current law you can request a rebate if an official measurement campaign with the desktop app of breitbandmessung.de documents 'significantly reduced performance'... (The law implies you can pro rate your payments according to the ratio of delivered/contracted rate, but a measurement campaign will not return a single 'delivered rate' number, so you either would need to fight this out before a court or accept whatever the ISP is willing to offer which for Telekom mostly seems to be you keep the current sync but pay 5EUR/month less, effectively paying the price for the next lower plan, with being restricted to that plan's sync limits).
Flipped-around numbers, perhaps? Getting 16 delivered instead of 10 contracted would not really be a problem for most users....
If true, then this will debunk the theory that issue started from the v1.0.3 installer. Did you confirm that your router failed to load bl2 via serial console?
Maybe the issue is with converting flash to UBI over MTD instead of squashfs? From what I read, UBIFS maintains indexes to speed up mounting. Could it be that the UBIFS index has been corrupted during a power trip?
For those facing OKD, do you constantly write into your router’s flash storage, like log files or stats history?
Has anyone been running their RT3200/E8450 using squashfs instead of UBI and also encountered the dreaded OKD?
