Any preliminary tests on how this enclosure performs thermally?
Speaking of thermals,
Does anyone that has opened their RT3200/E8450 to use serial, has repasted SoC? Has this improved the temps?
If I'm in need to open my RT3200 because some screw up on an installer or something, this is what I would do. I have MX-4 paste and PTM7950 and I think it would improve the temps a lot.
Offtopic: what's wrong with the sysupgrade server? It's down from more than 3 days ago. I've never seen that happening.
My unmodified RT3200 AP runs between 56.5 to 61.0 C (from statistics over the last week) depending on load and room temperature, which is around 25 to 26 C.
The RT3200 is among the cooler running of the AP's I've used over the years. The stock case has a good design for natural circulation pulling air in from the bottom and exhausting it out the top.
I have no doubt others have higher and lower temperatures, and different targets that run higher or lower in temperature; however, my main point is I would not bother with modifying anything on an RT3200 to try to lower its running temperature. I think it is fine just as it is.
2 Likes
FWIW, I tried using a USB-A to 12V adapter on this buddy and it keeps rebooting.
The same adapter works for the fibre ONT and an Armbian box.
Cheers.
1 Like
Those adapters give the 12v but very low Amps, that's why the router reboots. The ONT needs less power.
I have an adapter like that to power a fan (we have a lots of power outages on my country) and it can barely move a 140mm fan properly. At least it works on a 90mm fan that moves it really good and works for me with a 20000mAh power bank.
1 Like
Per the USB1/USB2 standard, you'll get 100mA current at most from a USB port prior to negotiation. That's 0.5W, and that's only a small fraction of the power the device needs to power up.
Assuming the adapter can negotiate with the USB host and the USB host approves the USB2 max of 500mA output current, you're still looking at only 2.5W. That's still less than the device needs during boot.
Now, if you have a USB3-PD support and a device that can be configured properly to make the request, that can be instructed to request 12V at the current required to run the device without needing a separate DC-DC converter and without incurring the extra losses such a converter would add. However, the output might need additional filtering to prevent instability.
1 Like
Yes I get that.
There are USB-C PD adapters but they cost much more (~USD4@ vs ~USD0.5@) so I plan to let this buddy uses its own AC/DC adapter and run the other 5V and 12V devices off USB to reduce the use of multiplugs.
Cheers.
You may also want to buy a single 12V 5A adapter and then use this splitter cable: https://www.amazon.com/2-Pack-Power-Splitter-Cable-Cameras/dp/B0186Z7P76
Not yet - as I said I'm doing fitting testing for now to ensure all the buttons, ports, lights, etc. translate well. Once that's done, comes thermal design - though I'm not too worried as this case will be much more breezy than the stock, plus I'm printing it from PETG-CF, which means a bit more tolerance for heat than standard PLA 
@Bartvz thanks! I did look around before cooking up my own, and completely missed this - though to be fair, due to the recent Stratasys drama, I want to avoid using Thingiverse as much as possible. But it will certainly be useful, especially for the port plate.
@eginnc I think NullDev's point was not to optimise temps but to ensure that the device doesn't get baked during use
Yes, I was just curious how the thermals compared to the original enclosure. I usually try not to make an impromptu EasyBake Oven if at all possible. I'm excited to see how the enclosure turns out! I've personally been contemplating external antennas.
Oh trust me I thought about them too. But I have no idea what configuration the stock antennas are, or if there's even any relevance (though the fact that the motherboard has specific ports indicated to specific antenna cable colours suggests that it is indeed relevant).
External antennas would definitely make my job easier. Trying to make slots for these PCB antennas is a PITA.
They should be in the 3d files I linked.
What would be cool is measurements of how external antennae would influence signal strength (eg "og" vs external antennae 3/5/10 m with a clear line of sight and distances with things like walls between the router and the WiFi-device).
This because some people have complained about coverage.
Since OKD is gone,
I think I'm gonna go 4 celling mounted Ubiquiti U6-LR disc style devices for my home with POE splitter fitted into the housing.
Hmm, I might give it a go.
The one you linked doesn't help me much, I'm going for a different approach for my case, and the struggle is getting the right amount of spacing between the PCB and the shell to fit the antennae and the cabling.
@darekxan not a bad idea, you can technically do it with some ease. Though at that point I'd rather buy a new device (I did actually get a Netgear WAX220 which has a dual barrel+PoE power setup, and a slightly better SoC + wireless capability).
With the new repaired "OKD Resolution" I decided to get one of my two e8450s working again.
Router A: Marvin
I got the serial working and the full boot. No problem. I must have done the OKD (with only serial) and the OKD (with full boot) recovery instructions a dozen times without luck. Then, one time ... it worked.
Router B: Benjimouse
I did everything the same ... and no luck. I thought "maybe I did do the 1.1.1 installer?" And borked the router. One generic wireless adapter, no MAC addresses, etc.
Interestingly, restoring a firmware snapshot (from Luci) of Router A fixed Router B. Yes, it pulled in the IPs that were config-ed, but the WiFi MAC addresses came -back-. But it's stuck on the 2.9 bootloader. More interestingly is that the snapshot from Router A does have the 2.10....-3 bootloader.
I need to know what is the SET of information I can provide to people that will help me to IDENTIFY what the status of the router is. Router B is booting like a champ now, and I wonder if I somehow wound up in a "half and half" state that is stable. But, I'm fairly certain that's not possible.
PS- A bonus offer
I think it's fair to say that we need documentation that is clearer than:
"Did you run the v1.1.1 installer (you'd know if you did)" because that is vague af. Careless talk costs lives people.
Are there any CONTENT experts on the OKD who might like to collaborate with me, a total hack(er) who is good at technical writing? Because ... the current OKD section of the Wiki -can- be followed ... mostly .. but while things are CLOSE ... and OFTEN work ... they are vague and don't capture all use cases succinctly.
Oh, and some bonus nachos: the e8450 MAC naming structure. Based on the MACs of my two "bought as a set" box routers, if you lost your original MAC, and need to re-create them, the structure and convention appears to be as follows:
(these are fictitious macs, well ... they prolly belong to someone...lol)
Router 1:
| Interface | MAC Address | Notes |
|---|---|---|
| WAN Port (base sticker) |
D8:EC:5E:DE:AB:5F | Same as base of router |
| LAN Ports (bridge: br-lan) |
D8:EC:5E:DE:AB:60 | Incremented by +1 from the base MAC |
| 2.4 GHz Wi-Fi | D8:EC:5E:DE:AB:61 | Incremented by +2 from the base MAC |
| 5 GHz Wi-Fi | D8:EC:5E:DE:AB:62 | Incremented by +3 from the base MAC |
Router 2:
| Interface | MAC Address | Notes |
|---|---|---|
| WAN Port (base sticker) |
D8:EC:5E:DE:CD:9F | Same as base of router |
| LAN Ports (bridge: br-lan) |
D8:EC:5E:DE:CD:00 | Incremented by +1 from the base MAC |
| 2.4 GHz Wi-Fi | D8:EC:5E:DE:CD:01 | Incremented by +2 from the base MAC |
| 5 GHz Wi-Fi | D8:EC:5E:DE:CD:02 | Incremented by +3 from the base MAC |
This topic contains the information. Prior to the resolution of OKD, steps were posted for 'hard recovery' of the device in case someone were to end up with a completely corrupted flash. That post included a link to both a surrogate/replacement factory partition (which contains the MAC addresses) as well as the locations where they are stored and the numerical order in which they appear. That data does indeed match your findings.
As for identifying the version of the BL2 in use, those instructions were also posted following the resolution of OKD. In short, you can grep for the string '(release)' in mtd0 and it will return the version of the flashed BL2. Combine that with the mtd layout as returned in either the U-Boot variable 'mtdparts' and/or in the dmesg after boot, and that will give you all the details. BL2 + UBI == new all-in-UBI (SNAPSHOT, post installer v.1.1.x) layout; BL2 + FIP + FACTORY + UBI == older UBI layout (23.0.x, pre installer v1.1.x)
Danke. Und, tut mir leid wenn ich kritisch gekluge habe. Ich bin verwirrt und gestresst, weil ich es nicht GANZ hinbekomme.
I've been using the 'hard' serial interface reset with mtkUartBoot. I have poured over this forum, as well as used the instructions that were recently posted to the OpenwrtWiki device page, but I still find them all difficult to follow at the "edge" cases.
As I trudge forward, I'll start compiling more notes, and see if I can develop some instructions that account for all use cases during the recovery process in a way that's perhaps a bit more "If X, then Y, else STOP" kind of format.
Evidently that is the part that is confusing and/or confounding me. I've followed the instructions in the wiki "with a router that is booting" to SSH into the router and grep the release version.
- Benjimouse current state:
- The router was originally UBI Converted (in maybe October 2023) with the then current version of 23.x.x OpenWRT.
- The router indicates it's on BL 2.9, but with a date of July 2024, if that matters, when I grep the bootloader version.
- When allowed to fully boot from internal flash, the router shows the 2.5.4 firmware, which I may have invoked from the commandline using SSH console when it was running and the sysupgrade command.
- The router was booted (using hard/serial recovery uartboot cmdline) and I performed all the instructions as from the Wiki device page for a "serial recovery" and TFT loading.
- I updated the ok... package, "I want a brick" and allowed for writing. I copied and ran the mtd commands.
- (note, the above prolly is missing many steps from both the "if working" and "if hard recovery" steps since I performed them at the time of trying to recover.)
Let me go back to the router tonight and perform all the commands to get the full BL version at the Recovery console, get the current partition layout, and return with a "clear head".
Bis später!
No worries; We all get stressed and frustrated when things are amiss and the information available does not fit.
The BL2 compile date might have been updated if/when you updated the BL2. If you installed the BL2 packaged for release 23.05.4, that would have been v.2.9 with a date of July 2024. The important part here is the version. Any BL2 with v.2.9 prior to the patch (which includes all official releases so far) is at risk of OKD. If your partition layout confirms that you are on the 23.x UBI layout, you should install the BL2 packaged for release 22.03.7 to ensure the router is not at risk of OKD.
1 Like
I updated the https://openwrt.org/toh/linksys/e8450 serial recovery instructions for stable OpenWrt with information to use 22.03.7 (not 23.05.4) preloader.bin.
I'm virtually certain this is correct, as when I flashed the 23.05.4 versions it recovered (presumably by virtue of rewriting the flash), but still had vulnerable versions.
I believe this matches what you wrote up above.
Mostly I'm not certain if bl31-uboot.fip should also be from 22.03.7 instead of 23.05.4
3 Likes