network

88 Articles

SCADA Security Hack Chat

July 12, 2021 by 18 Comments

Join us on Wednesday, July 14 at noon Pacific for the SCADA Security Hack Chat with Éireann Leverett!

As a society, we’ve learned a lot of hard lessons over the last year and a half or so. But one of the strongest lessons we’ve faced is the true fragility of our infrastructure. The crumbling buildings and bridges and their tragic consequences are one thing, but along with attacks on the food and energy supply chains, it’s clear that our systems are at the most vulnerable as their complexity increases.

And boy are we good at making complex systems. In the United States alone, millions of miles of cables and pipelines stitch the country together from one coast to the other, much of it installed in remote and rugged places. Such far-flung systems require monitoring and control, which is the job of supervisory control and data acquisition, or SCADA, systems. These networks have grown along with the infrastructure, often in a somewhat ad hoc manner, and given their nature they can be tempting targets for threat actors.

Finding ways to secure such systems is very much on Éireann Leverett’s mind. As a Senior Risk Researcher at the University of Cambridge, he knows about the threats to our infrastructure and works to find ways to mitigate them. His book Solving Cyber Risk lays out a framework for protecting IT infrastructure in general. For this Hack Chat, Éireann will be addressing the special needs of SCADA systems, and how best to protect these networks. Drop by with your questions about infrastructure automation, mitigating cyber risks, and what it takes to protect the endless web of pipes and wires we all need to survive.

join-hack-chatOur Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, July 14 at 12:00 PM Pacific time. If time zones have you tied up, we have a handy time zone converter.

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

June 29, 2021 by 59 Comments

[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

April 26, 2021 by 5 Comments

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” →

Open Source Electric Vehicle Charging

April 6, 2021 by 26 Comments

Electric vehicles are becoming more and more common on the road, but when they’re parked in the driveway or garage there are still some kinks to work out when getting them charged up. Sure, there are plenty of charging stations on the market, but they all have different features, capabilities, and even ports, so to really make sure that full control is maintained over charging a car’s batteries it might be necessary to reach into the parts bin and pull out a trusty Arduino.

This project comes to us from [Sebastian] who needed this level of control over charging his Leaf, and who also has the skills to implement it from the large high voltage switching contactors to the software running its network connectivity and web app. This charging station has every available feature, too. It can tell the car to charge at different rates, and can restrict it to charging at different times (if energy is cheaper at night, for example). It is able to monitor the car’s charge state and other information over the communications bus to the vehicle, and even has a front-end web app for monitoring and controlling the device.

The project is based around an Arduino Nano 33 IoT with all of the code available on the project’s GitHub page. While we would advise using extreme caution when dealing with mains voltage and when interfacing with a high-ticket item like an EV, at first blush the build looks like it has crossed all its Ts and might even make a good prototype for a production unit in the future. If you don’t need all of the features that this charging station has, though, you can always hack the car itself to add some more advanced charging features.

Continue reading “Open Source Electric Vehicle Charging” →

Raspberry Pi Tally Lights

January 4, 2021 by 25 Comments

Running a camera studio is a complicated affair from pretty much every angle. Not only is the camera gear expensive but the rest of the studio setup takes care and attention down to the lighting as well. When adding multiple cameras to the mix, like for a television studio, the level of complexity increases exponentially. It’s great to have a few things that simplify the experience of running all of this equipment too, without the solution itself causing more problems than it solves, like these network-operated Raspberry Pi-powered tally lights.

A tally light is the light on a camera that lets the person being recorded know which camera is currently in use. Networking them all together often requires complex wiring or at least some sort of networking solution, which is what this particular build uses. However, the lights are controlled directly over HTTP rather than using a separate application which might need a port open on a firewall or router, which not only simplifies their use but doesn’t decrease network security.

The HTTP interface, plus all of the software and schematics for this build, are available on the project’s GitHub page. We imagine the number of people operating a studio and who are in need of a tally light system to be fairly low, but the project is interesting from a networking point-of-view regardless of application. If you do have a studio like this and are looking for other ways to improve it, we do have a simple teleprompter hack that might be right up your alley.

True Networked KVM Without Breaking The Bank

November 24, 2020 by 27 Comments

For administering many computers at once, an IP KVM is an invaluable piece of equipment that makes it possible to get the job done over the network without having to haul a keyboard, monitor, and mouse around to each computer. The only downside is that they can get pricey, unless of course you can roll one out based on the Raspberry Pi and the PiKVM image for little more than the cost of the Pi itself.

The video linked below shows how to set all of this up, which involves flashing the image and then setting up the necessary hardware. The build shows an option for using HDMI over USB, but another option using the CSI bus would allow for control over options like video resolution and color that a USB HDMI dongle doesn’t allow for. It also makes it possible to restart the computer and do things like configure BIOS or boot from removable media, which is something that would be impossible with a remote desktop solution like VNC.

The creator of PiKVM was mentioned in a previous post about the creation of the CSI bus capture card, and a Pi hat based on this build will be available soon which would include options for ATX controls as well. Right now, though, it’s possible to build all of this on your own without the hat, and is part of what makes the Pi-KVM impressive, as well as its very low cost.

Continue reading “True Networked KVM Without Breaking The Bank” →

Modern Network Adapter For Retro Computers

October 14, 2020 by 9 Comments

Universal Serial Bus, or USB, is so ingrained in modern computing that it’s hard to imagine a time without it. That time did exist, though, and it was a wild west of connector types, standards, and interfacing methods. One of the more interesting interfaces of the time was the SIO system found in 8-bit Atari computers which ended up sharing a lot of the features of modern USB, and its adaptability is displayed in this modern project which brings WiFi, Bluetooth, USB, and SD card slots to any old Atari with an SIO port.

The project is called FujiNet and it uses the lightweight protocol of SIO to add a number of modern features to the 8-bit machine. It’s based on an ESP32, and the chip performs the functions of a network adapter by bridging WiFi and Bluetooth to the Atari. It does this by simulating drives that would have potentially been used on the Atari in its time, such as a floppy disk drive, an RS232 interface, or a modem, and translating them to the modern wireless communication protocols. It even has the ability to emulate a printer by taking the output of the print job from the Atari and converting it to PDF within the device itself.

Not only does this bring a lot of functionality to the Atari, which you may be able to use to view sites like retro.hackaday.com, but the FujiNet is housed in a period-appropriate 3D-printed case that matches the look and feel of the original Atari. If you need a more generic solution for your retrocomputing networking adventures that isn’t limited to SIO, we recommend grabbing a Raspberry Pi to handle that.

Thanks to [Gavin] for the tip!