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.

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.

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