Oh-man! Sars-nCoV-2 bug has even spread to TEW-827DRU routers 
But I'm sure our jmomo will get a vaccine for it sooner or later!
I was looking at the source code for uboot and figured it out.
If you connect a computer's network interface directly to the router it will work fine.
If you only put a switch between the router and your computer it will fail.
So, for the time being, the solution is simple: To use the Recovery Loader you must directly connect your computer to the router. You should not use a switch in between.
If you look at the Trendnet source code under qsdk_gpl/qca/src/u-boot/common/main.c, backup_mode_handle() triggers the recovery loader. It goes through a bunch of functions to initialize the network interfaces and for some reason that's failing and then the UBI gets assembled for some reason I don't yet understand. I need to look into it more. It's probably doing MDIX wrong or something stupid. They might have even done this on purpose, or it's just a bug. I don't know yet.
I may be able to work around it anyway. All I really have to do is disassemble the UBI first.
It might be a week or two before I can work on this again, but for now at least we know what is triggering the issue.
Hi jmomo,
i actually tried all the following methods. The Recovery Loader failed (with the same ipq_nand error) for all of them.
- Directly connect the TEW-827DRU to a laptop running Windows 10 Enterprise.
- Directly connect the TEW-827DRU to a laptop running Windows Server 2019.
- Directly connect the TEW-827DRU to a laptop running ArchLinux (kernel 5.6.8).
- Directly connect the TEW-827DRU to a laptop running Ubuntu 20.04 LTS.
- Connect the the laptop and TEW-827DRU via a switch with or without spanning tree portFast enabled. Enabling portFast allows a port to enter the spanning tree forwarding state immediately, bypassing the listening and learning states.
Best regards.
It's a timing issue and depends on how fast your network interface hardware comes up. That's why it's working for some setups and not working for others.
My cheap testing switch comes up slow. My Pluggable USB network adapter comes up fast. OS won't matter since the speed that the MII/physical layer-1 comes up is mostly dependent upon hardware.
The way Trendnet implemented the Recovery Loader seems really dumb. The main() loop keeps running and they don't break when the reset button is detected.
When the reset button is detected from the main() loop, the backup_mode_handle() func triggers. It then tries to bring up one of the two network interfaces. If it fails you get that "fail WHY" message. If it succeeds the Recovery Loader httpd program gets run and you get the "backup_mode_handle Using ethX device" message.
The problem is that some network interfaces on a computer or switch come up slower than the loop runs and it fails a number of times before seeing a network interface come up. During that time the boot process just keeps going. In your log we can see the UBI gets assembled and the kernel gets read into memory. The same thing happens with my testing switch.
Having the UBI assembled causes the ipq_nand command to fail, and that's why our installer script isn't working when the connected network interface comes up slowly.
I may be able to work around this in the installer script. I'll have to do some testing.
However, some network interfaces could potentially be slow enough that the Recovery Loader never triggers at all, even with the button pressed down. This might explain why I've had a few reports of people not being able to get to the Recovery Loader.
The solution for now is to try a different network adapter or switch and hope it comes up faster.
Unfortunately there is no way to tell if the Recovery Loader is going to fail without having serial console access.
I will update my installation instructions with some new warnings and guidance.
I will also try to find a workaround. It turns out there's no method for disassembling a UBI in this uboot, so this may not be so simple.
Thanks a lot jmomo. From your clear explanations, I believe you have finally nailed down the culprit.
Superficially speaking, just from the look of how Trendnet Recovery GUI shows fake success, I can already tell how horrible their actual Recovery Loader code would be. Proper programming dictates the ability to handle error conditions as much as possible, not simply the ability to run when one particular condition is met. Such problems are also seen in lame code for products from even the biggest commercial companies (not just from a puny one like Trendnet.)
All the laptops (business-class Dell Latitude and Lenovo Thinkpad) I used have built-in Ethernet port, not the thin Ultrabook laptops with only USB-C ports and ugly dangling accessories like USB-Ethernet adapter etc.
Thank you very much for all your time and dedication in resolving issues.
Best regards.
I published a new build which has a workaround for the Recovery Loader bug we have been discussing in this thread:
vochong, thank you for your help in discovering this issue.
The workaround is kinda ugly but it does the job.
1 Like
New v19.07.3 builds have been published here: