ESP8266 Call Button

It's NDN Community Meeting again and this time I'm officially presenting HomeCam at the demo session. I'm the sole presenter of this project. Normally, I have to stay at my table to show my project to the audience. However, I don't want to miss the chance of seeing what others have been doing. To solve this dilemma, I come up with an idea: a call button.

I put a big button on my table. It is labelled as: if I'm not here, press the button to send an Interest. Then, I wear a battery powered light ring on my body. Whenever someone presses the button, it lights up for 15 seconds.

me wearing a light ring at NDNcomm demo session

How It Works

Both the button and the light ring are based on ESP8266. The light ring unit acts as WiFi access point and NDN producer. The button unit acts as WiFi station and NDN consumer. When the button is pressed, the consumer transmits a signed Interest, and the producer turns on the light for 15 seconds after verifying the signature. Since the light ring unit is battery-powered, it enters deep sleep mode if there's no connected WiFi client.

NFD on Windows 10 WSL

The NDN Forwarding Daemon (NFD) connects every Ubuntu and Mac OS machine to the Named Data Networking (NDN) testbed network. While it's awesome to get your NFD connected from a Linux server or a Macbook, 82.56% of the desktop users running Windows are out of luck. Compiling NFD for Windows is possible, but the amount of patches needed is astonishing.

Then the good news came: Microsoft announced Windows Subsystem for Linux (WSL), which lets developers run Linux environments directly on Windows, unmodified, without the overhead of a virtual machine. Ubuntu is the first Linux distribution supported by WSL. This means, we can now run NFD natively on Windows!

How to Install NFD on WSL

This section outlines how to install NDN Forwarding Daemon (NFD) on Windows Subsystem for Linux (WSL). As of this writing, I have Windows 10 version 1709 (Fall Creators Update), and the latest NFD release is version 0.6.1.

The steps to install NFD on Windows are:

Tunnel Ethernet Traffic Over NDN

Named Data Networking (NDN) is a common network protocol for all applications and network environment. NDN's network layer protocol runs on top of a best-effort packet delivery service, which includes physical channels such as Ethernet wires, and logical connections such as UDP or TCP tunnels over the existing Internet. Using this underlying connectivity, NDN provides a content retrieval service, which allows applications to fetch uniquely named "Data packets" each carrying a piece of data. The "data" could be practically anything: text file chunks, video frames, temperature sensor readings ... they are all data. Likewise, a packet in a lower layer network protocol, such as an Ethernet frame, is also a piece of data. Therefore, it should be possible to encapsulate Ethernet traffic into NDN Data packets, and establish a Virtual Private Network (VPN) through NDN communication. This post describes the architecture of a proof-of-concept Ethernet-over-NDN tunneling program, and shows a simple performance benchmark over the real world Internet.

The Program

tap-tunnel creates an Ethernet tunnel between two nodes using NDN communication. Each node runs an instance of tap-tunnel. This program collects packets sent into a TAP interface, and turn them into NDN packets. It then gains NDN connectivity by connecting to the local NDN Forwarding Daemon (NFD). The diagram below shows the overall architecture:

How I Setup my NFD Development Machine

I'm the lead developer of NDN Forwarding Daemon (NFD). In this article, I want to share how my development machine is setup.

Everything in Virtual Machines

I do all NFD development work in virtual machines. There are many benefits in using VMs: I can have a clean operating system, I can test out different OS versions if necessary, and I can work on a different change on another VM when "my code's compiling".

My VM was setup using Vagrant, using the following Vagrantfile:

How I Put a Temperature Sensor on the NDN Testbed

The frontpage of my recently renovated website shows a room temperature reading of my apartment. This is not your average IoT project, but a showcase of how an IoT device can communicate directly over Named Data Networking (NDN). This article explains where does this temperature reading come from, how is it turned into NDN Data packets, how the sensor appears on the NDN testbed, and how the temperature reading shows up on the website.

room temperature display on yoursunny.com frontpage

Sensor Hardware

If you have been reading my posts, you may have guessed that the temperature reading comes from an ESP8266. Of course! It is actually my very first ESP8266, which I received from Losant IoT Inc. It comes with a TMP36 analog temperature sensor, and has been reporting my room temperature to Losant platform since May 2016.

Losant Builder Kit with all the additions

How HomeCam Registers NDN Prefixes?

HomeCam, a browser-based home surveillance camera, is one of my major side projects during the past few years. My last post gave an overview on the overall architecture and various components of HomeCam. I mentioned that HomeCam delivers pictures via Named Data Networking (NDN), which provides better scalability because the camera only needs to serve each picture once even if there are multiple viewers, and the network takes care of the distribution.

Both HomeCam viewers and cameras connect to the global NDN testbed network via WebSockets. A viewer sends Interests to the network to request a picture from a specific camera identified by part of the Interest name. The network forwards the Interests to the named camera, and the camera responds with Data packets that contain the picture. But how does the network know where the camera is?

The camera must register its prefix onto the NDN testbed network.

For a regular end host running the NDN Forwarding Daemon (NFD), you may let the world reach your NFD via auto prefix propagation. This procedure involves sending a prefix registration command to the network, which causes the router to add a route toward the end host. A requirement is that the prefix registration command must be signed by a key trusted by the network.

HomeCam camera is a browser-based application that directly connects to a testbed router, and there is no NFD running locally to do auto prefix propagation for us. However, HomeCam can still have a route added toward the camera by sending a prefix registration command.

How HomeCam Works?

HomeCam, a browser-based home surveillance camera, is one of my major side projects during the past few years. HomeCam allows you to capture pictures via the webcam on a laptop or smartphone, and view real-time images from a different device. No specialized hardware or software installation is needed: HomeCam works directly in a web browser. This article gives an overview of the web technologies that enable HomeCam.

If you have not used HomeCam, try it today!

Functionality Review and General Workflow

The HomeCam web app can operate in either viewer or camera mode. To enter either mode, the user is required to specify a "camera name", which serves as an identifier. Each camera should have a distinct camera name. Any number of viewers can be active at the same time, and they will retrieve real-time pictures from the camera with the same camera name.

Under the hood, this works in three steps:

ndnping Jewelry on ESP8266

I was wearing a unique piece of jewelry at NDN community meeting, Mar 2017: a pair of ESP8266 units that communicate with each other over the NDN testbed. They are ugly, but it is a nice way to demonstrate my creation in a Named Data Networking community meeting.

Two Witty Cloud boards are tied to my wrists, and powered by a USB powerbank in my pocket. One of them runs a ndnping client, and the other runs a ndnping server. The client sends Interests to a router in Arizona, the Interests (under a multicast prefix) are flooded through the testbed, and reach the server which is connected to a router in Memphis.

Arduino Code

Library: esp8266ndn

Issue Your Own NDN Certificates

To publish contents into a Named Data Networking (NDN) backbone network, you need to connect your NFD end host to the NDN Testbed, run a local producer application, and let the world reach your NFD through Automatic Prefix Propagation. However, a limitation with NDN Forwarding Daemon (NFD)'s Automatic Prefix Propagation is that, the prefix registered toward your end host is always the identity name of your certificate. While this works fine when you only have one or two machines, two problems arise when you want to deploy multiple end hosts:

  • Every certificate request needs an email verification and manual approval process, which is inconvenient. Or, you can copy your certificate and private key onto every machine, but in case any of these machines is compromised, your one and only private key will be exposed.
  • Certificates requested with the same email address have the same "identity name" and hence Automatic Prefix Propagation would register the same prefix. Unless all your machines serve the same contents, registering the same prefix toward all machines hurts network performance because the router has to rely on flooding and probing to figure out which of your machines serves a certain piece of content.

The solution is to issue your own NDN certificates, and let the world trust them.

The Hierarchical Trust Model

In cryptography, two trust models are widely used: