Bits of GRUB syntax on pink background

Wake, Boot, Repeat: Remote OS Selection With GRUB And ESP

What do you do when you need to choose an OS at boot but aren’t physically near your machine? [Dakhnod]’s inventive solution is a mix of GRUB, Wake-on-LAN (WOL), and a lightweight ESP8266 running a simple HTTP server. In the past, [dakhnod] already enlightened us with another smart ESP hack. This one’s a clever combination of network booting and remote control that opens up possibilities beyond the usual dual-boot selector.

At its core, the hack modifies GRUB to fetch its boot configuration over HTTP. The ESP8266 (or any low-power device) serves up a config file defining which OS should launch. The trick lies in adding a custom script that tells GRUB to source an external config:

#!/usr/bin/env cat 
net_dhcp 
source (http,destination_ip_or_host:destination_port)/grub/config

Since GRUB itself makes the HTTP request, the system needs a running web server. That could be a Raspberry Pi, another machine, or the ESP itself. From there, a WOL-enabled ESP button can wake the PC and set the boot parameters remotely.

Is it secure? Well, that depends on your network. An open, unauthenticated web server dishing out GRUB configs is risky, but within a controlled LAN or a VLAN-segmented environment, it’s an intriguing option. Automation possibilities are everywhere — imagine remotely booting test rigs, toggling between OS environments for debugging, or even setting up kiosk machines that reconfigure themselves based on external triggers.

For those looking to take it further, using configfile instead of source allows for more dynamic menu entries, although it won’t persist environment variables. You could even combine it with this RasPi hack to control the uptime of the HTTP server. The balance between convenience and security is yours to strike.

If you’ve got your own wild GRUB customisation, let’s hear it!

Networking History Lessons

Do they teach networking history classes yet? Or is it still too soon?

I was reading [Al]’s first installment of the Forgotten Internet series, on UUCP. The short summary is that it was a system for sending files across computers that were connected, intermittently, by point-to-point phone lines. Each computer knew the phone numbers of a few others, but none of them had anything like a global routing map, and IP addresses were still in the future. Still, it enabled file transfer and even limited remote access across the globe. And while some files contained computer programs, others files contained more human messages, which makes UUCP also a precursor to e-mail.

What struck me is how intuitively many of this system’s natural conditions and limitations lead to the way we network today. From phone numbers came the need for IP addresses. And from the annoyance of having know how the computers were connected, and to use the bang notation to route a message from one computer to another through intermediaries, would come our modern routing protocols, simply because computer nerds like to automate hassles wherever possible.

But back to networking history. I guess I learned my networking on the mean streets, by running my own Linux system, and web servers, and mail servers. I knew enough networking to get by, but that mostly focused on the current-day application, and my beard is not quite grey enough to have been around for the UUCP era. So I’m only realizing now that knowing how the system evolved over time helps a lot in understanding why it is the way it is, and thus how it functions. I had a bit of a “eureka” moment reading about UUCP.

In physics or any other science, you learn not just the status quo in the field, but also how it developed over the centuries. It’s important to know something about the theory of the aether to know what special relativity was up against, for instance, or the various historical models of the atom, to see how they inform modern chemistry and physics. But these are old sciences with a lot of obsolete theories. Is computer science old enough that they teach networking history? They should!

It’s IP, Over TOSLINK!

At the recent 38C3 conference in Germany, someone gave a talk about sending TOSLINK digital audio over fiber optic networks rather than the very low-end short distance fibre you’ll find behind your CD player. This gave [Manawyrm] some ideas, so of course the IP-over TOSLINK network was born.

TOSLINK is in effect I2S digital audio as light, so it carries two 44.1 kilosamples per second 16-bit data streams over a synchronous serial connection. At 1544 Kbps, this is coincidentally about the same as a T1 leased line. The synchronous serial link of a TOSLINK connection is close enough to the High-Level Data Link Control, or HDLC, protocol used in some networking applications, and as luck would have it she had some experience in using PPP over HDLC. She could configure her software from that to use a pair of cheap USB sound cards with TOSLINK ports, and achieve a surprisingly respectable 1.47 Mbit/s.

We like this hack, though we can see it’s not entirely useful and we think few applications will be found for it. But she did it because it was there, and that’s the essence of this game. Now all that needs to happen is for someone to use it in conjunction with the original TOSLINK-over network fiber, for a network-over-TOSLINK-over-network abomination.

38C3: It’s TOSLINK, Over Long Distance Fibre

If you’ve owned a CD player or other piece of consumer digital audio gear manufactured since the 1980s, the chances are it has a TOSLINK port on the back. This is a fairly simple interface that sends I2S S/PDIF digital audio data down a short length of optical fibre, and it’s designed to run between something like a CD player and an external DAC. It’s ancient technology in optical fibre terms, with a lowish data rate and plastic fibre, but consider for a minute whether it could be adapted for modern ultra-high-speed conenctions. It’s what [Ben Cartwright-Cox] has done, and he delivered a talk about it at the recent 38C3 event in Germany.

if you’ve cast you eye over any fibre networking equipment recently, you’ll be familiar with SFP ports. These are a standard for plug-in fibre terminators, and they can be had in a wide variety of configurations for different speeds, topographies, and wavelengths. They’re often surprisingly simple inside, so he wondered if he could use them to carry TOSLINK instead of a more conventional network. And it worked, with the simple expedient of driving an SFP module with an LVDS driver to make a differential signal. There follows a series of experiments calling in favours from friends with data centre space in various locations around London, finally ending up with a 140 km round trip for CD-quality audio.

It’s an interesting experiment, but perhaps the most value here is in what it reveals to us about the way optical networking systems work. Most of us don’t spend our days in data centres, so that’s an interesting technology to learn about. The video of the talk itself is below the break.

Continue reading “38C3: It’s TOSLINK, Over Long Distance Fibre”

The Twisted History Of Ethernet On Twisted Pair Wiring

We all take Ethernet and its ubiquitous RJ-45 connector for granted these days. But Ethernet didn’t start with twisted pair cable. [Mark] and [Ben] at The Serial Port YouTube channel are taking a deep dive into the twisted history of Ethernet on twisted pair wiring. The earliest forms of Ethernet used RG-8 style coaxial cable. It’s a thick, stiff cable requiring special vampire taps and lots of expensive equipment to operate.

The industry added BNC connectors and RG-58 coax for “cheapernet” or 10Base2. This reduced cost, but still had some issues. Anyone who worked in an office wired with 10Base2 can attest to the network drops whenever a cable was kicked out or a terminator was dropped.

The spark came when [Tim Rock] of AT&T realized that the telephone cables already installed in offices around the world could be used for network traffic. [Tim] and a team of engineers from five different companies pitched their idea to the IEEE 802.3 committee on Feb 14, 1984.

The idea wasn’t popular though — Companies like 3COM, and Digital Equipment Corporation had issues with the network topology and the wiring itself. It took ten years of work and a Herculean effort by IEEE committee chairwoman [Pat Thaler] to create the standard the world eventually came to know as 10Base-T. These days we’re running 10 Gigabit Ethernet over those same connectors.

For those who don’t know, this video is part of a much larger series about Ethernet, covering both history and practical applications. We also covered the 40th anniversary of Ethernet in 2020.

Continue reading “The Twisted History Of Ethernet On Twisted Pair Wiring”

It’s Remotely Ham Radio

Have you ever considered running your ham radio remotely? It has been feasible for years but not always easy. Recently, I realized that most of the pieces you need to get on the air remotely are commonplace, so I decided to take the plunge. I won’t give step-by-step instructions because your radio, computer setup, and goals are probably different from mine. But I will give you a general outline of what you can do.

I’m fortunate enough to have a sizeable freestanding shop in my backyard. When I had it built, I thought it was huge. Now, not so much. The little space is crammed with test equipment, soldering gear, laser cutters, drill presses, and 3D printers. I’ve been a ham for decades, but I didn’t have room for the radios, nor did I have an antenna up. But a few months ago, I made space, set some radios up, strung out a piece of wire, and got back on the air. I had so much fun I decided it was time to buy a new radio. But I didn’t want to have to go out to the shop (or the lab, as I like to call it) just to relax with some radio time.

Continue reading “It’s Remotely Ham Radio”

A Month Without IPV4 Is Like A Month Without…

Recently, there was a Mastodon post from [nixCraft] challenging people to drop their NAT routers for the month of November and use only IPv6. What would it be like to experience “No NAT November?” [Alex Haydock] decided to find out.

What did he learn? You’d imagine he’d either wholeheartedly embrace IPv6 or stagger back in and warn everyone not to mess with their configuration. Instead, he recommends you go IPv6 mostly. He notes he is only talking about a home network, not necessarily networks for a big company or an Internet carrier. That’s a different topic.

IPv6 has been around since 1998, but it has been slow to catch on. However, OS support seems universal at this point. [Alex] was able to easily switch on IPv6 only using Windows, macOS, and several Linux flavors. He didn’t use any Android devices, but they should be OK. His iOS phones were fine.

Continue reading “A Month Without IPV4 Is Like A Month Without…”