There’s a big problem with the Internet of Things. Everything’s just fine if your Things are happy to sit around your living room all day, where the WiFi gets four bars. But what does your poor Thing do when it wants to go out and get a coffee and it runs into a for-pay hotspot?
[Yakamo]’s solution is for your Thing to do the same thing you would: tunnel your data through DNS requests. It’s by no means a new idea, but the combination of DNS tunneling and IoT devices stands to be as great as peanut butter and chocolate.
DNS tunneling, in short, relies on you setting up your own DNS server with a dedicated subdomain and software that will handle generic data instead of information about IP addresses. You, or your Thing, send data encoded in “domain names” for it to look up, and the server passes data back to you in the response.
DNS tunneling is relatively slow because all data must be shoe-horned into “domain names” that can’t be too long. But it’s just right for your Thing to send its data reports back home while it’s out on its adventure.
Oh yeah. DNS tunneling may violate the terms and conditions of whatever hotspot is being accessed. Your Thing may want to consult its lawyer before trying this out in the world.
Normal WiFi is not what you want to send video from your quadcopter back to the first-person-view (FPV) goggles strapped on your head, because it’s designed for 100% correct, two-way transmission of data between just two radios. Transmission of analog video signals, on the other hand, is lossy, one-way, and one-to-many, which is why the longer-range FPV flights all tend to use old-school analog video transmission.
When you’re near the edge of your radios’ range, you care much more about getting any image in a timely fashion than about getting the entire video sequence correctly after a delay. While WiFi is retransmitting packets and your video is buffering, your quadcopter is crashing, and you don’t need every video frame to be perfect in order to get an idea of how to save it. And finally, it’s just a lot easier to optimize both ends of a one-way transmission system than it is to build antennas that must receive and transmit symmetrically.
And that’s why [Befinitiv] wrote wifibroadcast: to give his WiFi FPV video system some of the virtues of analog broadcast.
Continue reading “Wifibroadcast Makes WiFi FPV Video More Like Analog”
Ethernet has been around since the mid-70s, but if you think it was always Cat5 and 10BaseT, you’d be sorely mistaken. The first ethernet was built with coaxial cable, vampire taps, AUI adapters, and a whole bunch of other network hardware that will make wizened networking veterans cringe. [Matt] had heard about these weird physical layers back when he started building networks in 1997, but he had never seen one. Now it’s an ancient and forgotten footnote in the history of computer networking. Is it possible to build a Thicknet in this modern era? It turns out, yes, it’s possible. It’s not easy, though.
The network [Matt] is building is a true 10Base5, or Thicknet, network. The backbone of this network is a coaxial cable 9.5mm in diameter. [Matt] discovered that while the common belief that Thicknet used RG-8/U cable. This appears to be incorrect, as the connectors for this cable – vampire taps that pierced the insulation and shield of the cable – are designed for cable manufactured by Belden, part number 9880.
[Matt] assembled the cable, vampire taps, AUI cables, and even found a few ISA NICs that would still work with a reasonably modern computer. He even went so far as to build a USB Ethernet adapter with an AUI interface. This impossibly retro device uses a standard USB to 10BaseT Ethernet adapter, with a chip designed to convert 10BaseT to AUI hacked onto a circuit board. That in itself is an incredible piece of engineering, with a handful of power supplies to get the correct 2.5, 3.3, 5, and 12 Volts to the right places.
As far as exercises in computing history go, [Matt] is at the top of his game. In the process of building it, he also figured out why no one uses Thicknet anymore; once it’s in place, you can’t change it, the cable is big, bulky, and the connectors are terrible. Still, it’s an amazing example of how far we’ve come.
[Alessandro] is an unlucky VoIP PBX administrator that frequently has to deal with very, very dumb network policies. Often times, he’ll have to change something on his setup which requires him to go out to his client’s location, or ask a client to use Teamviewer so the appropriate change can be made from behind a firewall.
This isn’t the solution to the problem. It will, however, fix the problem. To get around these firewalls, [Alessandro] is using the voice channels he already has access to for changing configurations on his VoIP boxes.
The implementation of this uses the AX.25 amateur radio modules that can be found in just about every Linux distro. This, and an Alsa loopback device, allows [Alessandro] to access a terminal over a voice-only network. Is it a hackey kludge? Yep. Is it just a little bit dumb? So are the network policies that don’t allow [Alessandro] to do his job.
This build isn’t too dissimilar than a bunch of modems from the old BBS days, albeit with vastly more powerful software. [Alessandro] says you’re only going to get about 38400bps out of this setup, but it beats begging for help for remote access.
If you’ve ever been to a capture the flag hacking competition (CTF), you’ve probably seen some steganography challenges. Steganography is the art of concealing data in plain sight. Tools including secret inks that are only visible under certain light have been used for this purpose in the past. A modern steganography challenge will typically require you to find a “flag” hidden within an image or file.
[Anfractuosus] came up with a method of hiding packets within a stream of network traffic. ‘Timeshifter’ encodes data as delays between packets. Depending on the length of the delay, each packet is interpreted as a one or zero.
To do this, a C program uses libnetfilter_queue to get access to packets. The user sets up a network rule using iptables, which forwards traffic to the Timeshifter program. This is then used to send and receive data.
All the code is provided, and it makes for a good example if you’ve ever wanted to play around with low-level networking on Linux. If you’re interested in steganography, or CTFs in general, check out this great resource.
If internet service providers go down, how are we going to get our devices to communicate? Project Byzantium aims to create an “ad-hoc wireless mesh networking for the zombie apocalypse.” It’s a live Linux distribution that makes it easy to join a secure mesh network.
[B1tsh1fter] has put together a set of hardware for running Byzantium on Pis in emergency situations. A Raspberry Pi 2 acts as a mesh node, using a powerful USB WiFi adapter for networking. Options are provided for backup power, including a solar charger and a supercapacitor based solution.
The Pi runs a standard Raspbian install, but uses packages from the ByzPi repository. This provides a single script that gets a Byzantium node up and running on the Pi. In the background, OLSR is used to route packets through the mesh network, so that nodes can communicate without relying on a single link.
The project has a ways to go, but the Raspberry Pi based setup makes it cheap and easy to get a wide area network up and running without relying on a single authority.
The idea of a pirate box is pretty simple. All you need is a tiny Linux system with a WiFi adapter, a bit of storage space, and the software that will allow anyone to upload a few files to the server and an interface that will let anyone on the network download those files. In practice, though, a pirate box is a mess of wires and power adapters – not the pocketable device a WiFi file sharing box should be.
[Chris] came up with a much smaller file sharing beacon. It’s not based on a router; instead, [Chris]’ build uses an ez Share WiFi microSD adapter. It’s a device meant to push pics taken by a digital camera up to the Internet, but by configuring the software just so, up to five users can connect to the adapter and pull files down from a microSD card. The build only requires putting power to the correct pins. A LiPo battery and charge controller takes care of this problem.
There are a few shortcomings to this project – [Chris] doesn’t know how to upload files to the device. Maybe someone sufficiently clever can figure out how to make that work. Still, if you’re ever in a situation where you’d like to share some files with people in the same building, this is the device you need.
Thanks [Jake] for the tip.