Imagine the Internet had begun its life as a proprietary network from a major software vendor rather than evolved as a distributed network shared by researchers. It’s a future that almost came to pass for consumers in the 1990s when walled gardens such as AOL or the original incarnation of MSN were all the rage, but thankfully the world took the Internet course.
At its heart is spam, or indeed the heavy-handed measures taken by large email providers to combat it. Spotting and canning spam is computationally expensive, so the easiest way to stop a spammer is to recognize their activity and block it at the network level. Thus a large email provider will instantly block large IP ranges when it detects they hold a spammer, with the collateral damage of also blocking any legitimate email servers in the same range such that their mail just doesn’t get through. Since spam is such a widespread problem, as [Carlos] points out it’s less of a case of if your server has this problem, but when. This functions essentially as something of a racket, in which large email providers have the power to ensure that any email not generated from amongst themselves is unlikely to reach any of the millions of addresses under their care, and the only recourse an operator of a small email domain has is to use the services of one of them.
He has something of a manifesto as to how this problem can be addressed, and we think that it’s important enough that you should take a look. Maintaining email as something beyond the control of large providers is too important not to.
A few days ago we covered a project that brought Ethernet connectivity to the Raspberry Pi Pico using little more than some twisted pair and a RJ-45 connector. It was a neat trick, but not exactly ready for widespread adoption. Looking to improve on things a bit, [tvlad1234] has taken that project’s code and rewritten it into a friendly library you can use with any RP2040 board.
In case you missed it, the initial demo did 10BASE-T transmission by bit-banging with the PIO, and was able to send UDP messages to devices on the wired LAN. It was an impressive accomplishment, but its code didn’t make it easy to build your project around it. This new library makes UDP messaging as easy as a printf, offloading all non-PIO-managed Ethernet signal work onto the RP2040’s second CPU core. The library even generates a random MAC address out of your flash chip’s serial number!
As a demonstration of the new library, [tvlad1234] has put together a simple Ethernet-connected temperature monitor using the BMP085 or BMP180 sensor connect over I2C. If you feel like you could use an Ethernet transmit-only sensor in your life, browsing the source code would be a great start.
Whilst the Raspberry Pi RP2040 is quite a capable little chip, on the whole it’s nothing really special compared to the big brand offerings. But, the PIO peripheral is a bit special, and its inclusion was clearly a masterstroke of foresight, because it has bestowed the platform all kinds of capabilities that would be really hard to do any other way, especially for the price.
Our focus this time is on Ethernet, utilizing the PIO as a simple serialiser to push out a pre-formatted bitstream. [kingyo] so far has managed to implement the Pico-10BASE-T providing the bare minimum of UDP transmission (GitHub project) using only a handful of resistors as a proof of concept. For a safer implementation it is more usual to couple such a thing magnetically, and [kingyo] does show construction of a rudimentary pulse transformer, although off the shelf parts are obviously available for this. For the sake of completeness, it is also possible to capacitively couple Ethernet hardware (checkout this Micrel app note for starters) but it isn’t done all that much in practice.
UDP is a simple Ethernet protocol for transferring application data. Being connection-less, payload data are simply formatted into a packet buffer up front. This is all fine, until you realize that the packets are pretty long and the bitrate can be quite high for a low-cost uC, which is why devices with dedicated Ethernet MAC functionality have a specific hardware serialiser-deserialiser (SERDES) block just for this function.
Like many small uC devices, the RP2040 does not have a MAC function built in, but it does have the PIO, and that can easily be programmed to perform the SERDES function in only a handful of lines of code, albeit only currently operating at 10 MBit/sec. This will cause some connectivity problems for modern switch hardware, as they will likely no longer support this low speed, but that’s easily solved by snagging some older switch hardware off eBay.
As for the UDP receive, that is promised for the future, but for getting data out of a remote device over a wired network, Pico-10BASE-T is a pretty good starting point. We’ve seen a few projects before that utilize the PIO to generate high speed signals, such as DVI, albeit with a heavy dose of overclocking needed. If you want a bit more of an intro to all things Pico, you could do worse than check out this video series we highlighted a while back.
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”→
[Matt Keeter], like many of us, has a lot of network-connected devices and an oscilloscope. He decided he wanted to look into what was on the network. While most of us might reach for Wireshark, he started at the PCB level. In particular, he had — or, rather, had someone — solder an active differential probe soldered into an Ethernet switch. The scope attached is a Textronix, but it didn’t have the analyzer to read network data. However, he was able to capture 190+ MB of data and wrote a simple parser to analyze the network data pulled from the switch.
The point of probing is between a network switch and the PHY that expands one encoded channel into four physical connections using QSGMII (quad serial gigabit media-independent interface). As the name implies, this jams four SGMII channels onto one pair.
As is common in networking schemes, the 8-bit byte is encoded into a 10-bit code group to ensure enough bit transitions to recover the synchronous clock. The decoding software has to examine the stream to find framing characters and then synchronize to the transmitted clock.
What follows is a nice tour of the protocol and the Python code to decode it. It seems complex, but the code is fairly short and also executes quickly. The output? Pcap files that you can process with Wireshark. Overall, a great piece of analysis. He also points out there are other tools already available to do this kind of decoding, but what fun is that?
Wireshark can do a lot of different kinds of analysis, even if you aren’t usually capturing from a scope. You can even decrypt SSL if you know the right keys.
[Jeff] demonstrates how easy it is to get two CM4 modules to synchronize to within a few tens of nanoseconds in the video below the break. That alone can be very useful on many projects. But if you want really stable and absolute time, you need a stratum 1 external source. These time servers, called grandmasters in PTP nomenclature, have traditionally been specialized pieces of kit costing tens of thousands of dollars, using precision oscillators for stability and RF signals from stratum 0 devices like navigation satellites or terrestrial broadcast stations to get absolute time. But as Lasse Johnsen, who worked on the kernel updates remarks in the video:
In 2022 these purpose-built grandmaster clocks from the traditional vendors are about as relevant as the appliance web servers like the Raq and Qube were back in 1998.
It is now possible to build your own low-cost stratum 1 time server in your lab from open source projects. Two examples shown in the video. The Open Time Server project’s Timecard uses a GNSS satellite receiver and a Microchip MAC-SA5X Rubidium oscillator. If that’s overkill for your projects or budget, the Time4Pi CM4 hat is about to be release for under $200. If accurate time keeping is your thing, the technology is now within reach of the average home lab. You can also add PTP to a non-CM4 Raspberry Pi — check out the Real-Time HAT that we covered last year.
How fast is your Internet connection? The days of 56K modems are — thankfully — long gone for most of us. But before you get too smug with your gigabit fiber connection, have a look at what researchers from the Network Research Institute in Japan have accomplished. Using a standard diameter fiber, they’ve moved data at a rate of 1 petabit per second.
The standard fiber has four spatial channels in one cladding. Using wavelength division multiplexing, the researchers deployed a total of 801 channels with a bandwidth over 20 THz. The fiber distance was over 50 km, so this wasn’t just from one side of a lab to another. Well if you look at the pictures perhaps it was, but with big spools of fiber between the two lab benches. The project uses three distinct bands for data transmission with 335 channels in the S-band, 200 channels in the C-band, and 266 channels in the L-band.
To put this into perspective, a petabit — in theory — could carry a million gigabit Ethernet connections if you ignore overhead and other losses. But even if that’s off by a factor of 10 it is still impressive. We can’t imagine this will be in people’s homes anytime soon but it is easy to see the use for major backhaul networks that carry lots of traffic.