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

October 26, 2024 by Maya Posch 69 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 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.

Raspberry Pi Becomes Secure VPN Router

September 16, 2024 by Bryan Cockfield 20 Comments

OpenWRT is a powerful piece of open-source software that can turn plenty of computers into highly configurable and capable routers. That amount of versatility comes at a cost, though; OpenWRT can be difficult to configure outside of the most generic use cases. [Paul] generally agrees with this sentiment and his latest project seeks to solve a single use case for routing network traffic, with a Raspberry Pi configured to act as a secure VPN-enabled router configurable with a smartphone.

The project is called PiFi and, while it’s a much more straightforward piece of software to configure, at its core it is still running OpenWRT. The smartphone app allows most users to abstract away most of the things about OpenWRT that can be tricky while power users can still get under the hood if they need to. There’s built-in support for Wireguard-based VPNs as well which will automatically route all traffic through your VPN of choice. And, since no Pi router is complete without some amount of ad blocking, this router can also take care of removing most ads as well in a similar way that the popular Pi-hole does. More details can be found on the project’s GitHub page.

This router has a few other tricks up its sleeve as well. There’s network-attached storage (NAS) built in , with the ability to use the free space on the Pi’s microSD card or a USB flash drive. It also has support for Ethernet and AC1300 wireless adapters which generally have much higher speeds than the built-in WiFi on a Raspberry Pi. It would be a great way to build a guest network, a secure WiFi hotspot when traveling, or possibly even as a home router provided that the home isn’t too big or the limited coverage problem can be solved in some other way. If you’re looking for something that packs a little more punch for your home, take a look at this guide to building a pfSense router from the ground up.

Getting Root On Cheap WiFi Repeaters, The Long Way Around

September 5, 2024 by Dan Maloney 13 Comments

What can you do with a cheap Linux machine with limited flash and only a single free GPIO line? Probably not much, but sometimes, just getting root to prove you can is the main goal of a project. If that happens to lead somewhere useful, well, that’s just icing on the cake.

Like many interesting stories, this one starts on AliExpress, where [Easton] spied some low-cost WiFi repeaters, the ones that plug directly into the wall and extend your wireless network another few meters or so. Unable to resist the siren song, a few of these dongles showed up in the mailbox, ripe for the hacking. Spoiler alert: although the attempt on the first device had some success by getting a console session through the UART port and resetting the root password, [Easton] ended up bricking the repeater while trying to install an OpenWRT image.

The second attempt, this time on a different but similar device, proved more fruitful. The rudimentary web UI provided no easy path in, although it did a pretty good job enumerating the hardware [Easton] was working with. With the UART route only likely to provide temptation to brick this one too, [Easton] turned to a security advisory about a vulnerability that allows remote code execution through a specially crafted SSID. That means getting root on these dongles is as simple as a curl command — no hardware hacks needed!

As for what to do with a bunch of little plug-in Linux boxes with WiFi, we’ll leave that up to your imagination. We like [Easton]’s idea of running something like Pi-Hole on them; maybe Home Assistant would be possible, but these are pretty resource-constrained machines. Still, the lessons learned here are valuable, and at this price point, let the games begin.

DEC’s LAN Bridge 100: The Invention Of The Network Bridge

August 27, 2024 by Maya Posch 13 Comments

DEC’s LAN Bridge 100 was a major milestone in the history of Ethernet which made it a viable option for the ever-growing LANs of yesteryear and today. Its history is also the topic of a recent video by [The Serial Port], in which [Mark] covers the development history of this device. We previously covered the LANBridge 100 Ethernet bridge and what it meant as Ethernet saw itself forced to scale from a shared medium (ether) to a star topology featuring network bridges and switches.

Featured in the video is also an interview with [John Reed], a field service network technician who worked at DEC from 1980 to 1998. He demonstrates what the world was like with early Ethernet, with thicknet coax (10BASE5) requiring a rather enjoyable way to crimp on connectors. Even with the relatively sluggish 10 Mbit of thicknet Ethernet, adding an Ethernet store and forward bridge in between two of these networks required significant amounts of processing power due to the sheer number of packets, but the beefy Motorola 68k CPU was up to the task.

To prevent issues with loops in the network, the spanning tree algorithm was developed and implemented, forming the foundations of the modern-day Ethernet LANs, as demonstrated by the basic LAN Bridge 100 unit that [Mark] fires up and which works fine in a modern-day LAN after its start-up procedure. Even if today’s Ethernet bridges and switches got smarter and more powerful, it all started with that first LAN Bridge.

Continue reading “DEC’s LAN Bridge 100: The Invention Of The Network Bridge” →

Ethernet History: Why Do We Have Different Frame Types?

August 23, 2024 by Maya Posch 9 Comments

Although Ethernet is generally considered to be a settled matter, its history was anything but peaceful, with its standardization process (under Project 802) leaving its traces to this very day. This is very clear when looking at the different Ethernet frame types in use today, and with many more historical types. While Ethernet II is the most common frame type, 802.2 LLC (Logical Link Control) and 802 SNAP (Subnetwork Access Protocol) are the two major remnants of this struggle that raged throughout the 1980s, even before IEEE Project 802 was created. An in-depth look at this history with all the gory details is covered in this article by [Daniel].

The originally proposed IEEE 802 layout, with the logical link control (LLC) providing an abstraction layer.

We covered the history of Ethernet’s original development by [Robert Metcalfe] and [David Boggs] while they worked at Xerox, leading to its commercial introduction in 1980, and eventual IEEE standardization as 802.3. As [Daniel]’s article makes clear, much of the problem was that it wasn’t just about Ethernet, but also about competing networking technologies, including Token Ring and a host of other technologies, each with its own gaggle of supporting companies backing them.

Over time this condensed into three subcommittees:

802.3: CSMA/CD (Ethernet).
802.4: Token bus.
802.5: Token ring.

An abstraction layer (the LLC, or 802.2) would smooth over the differences for the protocols trying to use the active MAC. Obviously, the group behind the Ethernet and Ethernet II framing push (DIX) wasn’t enamored with this and pushed through Ethernet II framing via alternate means, but with LLC surviving as well, yet its technical limitations caused LLC to mutate into SNAP. These days network engineers and administrators can still enjoy the fallout of this process, but it was far from the only threat to Ethernet.

Ethernet’s transition from a bus to a star topology was enabled by the LANBridge 100 as an early Ethernet switch, allowing it to scale beyond the limits of a shared medium. Advances in copper wiring (and fiber) have further enabled Ethernet to scale from thin- and thicknet coax to today’s range of network cable categories, taking Ethernet truly beyond the limits of token passing, CSMA/CD and kin, even if their legacy will probably always remain with us.

Portable Router Build: Finding An LTE Modem

August 19, 2024 by Arya Voronova 8 Comments

Ever want your project equipped with a cellular interface for a data uplink? Hop in, I have been hacking on this for a fair bit! As you might remember, I’m building a router, I told you about how I picked its CPU board, and learned some lessons from me daily-driving it as a for a bit – that prototype has let me learn about the kind of extra hardware this router needs.

Here, let’s talk about LTE modems for high data throughput, finding antennas to make it all work, and give you a few tips that should generally help out. I’d like to outline a path that increases your chances of finding a modem working for you wonderfully – the devices that we build, should be reliable.

Narrowing It Down

If you look at the LTE modem selection, you might be a little overwhelmed: Simcom, Qualcomm, uBlox, Sierra, Telit, and a good few other manufacturers package baseband chipsets into modules and adjust the chipset-maker-provided firmware. The modems will be available in many different packages, too, many of them solderable, and usually, they will be available on mPCIe cards too. If you want to get a modem for data connections for a project, I argue that you should go for mPCIe cards first, and here’s why.

Continue reading “Portable Router Build: Finding An LTE Modem” →