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”

Hackaday Links Column Banner

Hackaday Links: April 25, 2021

There’s much news from the Jezero Crater on Mars this week, and all of it was good. Not only did the Ingenuity helicopter make history by making the first powered, controlled flight of an aircraft on another planet, it made a second longer, more complex flight just a couple of days later. This time, the autonomous rotorwing craft flew to a higher altitude than the maiden flight, hovered for a bit longer, and made a lateral move before landing safely again on the surface. Three more flights of increasing complexity (and risk) are scheduled over the next two weeks, with the next set to happen early Sunday morning. I have to admit that even though the Ingenuity tech demonstration seemed a little like a publicity stunt when I first heard about it, especially when compared to the Perseverance’s main mission of searching for evidence of life on Mars, the Ingenuity team’s successes have made a believer out of me.

Speaking of technology demonstrations, NASA fired up the MOXIE experiment aboard Perseverance for the first time. Intended to explore the possibility of producing oxygen from the thin carbon dioxide-rich Martian atmosphere, the Mars Oxygen In-Situ Resource Utilization Experiment made about 5.4 grams of oxygen total at a rate of about 6 grams an hour. We detailed the technology MOXIE uses, called solid-oxide electrolysis, which depends on a scandium-stabilized zirconium oxide ceramic electrolyte to strip the oxygen from superheated carbon dioxide using an electric current. Should the technology prove itself over the planned total of ten MOXIE runs over the next few months, a scaled up version of the device could someday land on Mars and produce the estimated 55 metric tons of oxygen needed to fuel a return trip from a crewed mission.

By now we’ve all heard about the global semiconductor shortage, or perhaps felt the pinch ourselves while trying to procure parts for a build. It’s easy to count the crunch as yet another follow-on from the COVID-19 shutdowns and the logistics woes the pandemic begat, so one might have hope that with lockdowns easing up around the world, the shortage will soon be over as manufacturers ramp up production. But not so fast — it looks like the machines needed to make the chips are the latest victims of the shortage. According to Nikkei Asia, wire bonding machines, wafer dicers, and laser drilling machines are all in short supply, with orders for new machines booked out for a year. Like toilet paper this time last year, chip makers are hoarding machines, ordering 50 or 100 of them at a time, in the hopes of having enough to meet production goals. And when machines are available, travel restrictions are making it difficult to get on-site installation and support from factory reps. The bottom line — this isn’t over yet, not by a long shot.

We all know the Stack Overflow memes, and few of us who are being honest haven’t squirmed a bit when thinking about just how screwed we’d be without being able to copy a bit of code to get us past that rough part in a project. But just how often do people copy code from Stack Overflow? Quite a lot, actually, if SO’s analysis of the use of copy commands on their pages is to be believed. For two weeks, SO monitored the number of times the Ctrl-C (or Command-C, if that’s your jam) key combination was pressed. They toted up over 40 million copies, most often from the answers to questions and almost always from the code blocks within them. We suppose none of this is exactly unexpected — memes are memes for a reason, after all — but what we found surprising is that one in four visitors to Stack Overflow copied something within five minutes of loading a page. Being charitable, we’d say the speed with which coders accept someone else’s work is an indication that maybe they were almost at an answer themselves and just needed a little reminder. On the other hand, it could be a sign of separation driving them to get something working.

And finally, while we know we’ve recommended videos from Grady at Practical Engineering recently, we couldn’t help but plug another of his videos as a must-watch. This time, Grady tackles the Suez Canal blockage, and he presents it in the same dispassionate, informed way that he previously handled the engineering roots of the Texas blackouts. If you think the Ever Given grounding was just a case of poor seamanship, think again — Grady makes a compelling case for possible hydrodynamic causes of the incident, including “squatting” and the bank effect. He also speculates on the geotechnical forces that held the ship fast, in the process of which he helpfully introduces the concept of dilatancy and how it explains the way your feet seem to “dry out” a zone around them as you walk across the beach.

Continue reading “Hackaday Links: April 25, 2021”

Fail Of The Week: Mistaking Units For Values

Usually when we post a Fail Of The Week, it’s a heroic tale of a project made with the best of intentions that somehow failed to hit its mark. The communicator that didn’t, or the 3D-printed linkage that pushed the boundaries of squirted plastic a little bit too far. But today we’re bringing you something from a source that should be above reproach, thanks to [Boldport] bringing us a Twitter conversation between [Stargirl] and [Ticktok] about a Texas Instruments datasheet.

The SN65220 schematic
The SN65220 schematic

The SN65220 is a suppressor chip for USB ports, designed to protect whatever the USB hardware is from voltage spikes. You probably have several of them without realising it, the tiny six-pin package nestling on the PCB next to the USB connector. Its data sheet reveals that it needs a resistor network between it and the USB device it protects, and it’s this that is the source of the fail.

There are two resistors, a 15kO and a 27O, 15k ohms, and 270 ohms, right? Looking more closely though, that 27O is not 270 with a zero, but 27O with a capital “O”, so in fact 27 ohms.

The symbol for resistance has for many decades been an uppercase Greek Omega, or Ω. It’s understood that sometimes a typeface doesn’t contain Greek letters, so there is a widely used convention of using an uppercase “R” to represent it, followed by a “K” for kilo-ohms, an “M” for mega-ohms, and so on. Thus a 270 ohm resistor will often be written as 270R, and 270 kilo-ohm one as 270K. In the case of a fractional value the convention is to put the fraction after the letter, so for example 2.7kilo-ohms becomes 2K7. For some reason the editor of the TI datasheet has taken it upon themselves to use an uppercase “O” to represent “Ohms”, leading to ambiguity over values below 1 kilo-ohm.

We can’t imagine an engineer would have made that choice so we’re looking towards their publishing department on this one, and meanwhile we wonder how many USB devices have gone to manufacture with a 270R resistor in their data path. After all, putting the wrong resistor in can affect any of us.

Hack The Cloud!

The obvious rants against software or services “in the cloud” are that you don’t own it, your data isn’t on your own hard drive, or that, when the interwebs are down, you just can’t get your work done. But the one that really grinds my gears is that, at least for many cloud services, you just can’t play around with them. Why does that matter? Well, as a hacker type, of course, I like to fool around, but more deeply, I feel that this invitation to play around is what’s going to grow up the next generation of hackers. Openness matters not just for now, but also for the future.

Of course, it’s unfair to pin all of this on the cloud. There are plenty of services with nice open APIs that let you play around with their systems as much as you want — witness the abundance of amusing things you can do with Twitter or Twitch. Still, every day seems to bring another formerly-open API that gets bought up by some wealthy company and shut down. I built a nice “is it going to rain today” display out of a meter-long WS2812 strip and an ESP8266, but Dark Sky API got bought up by Apple and is going dark soon (tee-hee!) leaving me thinking of how I’m going to get easy weather data in the next few months.

Whisper your tip in our earOr take my e-mail annunciator. I wrote a little script that, when I have new mail that’s work related or from my wife (read: important), it displays the subject line on a VFD that I have perched on my monitor. This works with Gmail, which I have to use for work, because they support IMAP so at least I can do cool things with the mail once it reaches my server. But can I do anything with Google Groups, which we use for the Hackaday Tip Line? Fat chance!

So there’s good “cloud” and there’s bad “cloud”. Good cloud is open cloud. Good cloud invites you to play, to innovate, and to come up with the right solutions for yourself. Good cloud gives you access to your data. Good cloud is hackable cloud. Let’s see more of that.

Hackaday Podcast 115: AI Is Bad At Linux Terminal, Puppeting Pico In Python, 3D Scanning Comes Up Short

Hackaday editors Mike Szczys and Elliot Williams pull back the curtain on a week of excellent hacks. We saw an awesome use of RGB LEDs as a data channel on a drone, and the secrets of an IP camera’s OS laid bare with some neat reverse engineering tools. There’s an AI project for the Linux terminal that guesses at the commands you actually want to run. And after considering how far autopilot has come in the aerospace industry, we jump into a look at the gotchas you’ll find when working with models of 3D scanned objects.

Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download (~60 MB)

Places to follow Hackaday podcasts:

Continue reading “Hackaday Podcast 115: AI Is Bad At Linux Terminal, Puppeting Pico In Python, 3D Scanning Comes Up Short”

This Week In Security: NAME:WRECK, Signal Hacks Back, Updates, And More

NAME:WRECK is a collection of vulnerabilities in DNS implementations, discovered by Forescout and JSOF Research. This body of research can be seen as a continuation of Ripple20 and AMNESIA:33, as it builds on a class of vulnerability discovered in other network stacks, problems with DNS message compression.

Their PDF Whitepaper contains a brief primer on the DNS message format, which is useful for understanding the class of problem. In such a message, a DNS name is encoded with a length-value scheme, with each full name ending in a null byte. So in a DNS Request, Hackaday.com would get represented as [0x08]Hackaday[0x03]com[0x00]. The dots get replaced by these length values, and it makes for an easily parsable format.

Very early on, it was decided that continually repeating the same host names in a DNS message was wasteful of space, so a compression scheme was devised. DNS compression takes advantage of the maximum host/domain length of 63 characters. This max size means that the binary representation of that length value will never contain “1”s in the first two digits. Since it can never be used, length values starting with a binary “11” are used to point to a previously occurring domain name. The 14 bits that follow this two bit flag are known as a compression pointer, and represent a byte offset from the beginning of the message. The DNS message parser pulls the intended value from that location, and then continues parsing.

The problems found were generally based around improper validation. For example, the NetX stack doesn’t check whether the compression pointer points at itself. This scenario leads to a tight infinite loop, a classic DoS attack. Other systems don’t properly validate the location being referenced, leading to data copy past the allocated buffer, leading to remote code execution (RCE). FreeBSD has this issue, but because it’s tied to DHCP packets, the vulnerability can only be exploited by a device on the local network. While looking for message compression issues, they also found a handful of vulnerabilities in DNS response parsing that aren’t directly related to compression. The most notable here being an RCE in Seimens’ Nucleus Net stack. Continue reading “This Week In Security: NAME:WRECK, Signal Hacks Back, Updates, And More”

Hands-On With PineCube: An Open IP Camera Begging For Better Kernel Support

When the PineCube was announced by the Pine64 project in 2020, it created a fair bit of interest. Most of this was due to the appeal of a single-board computer (SBC) in a network-based (IP) camera form factor with integrated camera module, for a mere $29.99. Add an enclosure to it, and you would have a neat little package combining a 5 MP camera module with 100 Mbit Ethernet and WiFi. As a bonus, the system could be powered either via an optional battery pack as well as passive PoE, in addition to MicroUSB.

A few weeks ago I bought two of these boards, as part of a client project, and set out to use it for a custom IP camera implementation. With existing Linux-on-SBC and MIPI (CSI) camera experience on my end ranging from the Raspberry Pi to the Odroid, Orange Pi and Banana Pi boards, I felt fairly confident that I could make it work with minimal fuss.

Unfortunately, my experiences were anything but positive. After spending many hours with the PineCube, I’m not able to recommend it for those seeking an IP camera. There are many reasons for this, which I’ll try to explain in this article.

Continue reading “Hands-On With PineCube: An Open IP Camera Begging For Better Kernel Support”