A diagram from the article, showing the router being used in a car for streaming media to multiple portable devices at once

A Portable DLNA Server Hack Helps You Tame OpenWRT

May 5, 2024 by Arya Voronova 12 Comments

A good amount of hacks can be done with off-the-shelf hardware – what’s more, it’s usually available all over the world, which means your hacks are easier to build for others, too. Say, you’ve built something around a commonly available portable router, through the magic of open-source software. How do you make the fruits of your labour easy to install for your friends and blog readers? Well, you might want to learn a thing or two from [Albert], who shows us a portable DLNA server built around a GL-MT300N-V2 pocket router.

[Albert]’s blog post is a tutorial on setting it up, with a pre-compiled binary image you can flash onto your router. Flash it, prepare a flash drive with your media files, connect to the WiFi network created by the router, run the VLC player app, and your media library is with you wherever you go.

Now, a binary image is good, but are you wondering how it was made, and how you could achieve similar levels of user-friendliness in your project? Of course, here’s the GitHub repository with OpenWRT configuration files used to build this image, and build instructions are right there in the README. If you ever needed a reference on how to make commonly available OpenWRT devices do your bidding automagically, this is it.

This is an elegant solution to build an portable DLNA server that’s always with you on long rides, and, think of it, it handily beats a typical commercialized alternative, at a lower cost. Want software upgrades? Minor improvements and fixes? Security patches? Everything is under your control, and thanks to the open-source nature of this project, you have a template to follow. There won’t always be a perfectly suited piece of hardware on the market, of course, as this elegant dual-drive Pi-based NAS build will attest.

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” →