Satellite Internet On 80s Hardware

February 14, 2025 by Bryan Cockfield 2 Comments

Portability has been a goal of a sizable section of the computing world for many decades now. While the obvious products of this are laptops, there are a number of “luggable” PCs that pack more power while ostensibly maintaining their portability. Going back in time past things like the LAN party era of the 90s and 00s takes us to the early era of luggables, with the Commodore SX-64 being one such machine of this era. Its portability is on display in this video where [saveitforparts] is using it to access the Internet over satellite.

The project uses a Glocom Inmarsat modem and antenna to access the internet through a geostationary satellite, but since this computer is about four decades old now this takes a little bit more effort than a modern computer. A Teensy microcontroller is used to emulate a modem so that the Ethernet connection from the satellite modem can be understood by the Commodore. There was a significant amount of setup and troubleshooting required as well, especially regarding IP addresses and networking but eventually [saveitforparts] got the system up and running well enough to chat on a BBS and browse Wikipedia.

One thing he found that might make a system like this relevant for a modern user is that the text-only mode of the Commodore significantly limited data use. For a normal Internet connection this might be a problem, but on a geostationary satellite network where the data is orders of magnitude more expensive, this can be surprisingly helpful. We might not recommend an SX-64 system specifically, but one inspired by similar computers like this text-only cyberdeck might do the trick with the right networking connections.

Continue reading “Satellite Internet On 80s Hardware” →

Networking History Lessons

January 25, 2025 by Elliot Williams 34 Comments

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!

Forgotten Internet: UUCP

January 16, 2025 by Al Williams 82 Comments

What’s Forgotten Internet? It is the story of parts of the Internet — or Internet precursors — that you might have forgotten about or maybe you missed out on them. This time, we’re looking at Unix-to-Unix Copy, more commonly called UUCP. Developed in the late 1970s, UUCP was a solution for sending messages between systems that were not always connected together. It could also allow remote users to execute commands. By 1979, it was part of the 7th Edition of Unix.

Ken Thompson and Dennis Ritchie may have used UUCP on a PDP-11 like this one. (Photo via Computer History Museum/Gwen Bell)

Operation was simple. Each computer in a UUCP network had a list of neighbor systems. Don’t forget, they weren’t connected, so instead of an IP address, each system had the other’s phone number to connect to a dial up modem. You also needed a login name and password. Almost certainly, by the way, those modems operated at 300 baud or less.

If a computer could dial out, when someone wanted to send something or do a remote execution, the UUCP system would call a neighboring computer. However, some systems couldn’t dial out, so it was also possible for a neighbor to call in and poll to see if there was anything you needed to do. Files would go from one system to another using a variety of protocols.

Continue reading “Forgotten Internet: UUCP” →

A Month Without IPV4 Is Like A Month Without…

December 3, 2024 by Al Williams 89 Comments

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

Ethernet From First Principles

November 16, 2024 by Bryan Cockfield 24 Comments

For someone programming in a high-level language like Python, or even for people who interact primarily with their operating system and the software running on it, it can seem like the computer hardware is largely divorced from the work. Yes, the computer has to be physically present to do something like write a Hackaday article, but most of us will not understand the Assembly language, machine code, or transistor layout well enough to build up to what makes a browser run. [Francis Stokes] is a different breed, though, continually probing these mysterious low-level regions of our computerized world where he was recently able to send an Ethernet packet from scratch.

Continue reading “Ethernet From First Principles” →

When Raw Network Sockets Aren’t Raw: Raw Sockets In MacOS And Linux

September 21, 2024 by Maya Posch 3 Comments

Raw network sockets are a curious beasts, as unless you have a strong urge to implement your own low-level network protocol, it’s a topic that is probably best left to the (well-paid) experts. That said, you can totally use raw sockets in virtually every operating system, but one should be aware of a few things, the lack of portability being one of them. This is what tripped [Swagnik] up while trying to write a low-level network ping (ICMP) utility, by reading the Linux socket documentation while testing on MacOS. It’s all BSD-style sockets, after all, right?

As it turns out, the network stacks in Linux and MacOS have some subtle differences, which become apparent when you read the friendly manuals. For Linux, the raw(7) man entry for IPv4 sockets make it clear that the IP_HDRINCL socket option is default by default for IPPROTO_RAW sockets. This is different from MacOS, which is effectively FreeBSD with glossy makeup. Like FreeBSD, the MacOS man page makes it clear that the IP_HDRINCL option is not set by default.

So that’s easy, right? Just fire off a setsockopt() call on the raw socket and that’s done. Not quite. The Linux man page notes that it cannot receive all IP protocols, while the FreeBSD/MacOS version makes no such exceptions. There is also the issue of endianness, which is where [Swagnik]’s blog post seems to err. The claim is that on MacOS the received IPv4 raw socket header is in host (little endian) order, while the documentation clearly notes that these are in network (big endian) order, which the blog post also shows.

Where things get really fun is when moving from IPv4 raw sockets to IPv6 raw sockets, as [Michael F. Schönitzer] covered for Linux back in 2018 already. IPv6 raw sockets drop IP_HDRINCL and requires a whole different approach. The endianness also changes, as IPv6 raw sockets under Linux must send and will receive data in network byte order, putting it in line with FreeBSD raw sockets.

A Really Low Level Guide To Doing Ethernet On An FPGA

August 14, 2024 by Lewin Day 7 Comments

With so much of our day-to-day networking done wirelessly these days, it can be easy to forget about Ethernet. But it’s a useful standard and can be a great way to add a reliable high-throughput network link to your projects. To that end, [Robert Feranec] and [Stacy Rieck] whipped up a tutorial on how to work with Ethernet on FPGAs.

As [Robert] explains, “many people would like to transfer data from FPGA boards to somewhere else.” That basically sums up why you might be interested in doing this. The duo spend over an hour stepping through doing Ethernet at a very low level, without using pre-existing IP blocks to make it easier. The video explains the basic architecture right down to the physical pins on the device and what they do, all the way up to the logic blocks inside the device that do all the protocol work.

If you just want to get data off an embedded project, you can always pull in some existing libraries to do the job. But if you want to really understand Ethernet, this is a great place to start. There’s no better way to learn than doing it yourself. Files are on GitHub for the curious. Continue reading “A Really Low Level Guide To Doing Ethernet On An FPGA” →