QUIC! Jump To User Space!

Everyone knows that Weird Al lampooned computers in a famous parody song (It’s All About the Pentiums). But if you want more hardcore (including more hardcore language, so if you are offended by rap music-style explicit lyrics, maybe don’t look this up), you probably want “Kill Dash 9” by Monzy. There’s a line in that song about “You thought the seven-layer model referred to a burrito.” In fact, it refers to how networking applications operate, and it is so ingrained that you don’t even hear about it much these days. But as [Codemia] points out, QUIC aims to disrupt the model, and for good reason.

Historically, your application (at layer 7) interacts with the network through other layers like the presentation layer and session layer. At layer 4, though, there is the transport layer where two names come into play: TCP and UDP. Generally, UDP is useful where you want to send data and you don’t expect the system to do much. Data might show up at its destination. Or not. Or it might show up multiple times. It might show up in the wrong order. TCP solves all that, but you have little control over how it does that.

When things are congested, there are different strategies TCP can use, but changing them can be difficult. That’s where QUIC comes in. It is like a user-space TCP layer built over a UDP transport. There are a lot of advantages to that, and if you want to know more, or even just want a good overview of network congestion control mitigations, check the post out.

If you want to know more about congestion control, catch a wave.

A Month Without IPV4 Is Like A Month Without…

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

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”

Tunneling TCP By File Server

You want to pass TCP traffic from one computer to another, but there’s a doggone firewall in the way. Can they both see a shared file? Turns out, that’s all you need. Well, that and some software from [fiddyschmitt].

If you think about it, it makes sense. Unix treats most things as a file, so it is pretty easy to listen on a local TCP port and dump the data into a shared file. The other side reads the file and dumps the same data to the desired TCP port on its side. Another file handles data in the other direction. Of course, the details are a bit more than that, but that’s the basic idea.

Performance isn’t going to be wonderful, and the files keep growing until the program detects that they are bigger than 10 megabytes. When that happens, the program purges the file.

The code is written in C# and there are binaries for Windows and Linux on the release page. The examples show using shared files via Windows share and RDP, but we imagine any sort of filesystem that both computers can see would work. Having your traffic stuffed into a shared file is probably not great for security but, you know, you are already jumping a firewall, so…

Of course, no firewall can beat an air gap. Unless you can control the fans or an LED.

MS-DOS Meets The Fediverse

By now, most Windows users are set up with decently functional machines running Windows 10 or 11. Of course there are a few legacy machines still lagging behind on Windows 7 or 8 and plenty of computers in industrial settings running ancient proprietary software on Windows XP. But only the most hardcore of IBM PC users are still running DOS, and if you have eschewed things like Unix for this command-line operating system this long you might want to try using it to get online in the Fediverse with Mastodon.

The first step is getting DOS 6.22, the most recent version released in 1994, set up with all the drivers and software needed to access the Internet. At the time of its release there were many networking options so the operating system didn’t include these tools by default. [Stephen] first sets up an emulated NE2000-compatible networking card and then installs the entire TCP/IP stack and then gets his virtual machine set up with an IP address.

With a working Internet connection set up, the next step on the path of exploring federated social media is to install DOStodon (although we might have favored the name “MastoDOS”) which is a Mastodon client specifically built for MS-DOS by [SuperIlu]. There are pre-compiled packages available on its GitHub page for easy installation in DOS but the source code is available there as well. And, if this is your first time hearing about the Fediverse, it is mostly an alternative to centralized social media like Facebook and Reddit but the decentralization isn’t without its downsides.

Network Programming

If you want a book on network programming, there are a few classic choices. [Comer’s] TCP/IP books are a great reference but sometimes is too low level. “Unix Networking Programming” by [Stevens] is the usual choice, but it is getting a little long in the tooth, as well. Now we have “Beej’s Guide to Network Programming Using Internet Sockets.” While the title doesn’t exactly roll off the tongue, the content is right on and fresh. Best part? You can read it now in your browser or in PDF format.

All the topics you’d expect are there in ten chapters. Of course, there’s the obligatory description of what a socket is and the types of sockets you commonly encounter. Then there’s coverage of addressing and portability. There’s even a section on IPV6.

Continue reading “Network Programming”

Bufferbloat, The Internet, And How To Fix It

There’s a dreaded disease that’s plagued Internet Service Providers for years. OK, there’s probably several diseases, but today we’re talking about bufferbloat. What it is, how to test for it, and finally what you can do about it. Oh, and a huge shout-out to all the folks working on this problem. Many programmers and engineers, like Vint Cerf, Dave Taht, Jim Gettys, and many more have cracked this nut for our collective benefit.

When your computer sends a TCP/IP packet to another host on the Internet, that packet routes through your computer, through the network card, through a switch, through your router, through an ISP modem, through a couple ISP routers, and then finally through some very large routers on its way to the datacenter. Or maybe through that convoluted chain of devices in reverse, to arrive at another desktop. It’s amazing that the whole thing works at all, really. Each of those hops represents another place for things to go wrong. And if something really goes wrong, you know it right away. Pages suddenly won’t load. Your VoIP calls get cut off, or have drop-outs. It’s pretty easy to spot a broken connection, even if finding and fixing it isn’t so trivial.

That’s an obvious problem. What if you have a non-obvious problem? Sites load, but just a little slower than it seems like they used to. You know how to use a command line, so you try a ping test. Huh, 15.0 ms off to Google.com. Let it run for a hundred packets, and essentially no packet loss. But something’s just not right. When someone else is streaming a movie, or a machine is pushing a backup up to a remote server, it all falls apart. That’s bufferbloat, and it’s actually really easy to do a simple test to detect it. Run a speed test, and run a ping test while your connection is being saturated. If your latency under load goes through the roof, you likely have bufferbloat. There are even a few of the big speed test sites that now offer bufferbloat tests. But first, some history. Continue reading “Bufferbloat, The Internet, And How To Fix It”