10 Gigabit Ethernet For The Pi

When people like Bell and Marconi invented telephones and radios, you have to wonder who they talked to for testing. After all, they had the first device. [Jeff] had a similar problem. He got a 10 gigabit network card working with the Raspberry Pi Compute Module. But he didn’t have any other fast devices to talk to. Simple, right? Just get a router and another network card. [Jeff] thought so too, but as you can see in the video below, it wasn’t quite that easy.

Granted, some — but not all — of the hold-ups were self-inflicted. For example, doing some metalwork to get some gear put in a 19-inch rack. However, some of the problems were unavoidable, such as the router that has 10 Gbps ports, but not enough throughput to actually move traffic at that speed. Recabling was also a big task.

Continue reading “10 Gigabit Ethernet For The Pi”

Just How Did 1500 Bytes Become The MTU Of The Internet?

[Benjojo] got interested in where the magic number of 1,500 bytes came from, and shared some background on just how and why it seems to have come to be. In a nutshell, the maximum transmission unit (MTU) limits the maximum amount of data that can be transmitted in a single network-layer transaction, but 1,500 is kind of a strange number in binary. For the average Internet user, this under the hood stuff doesn’t really affect one’s ability to send data, but it has an impact from a network management point of view. Just where did this number come from, and why does it matter?

[Benjojo] looks at a year’s worth of data from a major Internet traffic exchange and shows, with the help of several graphs, that being stuck with a 1,500 byte MTU upper limit has real impact on modern network efficiency and bandwidth usage, because bandwidth spent on packet headers adds up rapidly when roughly 20% of all packets are topping out the 1,500 byte limit. Naturally, solutions exist to improve this situation, but elegant and effective solutions to the Internet’s legacy problems tend to require instant buy-in and cooperation from everyone at once, meaning they end up going in the general direction of nowhere.

So where did 1,500 bytes come from? It appears that it is a legacy value originally derived from a combination of hardware limits and a need to choose a value that would play well on shared network segments, without causing too much transmission latency when busy and not bringing too much header overhead. But the picture is not entirely complete, and [Benjojo] asks that if you have any additional knowledge or insight about the 1,500 bytes decision, please share it because manuals, mailing list archives, and other context from that time is either disappearing fast or already entirely gone.

Knowledge fading from record and memory is absolutely a thing that happens, but occasionally things get saved instead of vanishing into the shadows. That’s how we got IGNITION! An Informal History of Liquid Rocket Propellants, which contains knowledge and history that would otherwise have simply disappeared.

Linux Fu: A Little Bit Of (Network) History Repeating Itself

These days, embedded systems often have networks and that can make them significantly more complex. Networks are usually pretty nondeterministic and there are a variety of oddball conditions. For example, when your public-access pick and place machine gets written up on Hackaday and you suddenly get a 50X surge in traffic, how does your network stack handle it? While there’s no silver bullet for network testing, there are some tricks that can make it easier and one of those is the tcpreplay utilities that allow you to record complex network traffic and then play it back in a variety of ways. This has many benefits, especially if you manage to capture that one thing that triggers bad behavior sporadically. Being able to play it back on demand can speed up diagnostics considerably.

General Idea

You probably know that tcpdump allows you to grab packet captures from a network interface and save them to a file. If you prefer a GUI, you probably use Wireshark, which uses the same underlying library (libpcap) to grab the data. In fact, you can capture data using tcpdump and look at it with Wireshark, although there are other tools like tcptrace or Ngrep that can work with the output, also.

While the output of the command can be a little cryptic without tool support, a program called tcpreplay can take that data and feed it back in a variety of ways. Of course, you can modify the file first — there are tools to make that easier and — if you need to — you can craft your own network traffic by hand or using one of a variety of tools. This process is often called “packet crafting.”

Continue reading “Linux Fu: A Little Bit Of (Network) History Repeating Itself”

Experiment With SFP Modules With This Handy Breakout

While most home networking hardware comes with network ports baked in from the factory, industrial grade gear is typically more versatile. Using standards like Small Form-factor Pluggable, or SFP, network switches can be used with a variety of transport mediums by simply swapping tranceivers in and out. These network devices typically handle the nitty gritty of transmitting Ethernet over fiber optics, and for those keen to experiment, this breakout may come in handy.

The board design comes complete with an SFP receptacle, allowing a variety of compatible receivers to be plugged in for experimentation. With the standard using differential signalling, the board carries hardware to allow the transceiver to be fed with single-ended signals instead, though a differential version is available too. The board can be used for transmitting different signals over fiber, outside just Ethernet, or used as a simple way to reprogram SFP modules via I2C. The latter can be useful to get around DRM in network switches that attempt to lock out generic transceiver modules.

It’s a useful piece of hardware for the fiber optic tinkerer and network admin alike. You might also find it useful if you’re building your own 10-gigabit network at home!

Basics Of Remote Cellular Access: Connecting Via VPN

You’ve got a machine hooked up to the Internet via a shiny new cellular modem, which you plan to administer remotely. You do a quick check on the external IP, and try and log in from another PC. Try as you might, SSH simply won’t connect. What gives?

The reality of the modern internet is that most clients no longer get their own unique IPv4 address. There simply aren’t enough to go around anymore. Instead, most telecommunications operators use Carrier Grade Network Address Translation which allows a single external address to be shared by many customers. This can get in the way of direct connection attempts from the outside world. Even if that’s not the case, most cellular operators tend to block inbound connections by default. However, there is a way around this quandary – using a VPN. Continue reading “Basics Of Remote Cellular Access: Connecting Via VPN”

Leaking Data Slowly By Switching Ethernet Speeds

Airgapping refers to running a machine or machines without connections to external networks. Literally, a gap of air exists between the machine and the outside world. These measures present a challenge to those wishing to exfiltrate data from such a machine, leading to some creative hacks. [Jacek] has recently been experimenting with leaking data via Ethernet adapters.

The hack builds on [Jacek]’s earlier work with the Raspberry Pi 4, in which the onboard adapter is rapidly switched between 10 and 100 Megabit modes to create a signal that can be picked up via radio up to 100 meters away. Since then, [Jacek] determined the Raspberry Pi 4, or at least his particular one, seems to be very leaky of RF energy from the Ethernet port. He decided to delve deeper by trying the same hack out on other hardware.

Using a pair of Dell laptops connected back to back with an Ethernet cable, the same speed-switching trick was employed. However, most hardware takes longer to switch speeds than the Pi 4; usually on the order of 2-5 seconds. This limited the signalling speed, but [Jacek] was able to set this up to exfiltrate data using QRSS, also known as very slow speed Morse code. The best result was picking up a signal from 10 meters away, although [Jacek] suspects this could be improved with better antenna hardware.

While slow data rates and the one-way nature of such communication limit the utility of such an attack, it nonetheless shows that securing a machine isn’t as simple as unplugging it from the network. We’ve done a feature on such hacks before for those interested in learning more. Video after the break.

Continue reading “Leaking Data Slowly By Switching Ethernet Speeds”

Tiny Ethernet Routers Now Available In Gigabit Speeds

If you need to move a lot of data, and fast, Gigabit Ethernet is a great way to do it. However, most network hardware outside of datacenters is fairly space inefficient, a headache if you’re building a robot or drone. Enter the Gigablox, a super-compact Gigabit router for just these applications.

The Gigablox takes its mission seriously, with its compact size the ultimate design goal. The entire switch fits on a tiny 45 mm x 45 mm PCB. To this end, it eschews the common RJ45 connector, which is bulkier than necessary. Instead, thin Molex PicoBlade connectors are used for the five ports on board. Cables are included to convert between the two connectors, and obviously crimping ones own is easy to do, too. For those who need to connect more devices, several Gigablox can be hooked up in the same way as any other Ethernet switch. The Gigablox is a non-blocking switch, too – meaning all five ports can run at full speed simultaneously.

The design is the sequel to the SwitchBlox, and the later SwitchBlox Nano, both designed by [Josh Elijah] earlier this year. The pace of development is impressive, and it’s great to see [Josh] bring Gigabit speeds to the compact form factor. We can imagine a few good uses for these boards; share your best ideas in the comments below! Video after the break.

Continue reading “Tiny Ethernet Routers Now Available In Gigabit Speeds”