OpenWRT, But On An Unsupported Router

Everyone likes something cheap, and when that cheap thing is a router that’s supported by OpenWRT, it sounds like a win. [Hennung Paul] ordered a Wavlink WL-WN586X3 for the princely sum of 39 Euros, but was disappointed to find his device a rev. 2 board rather than the rev.1 board supported by the Linux distribution. Toss it on the failed projects pile and move on? Not at all, he hacked together a working OpenWRT for the device.

It’s fair to say that a majority of Hackaday readers will  have familiarity with Linux, but that’s something which runs on a sliding scale from “Uses Ubuntu a bit” all the way to “Is at one with the kernel”. We’d rate ourselves somewhere around halfway along that scale in terms of having an in-depth knowledge of userland and a working knowledge of some of the internals which make the operating system tick even if we’re apprehensive about tinkering at that level. [Henning] has no such  limitations, and proceeds to take the manufacturer’s distribution, itself a heavily modified OpenWRT, and make it his own. Booting over tFTP we’re used to, and we’re particularly impressed to see him using a Raspberry Pi as a surrogate host for the desoldered Flash chip over SPI.

It’s a long path he takes to get the thing working and we’re not sure we could follow it all, but we hope that the result will be a new device added to OpenWRT’s already extensive support list. It’s sometimes a shock to find this distro is now over two decades old.

Optimizing Your Linux Shell Experience

Are you familiar with Huffman encoding? That’s where you pick shorter codes for more frequent letters. Morse code is the same way, in that the most-used letters are the shortest. [Matheus Richard] had the same idea for optimizing your workflow in the Linux shell. The idea is to measure what commands you use the most and make them shorter.

Continue reading “Optimizing Your Linux Shell Experience”

A Potential Exploit With The Ext Filesystem

The extended filesystem, otherwise known as ext, has been a fundamental part of Linux since before the 1.0 release in 1994. Currently the filesystem is on its fourth major revision, in use since its release in 2008 thanks to its stability, reliability, and backwards compatibility with the other ext filesystem versions. But with that much history there are bound to be a few issues cropping up here and there. [Will] recently found an exploit with this filesystem that can cause a Linux kernel to immediately panic when a manipulated USB drive is inserted into a computer.

[Will] discovered this quirk when investigating the intricacies of the filesystem for problems and other vulnerabilities. A tool called tune2fs, used for administering and modifying ext filesystems, includes the ability to pass certain commands to the Linux kernel when certain situations arise with the filesystem itself, including that the kernel should panic. One situation is that the ext filesystem itself becomes corrupted, which can then cause the kernel panic. Armed with this knowledge, a USB drive can be purposefully given a corrupted ext filesystem which, when plugged into a Linux machine, can cause the computer to shut down.

The post linked above goes into some discussion about how this exploit could be used maliciously to gain access to a Linux system, including rebooting computers where no access to a power button is otherwise enabled or making other changes to the system before needing a reboot to apply the changes. In general, though, it’s good to assume an attacker could take any route to gain access to a machine. This exploit from a few years ago, for example, allowed another Linux tool to be used to gain root access.

Thanks to [Timothy] for the tip!

Smartphone Runs Home Server

It’s one of the great tragedies of our technological era. Smartphones that feature an incredible amount of computational power compared to computers the past, are largely locked down by carriers or manufacturers, dooming them to performing trivial tasks far below their true capabilities.

But there is hope. In part one of this build, a OnePlus 6T is stripped of its Android operating system in favor of postmarketOS, a Linux distribution based on Alpine designed for a number of Android phones and tablets as well as some Linux-only handhelds. The guide also demonstrates how to remove the battery and use a modified USB-C cable to essentially trick the battery management system into powering up the phone anyway. The second part of the project dives into the software side, getting the Linux system up and running before installing Docker and whichever Docker containers the user needs.

There are a few downsides to running a server from a smartphone. Although there’s plenty of processing power available for a wide range of applications, most phones won’t have Ethernet support out-of-the-box which forces the use of WiFi. There’s also limited storage options available, so a large NAS system may be out of reach. But for something like a home automation system or a music streaming server this could put plenty of older devices to work again. And if you don’t want to hunt for an Android phone that isn’t completely hobbled out-of-the box you might want to try a phone that’s Linux-based from the get-go instead.

Thanks to [JohnU] for the tip!

FLOSS Weekly Episode 811: Elixir & Nerves – Real Embedded Linux

This week, Jonathan Bennett and Lars Wikman chat about Elixir and Nerves — a modern language that’s a take on Erlang, and an embedded Linux approach for running Elixir code on devices.

Subscribe to catch the show live, and come to Hackaday for the rest of the story!

Continue reading “FLOSS Weekly Episode 811: Elixir & Nerves – Real Embedded Linux”

Linux Fu: Audio Network Pipes

Life was simpler when everything your computer did was text-based. It is easy enough to shove data into one end of a pipe and take it out of the other. Sure, if the pipe extends across the network, you might have to call it a socket and take some special care. But how do you pipe all the data we care about these days? In particular, I found I wanted to transport audio from the output of one program to the input of another. Like most things in Linux, there are many ways you can get this done and — like most things in Linux — only some of those ways will work depending on your setup.

Why?

There are many reasons you might want to take an audio output and process it through a program that expects audio input. In my case, it was ham radio software. I’ve been working on making it possible to operate my station remotely. If all you want to do is talk, it is easy to find software that will connect you over the network.

However, if you want to do digital modes like PSK31, RTTY, or FT8, you may have a problem. The software to handle those modes all expect audio from a soundcard. They also want to send audio to a soundcard. But, in this case, the data is coming from a program.

Of course, one answer is to remote desktop into the computer directly connected to the radio. However, most remote desktop solutions aren’t made for high-fidelity and low-latency audio. Plus, it is nice to have apps running directly on your computer.

I’ll talk about how I’ve remoted my station in a future post, but for right now, just assume we want to get a program’s audio output into another program’s audio input. Continue reading “Linux Fu: Audio Network Pipes”