Hardware Should Lead Software, Right?

January 20, 2024 by Elliot Williams 26 Comments

Once upon a time, about twenty years ago, there was a Linux-based router, the Linksys WRT54G. Back then, the number of useful devices running embedded Linux was rather small, and this was a standout. Back then, getting a hacker device that wasn’t a full-fledged computer onto a WiFi network was also fairly difficult. This one, relatively inexpensive WiFi router got you both in one box, so it was no surprise that we saw rovers with WRT54Gs as their brains, among other projects.

Of course, some people just wanted a better router, and thus the OpenWRT project was born as a minimal Linux system that let you do fancy stuff with the stock router. Years passed, and OpenWRT was ported to newer routers, and features were added. Software grew, and as far as we know, current versions won’t even run on the minuscule RAM of the original hardware that gave it it’s name.

Enter the ironic proposal that OpenWRT – the free software group that developed their code on a long-gone purple box – is developing their own hardware. Normally, we think of the development flow going the other way, right? But there’s a certain logic here as well. The software stack is now tried-and-true. They’ve got brand recognition, at least within the Hackaday universe. And in comparison, developing some known-good hardware to work with it is relatively easy.

We’re hardware hobbyists, and for us it’s often the case that the software is the hard part. It’s also the part that can make or break the user experience, so getting it right is crucial. On our hacker scale, we often choose a microcontroller to work with a codebase or tools that we want to use, because it’s easier to move some wires around on a PCB than it is to re-jigger a software house of cards. So maybe OpenWRT’s router proposal isn’t backwards after all? How many other examples of hardware designed to fit into existing software ecosystems can you think of?

OpenWRT To Mark 20 Years With Reference Hardware

January 13, 2024 by Jenny List 17 Comments

The OpenWRT project is now two decades old. The project has come a long way since Linksys was forced to release the GNU-licensed code for the original WRT54G router from which the project takes its name. They’ve marked the occasion in an interesting manner: by proposing that the plethora of devices supported by the OS be joined by a fully upstream-supported reference hardware platform.

Spec-wise it’s what you would expect for a hackable router platform in 2024. A MediaTek chipset can be found at its centre, but the hardware is not in this case the important bit. Here will be a platform that won’t have to rely on proprietary manufacturer BLOBs, and which will thus likely continue to have up-to-date kernel support long into the future. So many enticing SBCs fall in this regard, and many retain ossified kernel versions after their manufacturers tire of them as a result.

It appears that the future of this project will be subject to an OpenWRT community vote, and we sincerely hope that it will come to fruition. Meanwhile, we couldn’t resist a peek at the status of the router that started it all, by our reckoning the original WRT54G was last supported by the OS over a decade ago.

Thin Client Wysens Up To Become OpenWrt Router

August 14, 2023 by Jonathan Bennett 26 Comments

For some of us, unused hardware lying around just calls to be used. It seems like [Miles Goodhew] heard the call, and wanted to put a Dell Wyse 3040 thin client to use — in this case as a wireless router. It seems simple enough. OpenWrt supports x64_64 targets, and the thin client has 2G of ram and 8G of flash. It should make for a very capable router.

And before you tell us that it’s just another computer, and that installing OpenWrt on a miniature x86 machine isn’t a hack, note that there were some speedbumps along the way. First off, the motherboard has integrated storage, with the not-very-useful ThinLinux installed, and the system BIOS locked down to prevent reinstall. There is a BIOS clear button on the system’s diminutive motherboard. With the BIOS lock out of the way, a real Linux system can be installed on the small 8 GB mmcblk device.

The next issue the the CPU. It’s an Intel Atom x5 z-series. OpenWrt won’t actually boot on that oddball, not-quite- processor, so [Miles] opted to install Fedora and test via virtualization instead. If that statement makes you do a double-take, you’re not alone. The initial explanation sounded like the mobile-centric processor was missing instructions to make OpenWrt run, but virtualization doesn’t add any instructions for a guest to use. It turns out, the problem is a missing serial port that OpenWrt uses as a debugging output by default.

After a custom OpenWrt compile, the device comes up just as you’d expect, and while it would be underpowered as a desktop, OpenWrt runs happily shuffling bits from Ethernet to wireless adapter at respectable speeds. As [Miles] points out, there’s nothing ground-breaking here, but it’s nice to have the details on re-using these machines compiled in one place. And if you too love the idea of putting OpenWrt in places where nobody intended, we’ve got you covered.

The Meraki AP PCB on a desk, case-less, with three USB-UARTs connected to its pins - one for interacting with the device, and two for monitoring both of the UART data lines.

Flashing Booby-Trapped Cisco AP With OpenWrt, The Hard Way

October 26, 2022 by Arya Voronova 48 Comments

Certain manufacturers seriously dislike open-source firmware for their devices, and this particular hack deals with quite extreme anti-hobbyist measures. The Meraki MR33, made by Cisco, is a nice access point hardware-wise, and running OpenWrt on it is wonderful – if not for the Cisco’s malicious decision to permanently brick the CPU as soon as you enter Uboot through the serial port. This AP seems to be part of a “hardware as a service” offering, and the booby-trapped Uboot was rolled out by an OTA update some time after the OpenWrt port got published.

There’s an older Uboot version available out there, but you can’t quite roll back to it and up to a certain point, there was only a JTAG downgrade path noted on the wiki – with its full description consisting of a “FIXME: describe the process” tag. Our hacker, an anonymous user from the [SagaciousSuricata] blog, decided to go a different way — lifting, dumping and modifying the onboard flash in order to downgrade the bootloader, and guides us through the entire process. There’s quite a few notable things about this hack, like use of Nix package manager to get Python 2.7 on an OS which long abandoned it, and a tip about a workable lightweight TFTP server for such work, but the flash chip part caught our eye.

The flash chip is in TSOP48 package and uses a parallel interface, and an iMX6.LL devboard was used to read, modify and flash back the image — hotswapping the chip, much like we used to do with old parallel-interface BIOS chips. We especially liked the use of FFC cables and connectors for connecting the flash chip to the devboard in a way that allows hotswapping – now that we can see it, the TSOP 0.5 mm pitch and 0.5 mm FFC hardware are a match made in heaven. This hack, of course, will fit many TSOP48-equipped devices, and it’s nice to have a toolkit for it in case you don’t have a programmer handy.

In the end, the AP got a new lease of life, now governed by its owner as opposed to Cisco’s whims. This is a handy tutorial for anyone facing a parallel-flash-equipped device where the only way appears to be the hard way, and we’re glad to see hackers getting comfortable facing such challenges, whether it’s parallel flash, JTAG or power glitching. After all, it’s great when your devices can run an OS entirely under your control – it’s historically been that you get way more features that way, but it’s also that the manufacturer can’t pull the rug from under your feet like Amazon did with its Fire TV boxes.

We thank [WifiCable] for sharing this with us!

(Ed Note: Changed instances of “OpenWRT” to “OpenWrt”.)

Bufferbloat, The Internet, And How To Fix It

August 18, 2022 by Jonathan Bennett 48 Comments

There’s a dreaded disease that’s plagued Internet Service Providers for years. OK, there’s probably several diseases, but today we’re talking about bufferbloat. What it is, how to test for it, and finally what you can do about it. Oh, and a huge shout-out to all the folks working on this problem. Many programmers and engineers, like Vint Cerf, Dave Taht, Jim Gettys, and many more have cracked this nut for our collective benefit.

When your computer sends a TCP/IP packet to another host on the Internet, that packet routes through your computer, through the network card, through a switch, through your router, through an ISP modem, through a couple ISP routers, and then finally through some very large routers on its way to the datacenter. Or maybe through that convoluted chain of devices in reverse, to arrive at another desktop. It’s amazing that the whole thing works at all, really. Each of those hops represents another place for things to go wrong. And if something really goes wrong, you know it right away. Pages suddenly won’t load. Your VoIP calls get cut off, or have drop-outs. It’s pretty easy to spot a broken connection, even if finding and fixing it isn’t so trivial.

That’s an obvious problem. What if you have a non-obvious problem? Sites load, but just a little slower than it seems like they used to. You know how to use a command line, so you try a ping test. Huh, 15.0 ms off to Google.com. Let it run for a hundred packets, and essentially no packet loss. But something’s just not right. When someone else is streaming a movie, or a machine is pushing a backup up to a remote server, it all falls apart. That’s bufferbloat, and it’s actually really easy to do a simple test to detect it. Run a speed test, and run a ping test while your connection is being saturated. If your latency under load goes through the roof, you likely have bufferbloat. There are even a few of the big speed test sites that now offer bufferbloat tests. But first, some history. Continue reading “Bufferbloat, The Internet, And How To Fix It” →

This Week In Security: UClibc And DNS Poisoning, Encryption Is Hard, And The Goat

May 6, 2022 by Jonathan Bennett 8 Comments

DNS spoofing/poisoning is the attack discovered by [Dan Kaminski] back in 2008 that simply refuses to go away. This week a vulnerability was announced in the uClibc and uClibc-ng standard libraries, making a DNS poisoning attack practical once again.

So for a quick refresher, DNS lookups generally happen over unencrypted UDP connections, and UDP is a stateless connection, making it easier to spoof. DNS originally just used a 16-bit transaction ID (TXID) to validate DNS responses, but [Kaminski] realized that wasn’t sufficient when combined with a technique that generated massive amounts of DNS traffic. That attack could poison the DNS records cached by public DNS servers, greatly amplifying the effect. The solution was to randomize the UDP source port used when sending UDP requests, making it much harder to “win the lottery” with a spoofed packet, because both the TXID and source port would have to match for the spoof to work.

uClibc and uClibc-ng are miniature implementations of the C standard library, intended for embedded systems. One of the things this standard library provides is a DNS lookup function, and this function has some odd behavior. When generating DNS requests, the TXID is incremental — it’s predictable and not randomized. Additionally, the TXID will periodically reset back to it’s initial value, so not even the entire 16-bit key space is exercised. Not great. Continue reading “This Week In Security: UClibc And DNS Poisoning, Encryption Is Hard, And The Goat” →

IC Shortage Keeps Linux Out Of Phone Charger, For Now

September 29, 2021 by Tom Nardi 21 Comments

We’ve been eagerly following the development of the WiFiWart for some time now, as a quad-core Cortex-A7 USB phone charger with dual WiFi interfaces that runs OpenWrt sounds exactly like the sort of thing we need in our lives. Unfortunately, we’ve just heard from [Walker] that progress on the project has been slowed down indefinitely by crippling chip shortages.

At this point, we’ve all heard how the chip shortage is impacting the big players out there. It makes sense that automakers are feeling the pressure, since they are buying literally millions of components at a clip. But stories like this are a reminder that even an individual’s hobby project can be sidelined by parts that are suddenly 40 times as expensive as they were when you first put them in your bill of materials.

In this particular case, [Walker] explains that a power management chip you could get on DigiKey for $1.20 USD a few months ago is now in such short supply that the best offer he’s found so far is $49.70 a pop from an electronics broker in Shenzhen. It sounds like he’s going to bite the bullet and buy the four of them (ouch) that he needs to build a working prototype, but obviously it’s a no go for production.

Luckily, it’s not all bad news. [Walker] has made some good progress on the power supply board, which will eventually join the diminutive computer inside the USB charger enclosure. Part of the trick is that the device is still supposed to be a functional USB charger, so in addition to 5 VDC for the output port, the power supply also needs to produce 1.1 V, 1.35 V, 2.5 V, 3.0 V, and 3.3 V for the computer. We’re glad to see he’s taking the high road with his mains circuitry, making sure to use UL listed components and maintaining proper isolation.

When we last checked in on the WiFiWart back in July, [Walker] had already managed to boot Linux on his over-sized prototype board. Now he’s got PCBs in hand that look far closer to the final size and shape necessary to tuck them into a phone charger. It’s a shame that the parts shortage is slowing down progress, but we’re confident we’ll at least get to see a one-off version of the WiFiWart powered up before the year is out.