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

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

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

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

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?

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.
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

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”

A Really Low Level Guide To Doing Ethernet On An FPGA

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”