For the vast majority of us, Gigabit Ethernet is more than enough for daily tasks. The occasional big network file transfer might drag a little, but it’s rare to fall short of bandwidth when you’re hooked up over Cat 6. [Brian] has a thirst for saturating network links, however, and decided only 10 Gigabit Ethernet would do.
Already being the owner of a Gigabit Ethernet network at home, [Brian] found that he was now regularly able to saturate the links with his existing hardware. With a desire to run intensive virtual machines on his existing NAS without causing bandwidth issues, it was time for an upgrade. Unfortunately, the cost of rewiring the existing home network to Cat 6 and procuring hardware that could run 10 Gigabit Ethernet over copper twisted pair was prohibitively expensive.
Instead, [Brian] decided to reduce the scope to connecting just 3 machines. Switches were prohibitively expensive, so each computer was fitted with twin 10 Gigabit interfaces, such that it could talk to the two other computers. Rather than rely on twisted pair, the interfaces chosen use the SFP+ standard, in which the network cable accepts electrical signals from the interface, and contains a fiber optic transciever.
[Brian] was able to get the 3 computers networked for just $120, with parts sourced from eBay. It’s an approach that doesn’t scale well; larger setups would be much better served by using a switch and a less zany network topology. But for [Brian], it works just fine, and allows his NAS to outperform a 15,000 RPM server hard disk as far as read rates go.
In an era where everything seems to be getting “smarter” every year, it will probably come as no surprise to find that even relatively middling networking hardware is now packing advanced features and considerable computational power. A case in point is the Dell N1108T-ON Ethernet switch. Despite only costing around $100 USD on the second hand market, [Ben Cox] discovered this particular switch was capable of a lot more than what was advertised by poking around its onboard operating system.
It all started by plugging into the serial port on the front of the switch, which [Ben] happily notes is an integrated FTDI USB serial adapter to make life easy. Booting into recovery mode gave him local shell access, and some poking around determines it’s the sort of BusyBox-powered Linux system that you’d expect on an embedded device. The biggest discoveries were that it was running a relatively recent kernel (3.8.1), and that it apparently had Python installed.
From there, [Ben] found out that these switches have a feature where the administrator can install and run Python “applications” by packaging them up as tarballs and copying them from a USB flash drive. So he wrote up a simple Python program that used the socket library to open up a reverse shell to his desktop computer, and to his surprise, it worked perfectly on the first try. Now with root access, the fun really started.
The next step was getting an SSH installed and running on the switch, so that he didn’t have to do the reverse shell trick every time. He then started installing the packages necessary to turn the switch into a secure VPN tunnel with Wireguard. This took a little fiddling as [Ben] didn’t have the option of installing the normal Wireguard kernel module, but he eventually got the necessary tools modified and cross-compiled to ARM. He believes this is just the start of what’s capable on devices like this, and we’re interested in seeing where the community goes from here.
[Steve] bought a PoE module intended for security cameras and ran a close eye over the board to figure out what kind of hardware it was using to generate the nominal 12 V output. He identified an MP2494 step-down converter, and with the datasheet in hand found how the output voltage is configured by changing the values of resistors in the circuit. Swapping out the stock 21.5 kΩ resistor for a 57.1 kΩ one changed the output of the converter to the 5 V necessary for his electronics.
But of course that was only half of the problem solved; he still had to connect the Ethernet side of the PoE device to the Waveshare LAN8720 board that’s providing Ethernet for the ESP32. So he removed the RJ45 jack from the LAN8720 completely, and wired that directly to the connector on the PoE board. Helpfully, the PoE board had all the pins labeled on the bottom side so this wasn’t nearly as tricky to figure out as you might expect (if only it was always that easy).
In systems where there are multiple participants who need to interact with a shared resource some sort of concurrency protection is usually appropriate. The obvious technique is to use locking (and fun words like “mutex”) but this adds a constant performance hit as every participant needs to spend time interacting with the lock regardless of the number of other participants. It turns out this is actually a Big Problem that garners original research, but there are techniques that can yield great effect without a PhD. Years ago [Marc] posted a great walkthrough of one such method, exponential backoff with jitter, to Amazon’s AWS blog which is a great introduction to one such solution.
The blog post was written specifically to deal systems using a specific technique called optimistic concurrency control (OCC) but that doesn’t mean the advice isn’t generally applicable. OCC refers to a method where each writer checks for a write collision only after performing the write (but before committing it), which works well in scenarios where writes are relatively uncommon. [Marc] observed that even in systems where this is a safe assumption things bog down significantly when there are too many writers clamoring for attention all at once.
The traditional solution to such a problem is for each writer to pause for an exponentially increasing amount of time before trying again, but as writers come back in big groups the same problem can recur. He provides a discussion of simple modifications to that strategy which result in significantly reduced wait times for writers.
Problems like this are not especially relevant for single Arduino sensor networks, but even small groups of systems can have concurrency trouble and it’s nice to see such an accessible write up with solutions which are viable even for simple systems. Bonus points to [Marc] for posting source to his test tool online. It doesn’t require anything outside of your computer to run (no AWS required) so if you have any brainwaves about speeding up multi-writer environments it might make a nice test environment! Maybe don’t mention the blog post in your PhD applications though.
We’ll go out on a limb and assume that anyone reading these words is probably familiar with the classic ping command. Depending on which operating system you worship the options might be slightly different, but every variation of this simple tool does the same thing: send an ICMP echo request and wait for a response. How long it takes to get a response from the target, if it gets one at all, is shown to the user. This if often the very first step to diagnosing network connectivity issues; if this doesn’t work, there’s an excellent chance the line is dead.
But in the modern web-centric view of networking, ping might not give us the whole picture. But nature it doesn’t take into account things like DNS lookups, and it certainly doesn’t help you determine what (if any) services the target has available to you. Accordingly, [Liu Zhiyong] has come up with a tool he calls “pingms”, which allows you to check web server latency right from your browser.
Rather than relying on ICMP, pingms performs a more realistic test. It takes the list of targets from the file “targets.js” and connects to each one over HTTP. How does it work? The code [Liu] has come up with will take each target domain name, append a random number to create a gibberish filename, and then calculate how long it takes to get a response when trying to download the file. Obviously it’s going to be getting a 404 response from the web server, but the important thing is simply that it gets the response.
With this data, [Liu] has come up with a simplistic but very slick interface which shows the user the collected data with easy to understand color-coded graphs. As interesting as it is to see how long it takes your favorite web sites or service providers to wake up and start talking, watching the colored bars hop up and down the list to sort themselves is easily our favorite part of pingms.
When moving into a new house, it’s important to arrange for the connection of basic utilities. Electricity, water, and gas are simple enough, and then it’s generally fairly easy to set up a connection to an ISP for your internet connection. A router plugs into a phone line, or maybe a fiber connection and lovely packets start flowing out of the wall. But if you’re connected to the internet through an ISP, how is the ISP connected? [Kenneth] answers this in the form of an amusing tale.
It was during the purchase of data centre rack space that [Kenneth]’s challenge was laid down by a friend. Rather then simply rely on the connection provided by the data centre, they would instead rely on forging their own connection to the ‘net, essentially becoming their own Internet Service Provider.
This is known as creating an Autonomous System. To do this involves several challenges, the first of which is understanding just how things work at this level of networking. [Kenneth] explains the vagaries of the Border Gateway Protocol, and why its neccessary to secure your own address space. There’s also an amusing discussion on the routing hardware required for such a feat and why [Kenneth]’s setup may fall over within the next two years or so.
It’s not for the faint hearted, and takes a fair bit of paperwork, but [Kenneth] has provided an excellent guide to the process if you really, really just need to own your own corner of the internet. That said, there are other networking tricks to cut your teeth on if you’d like a simpler challenge, like tunneling IP over ICMP.
The mid-1980s were a time of drastic change. In the United States, the Reagan era was winding down, the Cold War was heating up, and the IBM PC was the newest of newnesses. The comparatively few wires stitching together the larger university research centers around the world pulsed with a new heartbeat — the Internet Protocol (IP) — and while the World Wide Web was still a decade or so away, The Internet was a real place for a growing number of computer-savvy explorers and adventurers, ready to set sail on the virtual sea to explore and exploit this new frontier.
In 1986, having recently lost his research grant, astronomer Clifford Stoll was made a computer system admin with the wave of a hand by the management of Lawrence Berkeley Laboratory’s physics department. Commanded to go forth and administer, Stoll dove into what appeared to be a simple task for his first day on the job: investigating a 75-cent error in the computer account time charges. Little did he know that this six-bit overcharge would take over his life for the next six months and have this self-proclaimed Berkeley hippie rubbing shoulders with the FBI, the CIA, the NSA, and the German Bundeskriminalamt, all in pursuit of the source: a nest of black-hat hackers and a tangled web of international espionage.