I know this is an old paperweight to some, but it's the only self-contained battery-powered solution I could find and well, it still works. However, I was running the old Chaos Calmer 15.05 firmware and though the device page suggests compatibility, in any form of kernel+rootfs, init, squash, kernel alone flash sequence (for both gl-mt300n or device-specific tm-05 builds) I have been unable to get beyond a solid blue led after flash.
This channel op showed a successful flash of an older version and a commenter reported similar success with 19.07.2, found here.
Not quite sure what I'm doing wrong here, but there are no green leds for me beyond 19.07.2, despite what the compatibility page reports.
I've been able to go back and forth between the CC build via TFTP to confirm I didn't brick anything with failed build flashes, but open to suggestions on what differences there might be between 19.07.2 and 22.03.2 which are preventing the upgrade.
EDIT - wanted to clarify I was also able to flash 19.07.2 using only the "openwrt-19.07.2-ramips-mt7620-gl-mt300n-squashfs-sysupgrade.bin" renamed to kernel and pushed via tftp - currently functional.
Did you attempt to keep settings when you upgraded from 19.07? You reset the router to defaults before running the upgrade, and then also ensure that the settings are not preserved across the upgrade.
the wiki describes a process mentioning the older 22.03.0.
You mention attempts with 22.03.2.
Have you tried the slightly older 22 releases as well? Or tried any 21 release?
Since you were always able to TFTP-recover without any risk, the only thing you would risk to loose is some personal life time.
Official OpenWrt support was introduced by commit:
and it's first included in OpenWrt 21.02.
This device has a clone which was somewhat supported before: RAVPower RP-WD03.
The initial support of RP-WD03 wasn't as good as it could be and was cleaned up later by @adrianschmutzler and @arrmo.
Read the patch series for the details, which ending here:
You will find the commit: "ramips: fix partitions and boot for RAVPower RP-WD03", and there will be the reason:
The RAVPower RP-WD03 is a battery powered router, with an Ethernet and
USB port. Due due a limitation in the vendor supplied U-Boot bootloader,
we cannot exceed a 1.5 MB kernel size, as is the case with recent builds
(i.e. post v19.07). This breaks both factory and sysupgrade images.
And if you search for that RP-WD03 device, you could find lot of posts about the same: OpenWrt doesn't start after upgrade. E.g.:
Just use the "kernel (squasfs)" as kernel and "rootfs" for rootfs files with TFTP recovery from firmware selector and you are good!
I’ve tried 21 and it’s a no-go.
Which firmware selection are you recommending I use? I tried to the HT-TM05 with squash as kernel and root as rootfs method - it doesn’t work - and I haven’t found any actual posts confirming it has been done successfully elsewhere.
It's interesting what you write.
So you downloaded the < 4K openwrt-22.03.2-ramips-mt7620-hootoo_ht-tm05-squashfs-kernel.bin, the ~ 6 MB openwrt-22.03.2-ramips-mt7620-hootoo_ht-tm05-squashfs-rootfs.bin, fed to TFTP server and doesn't boot?!
That is correct. I can verify via the log viewer and blue led behavior that the files are pushed and the unit attempts to flash, but it appears to soft brick after that (even giving it 5 minutes by timer to work itself out).
I can recover via 19, but have had no success in any configuration or process using 21 or newer.
I've been running OpenWrt on the HT-TM05 for a few years now (looks like the first version I flashed was lede-17.01.4-ar71xx-generic-wzr-hp-g300nh2-squashfs-sysupgrade.bin). I just recently noticed (21.02.2 or so) that it was supported directly and couldn't get it to flash. Went back to using the 19.07 tree for the g300nh2 for a while, and then took another shot when 21.02.0 came out and I realized I was still following the old kernel-only flash instructions from forum threads and didn't t notice the kernel + rootfs renamed files method mentioned above: Latest Firmware (21.02.0-22.03.0) (October 2022)
The last one I TFTP flashed to the HT-TM05 using tftp32.exe from a Windows 10 laptop appears to have been 22.03.0 as filenames kernel and rootfs. I've just recently figured out how to use Image Builder, and I've been rolling my own images and was planning on doing the same for this device and upgrading via sysupgrade.
It sounds like you already figured all that out and are indeed seeing both kernel and rootfs files transfer via TFTP, using the correct IP 10.10.10.254 and subnet 255.255.255.0, etc.? I will mention I generally put a powered on switch in between my laptop and any device I'm attempting to flash via TFTP to keep the link up and the TFTP server running properly. I'm pretty sure after flashing both files the HT-TM05 reboots and autoflashes (vs. the old power it off after kernel transfers and it's asking for rootfs method).
At the risk of throwing my working config away, I'd be willing to try flashing the latest (22.03.2) kernel and rootfs to it if that's helpful. Might take me a couple days to actually do it.
On a side note, these are fun little units. I had a spare one that would glitch and frequently power-off when I squeezed the top section around the ethernet port. HooToo (Sunvalley) sent me a replacement unit and let me keep the old flakey one, which I used as a "dev" box for years until just recently when it finally gave up the ghost completely. I opened it up and found the ground wire from the battery control unit to the daughter board had broken free, and it still doesn't work after soldering that back up.
I recently added a Comfast CF-926AC V2 for 802.11 AC and mesh support and it works great at that. For some reason the internal Wi-Fi chip (also an MT7620) should support mesh, but doesn't seem to actually join the network. Others have mentioned similar issues with some MT7620 boards, but I'd have to hunt to find where I saw that.
@daber I noticed two differences in our rigs 1) you're using a powered switch in between and 2) you're using tftp32
I dusted off an old powered switch and tried 23.03.0 with tftp64 (as you indicated you have successfully loaded this one) - unfortunately, same result...fast blue led flash, slower led flash, solid blue led, and soft brick. Upon resetting it has been / does seem to try and flash again with the same led sequence.
I wouldn't think tftp64 vs tftp32 as the culprit, given I'm able to load other variants (as I type this on my laptop through the unit in client mode via my phone hotspot, reverted back to 19.07.9).
Good to know I'm not the only one who saves old equipment @arrmo
EDIT: welp, I tried one more time with 23 and instead loaded the rootfs after it asked for it, but not sure this made a difference. However, I was a little more patient with trying to access after setting IP to 192.168.1.20 (as domg suggested in his thread) and that appeared to work, as I have access. The led behavior is wild... and it's not issuing an IP nearly as fast as it used to... so there's a bit of a learning curve. I suspect the dev's are attempting to use the led as more of an activity display as opposed to the state display we may be used to. Boot time is certainly much slower than 19...
Sorry, I don't understand how did you do the TFTP recovery now.
OR how did the TFTP recovery previously?
As @daber wrote the TFTP recovery changed for the newer releases: both kernel and rootfs files have to be downloaded and be served through TFTP.
Looks like it takes more time:
The TM-HT05 will grab the kernel file and then the rootfs file and start flashing them. This takes some time 2-3 mins.
And after the long flash the very first boot is also a long shot.
Ditto,I am curious if @jpgeer wants to spell it out, but if I had to speculate I'd say maybe just really closely following the directions to a T and being a little more patient with the flashing post-TFTP? Glad you got it working though.
It's a fun little device. I used it natively with the out-of-box firmware for a few years but never really needed what it provided. I sort of wished I could just OpenWrt, and one day I noticed people were YOLOing the gl-mt300n firmware on there. So I tried it and never looked back. The only thing I don't (didn't?) really enjoy with the native OpenWrt functionality is that if you've got it in Configure A(ccess) P(oint or 'hotspot') + STA(tion or 'client') mode:
When the hotspot is not available or it is incorrectly defined in the wireless configuration file, OpenWrt will disable the AP. This means that you can only access your OpenWrt device through its Ethernet port.
I played with the wwanHotspot script for a while, which worked fine, I just found editing the /etc/config/wwanHotspot file on the go to be tiresome, though that could be improved since I played with it last. I also see the is a section for 3. Revert to AP Only mode on boot when Hotspot is not available, which I don't recall being there when I previously looked.
As I mentioned I had trouble using the build-in Wi-Fi chip for mesh, has anyone had success? I have mesh working otherwise with similar chipset devices, and I was able to join the mesh after adding that Comfast USB adapter, so it's not something obvious I'm doing wrong. With this dual Wi-Fi solution the lack AP + STA issue is less of a problem for me.
@xabolcs yep, fresh and clean, ready for a second life as a client bridge
@daber i understand the tftp for 19 and below is different than for 21 and above. What I was attempting to sort is whether there was process adjustment I needed to make (in addition to your "powered switch in between") for the kernel + rootfs so I tried something a little different where I loaded the kernel into the tftp directory, then waited for the device to start looking for the rootfs - at which point I dragged the rootfs file into the directory and the device pulled it over. All of which might be pointless given all of my testing with previous flashes (after the flash) was expecting the new 21 and up to give me an IP, where domg suggested setting a static to 192.168.1.20 instead (which I finally got to work). I was not expecting a start-up behavior like what I witnessed (solid blue, fast flash, slow flash, solid blue and no activity on the ports), combined with the inability to auto obtain the IP, which prompted me to preemptively declare "soft brick"... in reality, they may not have been bricked at all...
I know this is an old post but wanted to share my experience.
I had previously installed Chaos Calmer 15 version but messed up the setting so I re-flashed it with the latest Oct 22 firmware.
The latest firmware was very unstable - the IP address would switch between 10.10.10.254 (suggesting it booted from the old firmware??) and the new IP every time it was rebooted. It's internet connection was also unstable, losing about half the packets when pinging 8.8.8.8. It meant that I couldn't fully execute opkg update. Frankly it was unusable.
I decided to go back to Chaos Calmer 15 install which is more stable. However I still couldn't execute opkg update - at all. I think (and I'm a total n00b here) because of the hardware limitation it doesn't include a lot of packages and I couldn't run any commands either through LuCi or SSH. If I am wrong I'd love to hear how I can make it work.
At least thanks to the wiki I could set it up as a wireless router though these days it seems less useful.
Unless this device is a dual partition device, that seems extremely unlikely.
This may be 'stable' on your device, but it is not safe. There are many serious known vulnerabilities in previous versions of OpenWrt -- this one is 8 years old and has been EOL and unsupported (and unpatched) probably more than half a decade. This should not be used on the internet under any circumstances.
According to the device info page, this product has 8MB flash + 64MB RAM, which is sufficient to run 22.03. I'd recommend trying this version again, but it is an absolute requirement to reset to defaults and then configure from scratch. If you attempted to keep your old settings, that would absolutely explain the issues you were seeing.
Thank you. Tried again and it's the same problem. I am going through the flashing process but it seems to not wipe out certain info - the name I gave the router before is preserved according to my laptop's network connections setting. Sorry for a basic question but shouldn't the flashing process wipe out everything or do I need to do something to make sure everything is reset somehow?
. Whatcha thinking?
