IP Over QR Codes

We’ve seen networks built over some interesting mediums, but QR codes has to be a new one. [Eric Seifert] decided to try to use QR codes to make an IP connection. He used these visual codes to create a bi-directional connection between two camera-equipped computers. He’s a persistent chap, because it works: in one of his videos, he shows an SSH connection between two devices.

He faced a number of challenges on the way. Although there is plenty of code to read QR codes, the data that can be encoded and read from them is limited. There is a binary mode that can be used with QR codes, but it is really inefficient. [Eric] decided to use base32 coding instead, packing the data into each frame as alphanumeric text. Each QR code image that is created and received is numbered, so the system can keep track and request any lost images. He also had some problems with keeping the data consistent between the encoded and decoded versions, so he had to add some packing to the data before it would work.  It uses Python-pytun to create a TUN/TAP device that carries the data.

The speed of the connection is rather slow: in his demo video, the two computers take over a minute to exchange keys for an SSH connection, and [Eric] measured the speed of the connection at about 100 bits per second. But even getting something like this working at all is a significant achievement. He has published his code on GitHub.

We’ve featured the work of [Eric] before: he created a data connection using an iPod FM transmitter.

Continue reading “IP Over QR Codes”

A Rebel Alliance for Internet of Things Standards

Back when the original Internet, the digital one, was being brought together there was a vicious standards war. The fallout from the war fundamentally underpins how we use the Internet today, and what’s surprising is that things didn’t work out how everyone expected. The rebel alliance won, and when it comes to standards, it turns out that’s a lot more common than you might think.

Looking back the history of the Internet could have been very different. In the mid eighties the OSI standards were the obvious choice. In 1988 the Department of Commerce issued a mandate that all computers purchased by government agencies should be OSI compatible starting from the middle of 1990, and yet two years later the battle was already over, and the OSI standards had already lost.

In fact by the early nineties the dominance of TCP/IP was almost complete. In January of 1991 the British academic backbone network, called JANET (which was based around X.25 colored book protocols), established a pilot project to host IP traffic on the network. Within ten months the IP traffic had exceeded the levels of X.25 traffic, and IP support became official in November.

“Twenty five years ago a much smaller crowd was fighting about open versus proprietary, and Internet versus OSI. In the end, ‘rough consensus and running code’ decided the matter: open won and Internet won,”

Marshall Rose, chair of several IETF Working Groups during the period

This of course wasn’t the first standards battle, history is littered with innumerable standards that have won or lost. It also wasn’t the last the Internet was to see. By the mid noughties SOAP and XML were seen as the obvious way to build out the distributed services we all, at that point, already saw coming. Yet by the end of the decade SOAP and XML were in heavy retreat. RESTful services and JSON, far more lightweight and developer friendly than their heavyweight counterparts, had won.

“JSON appeared at a time when developers felt drowned by misguided overcomplicated XML-based web services, and JSON let them just get the job done,”

“Because it came from JavaScript, and pretty much anybody could do it, JSON was free of XML’s fondness for design by committee. It also looked more familiar to programmers.”

Simon St. Laurent, content manager at LinkedIn and O’Reilly author

Yet, depending on which standards body you want to listen to, ECMA or the IETF, JSON only became a standard in 2013, or 2014, respectively and while the IETF RFC talks about semantics and security, the ECMA standard covers only the syntax. Despite that it’s unlikely many people have actually read the standards, and this includes the developers using the standard and even those implementing the libraries those developers depend on.

We have reached the point where standardization bodies no longer create standards, they formalize them, and the way we build the Internet of Things is going to be fundamentally influenced by that new reality.

Continue reading “A Rebel Alliance for Internet of Things Standards”

ESP Clock Needs More Power

[Victor-Chew] is tired of setting clocks. After all, here we are in the 21st century, why do we have to adjust clocks (something we just did for daylight savings time)? That’s why [Victor] came up with ESPClock.

Based on a $2 Ikea analog clock, [Victor] had a few design goals for the project:

  • Automatically set the time from the network
  • Automatically adjust for daylight savings time
  • Not cost much more than a regular clock
  • Run for a year on batteries

The last goal is the only one that remains unmet. Even with a large battery pack, [Victor’s] clock runs out of juice in a week or so. You can see some videos of the clock syncing with network time, below.

Continue reading “ESP Clock Needs More Power”

Colorful Display Keeps Track of Your Network

So you’ve built out your complete home automation setup, with little network-connected “things” scattered all around your home. You’ve got net-connected TVs, weather stations, security cameras, and whatever else. More devices means more chances for failure. How do you know that they’re all online and doing what they should?

[WTH]’s solution is pretty simple: take a Raspberry Pi Zero, ping all the things, log, and display the status on an RGB LED strip. (And if that one-sentence summary was too many words for you, there’s a video embedded below the break.)

Continue reading “Colorful Display Keeps Track of Your Network”

How to Run a Pagekite Server to Expose Your Raspberry Pi

Last time I showed you how to expose a web service on a Raspberry Pi (or, actually, any kind of device) by using a reverse proxy from Pagekite. On your Pi, you just need a simple Python script. However, it also depends on the Pagekite server, which isn’t always convenient. There are limits to the free service, and you don’t control the entire thing. The good news is twofold: the same Python script you use to set up the client-side can also set up a server. The other good news is the entire thing is open source.

In practical terms, then, if you have a computer that is always on and has an IP address that can be found on the public internet, you can run your own Pagekite server (they call it a front end) and service your own backends.

Continue reading “How to Run a Pagekite Server to Expose Your Raspberry Pi”

Hackaday Prize Entry: Cheap Visible Light Communication

[Jovan] is very excited about the possibilities presented by Visible Light Communication, or VLC. It’s exciting and new. His opening paragraphs is filled with so many networking acronyms that VLC could be used for, our browser search history now looks like we’re trying to learn english without any vowels.

In lots of ways he has good reason to be excited. We all know that IR can communicate quite a bit, but when you’re clever about frequency and color and throw in some polarizers with a mix of clever algorithms for good measure you can get some very high bandwidth communication with anything in line of site. You can do it for low power, and best of all, there are no pesky regulations to stand in your way.

He wants to build a system that could be used for a PAN (Personal Area Network). To do this he’ll have to figure out a way to build the system inexpensively and using less than a watt of power. The project page is full of interesting experiments and quite a few thesis on the subject of LEDs.

For example, he’s done work on how LEDs respond to polarization. He’s tested how fast an LED can actually turn on and off while still being able to detect the change. He’s also done a lot of work characterizing the kind of light that an LED emits. We don’t know if he’ll succeed yet, but we like the interesting work he’s doing to get there.

MIT Thinks It Can One-Up TOR With New Anonymity Network: Riffle

Tor is the household name in anonymous networks but the system has vulnerabilities, especially when it comes to an attacker finding out who is sending and receiving messages. Researchers at MIT and the École Polytechnique Fédérale de Lausanne think they have found a better way in a system called Riffle. You can dig into the whitepaper but the MIT news article does a great job of providing an overview.

The strength at the core of Tor is the Onion Routing that makes up the last two letters the network’s name. Riffle keeps that aspect, building upon it in a novel way. The onion analogy has to do with layers of skins — a sending computer encrypts the message multiple times and as it passes through each server, one layer of encryption is removed.

Riffle starts by sending the message to every server in the network. It then uses Mix Networking to route the message to its final destination in an unpredictable way. As long as at least one of the servers in the network is uncompromised, tampering will be discovered when verifying that initial message (or through subsequent authenticated encryption checks as the message passes each server).

The combination of Mix Networking with the message verification are what is novel here. The message was already safe because of the encryption used, but Riffle will also protect the anonymity of the sender and receiver.

[via Engadget]