Network Hacks

227 Articles

It’s IP, Over TOSLINK!

January 9, 2025 by 19 Comments

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

January 8, 2025 by 12 Comments

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

December 30, 2024 by 54 Comments

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

December 11, 2024 by 32 Comments

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…

December 3, 2024 by 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…” →

The Glacial IPv6 Transition: Raising Questions On Necessity And NAT-Based Solutions

October 26, 2024 by 72 Comments

A joke in networking circles is that the switch from IPv4 to IPv6 is always a few years away. Although IPv6 was introduced in the early 90s as a result of the feared imminent IPv4 address drought courtesy of the blossoming Internet. Many decades later, [Geoff Huston] in an article on the APNIC blog looks back on these years to try to understand why IPv4 is still a crucial foundation of the modern Internet while IPv6 has barely escaped the need to (futilely) try to tunnel via an IPv4-centric Internet. According to a straight extrapolation by [Geoff], it would take approximately two more decades for IPv6 to truly take over from its predecessor.

Although these days a significant part of the Internet is reachable via IPv6 and IPv6 support comes standard in any modern mainstream operating system, for some reason the ‘IPv4 address pool exhaustion’ apocalypse hasn’t happened (yet). Perhaps ironically, this might as [Geoff] postulates be a consequence of a lack of planning and pushing of IPv6 in the 1990s, with the rise of mobile devices and their use of non-packet-based 3G throwing a massive spanner in the works. These days we are using a contrived combination of TLS Server Name Indication (SNI), DNS and Network Address Translation (NAT) to provide layers upon layers of routing on top of IPv4 within a content-centric Internet (as with e.g. content distribution networks, or CDNs).

While the average person’s Internet connection is likely to have both an IPv4 and IPv6 address assigned to it, there’s a good chance that only the latter is a true Internet IP, while the former is just the address behind the ISP’s CG-NAT (carrier-grade NAT), breaking a significant part of (peer to peer) software and services that relied on being able to traverse an IPv4 Internet via perhaps a firewall forwarding rule. This has now in a way left both the IPv4 and IPv6 sides of the Internet broken in their own special way compared to how they were envisioned to function.

Much of this seems to be due to the changes since the 1990s in how the Internet got used, with IP-based addressing of less importance, while giants like Cloudflare, AWS, etc. have now largely become ‘the Internet’. If this is the path that we’ll stay on, then IPv6 truly may never take over from IPv4, as we will transition to something entirely else. Whether this will be something akin to the pre-WWW ‘internet’ of CompuServe and kin, or something else will be an exciting revelation over the coming years and decades.

Header: Robert.Harker [CC BY-SA 3.0].

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

September 21, 2024 by 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.