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.
Twitter and Facebook are two primary social networks that I regularly use.
Despite many arguments against synchronizing contents across different accounts, I still think it's beneficial to repost my tweets onto my Facebook timeline.
There are already many solutions to achieve cross-posting between Twitter and Facebook, but they are not ideal, because I'm very picky on what I want:
I want to cross-post from Twitter to Facebook, not the other way around.
I want to tweet with native Twitter clients, not through a third party website or app.
I don't want those tweets created by my Swarm check-ins to be re-posted onto Facebook, because Swarm app can directly post to Facebook.
For plain text tweets, I want them as plain text Facebook status updates, without a link to Twitter which could only confuse my Facebook friends.
If I tweet a photo, I want that photo to be uploaded to Facebook, instead of posting a link on Facebook.
If I tweet a link to some webpage, I want Facebook to display a preview of the webpage.
IFTTT is one of my favorite online services.
It allows me to create a recipe for certain automated actions.
The name "IFTTT" stands for IF This Than That, where This could be "posting a new tweet", and That could be "posting a Facebook status".
However, IFTTT does not allow filtering: I couldn't specify conditions like "the tweet is not posted by Swarm", which is necessary to achieve my goals.
Therefore, I need a more advance solution to repost my Twitter feed to Facebook.
This year the world is greeted with Losant, an Internet of Things platform that allows makers to connect their sensor devices, collect data into the cloud, and take actions through workflow execution.
While neither Twitter nor Facebook has anything to do with IoT, Losant workflow has some great capabilities that makes it suitable for non-IoT usage:
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:
A year ago, a Kickstarter campaign CHIP - The World's First Nine Dollar Computer caught my attention: it's a $9 computer smaller than a banana.
Unlikely the Raspberry Pi, it comes with onboard storage so I don't need to buy a separate SD card, it has WiFi instead of wired Ethernet so I don't have to run wires everywhere, and it is compatible with my existing VGA monitor through a $10 adaptor so I don't have to buy another HDMI monitor.
Therefore, I snapped two of these little computer along with one VGA adapter during the compaign.
A few more hours later, I start to discover a limitation of C.H.I.P software:
The Linux kernel comes with CHIP operating system has very limited features.
$ sudo modprobe fuse
modprobe: FATAL: Module fuse not found.
Obviously, the solution to this problem is to compile my own Linux kernel with more features.
The compilation can be done on the C.H.I.P itself.
I managed to do that when the CHIP is powered by a 5V 1A phone charger plus a 1500mAh LiPo battery.
I had the compilation running under screen(1) and attended to it intermittently, and finished in a day.
Named Data Networking (NDN) is a potential future Internet architecture designed as a distribution network.
My last post described how to connect an end host running NDN Forwarding Daemon (NFD) to the NDN Testbed, a backbone NDN network for research purposes, and retrieve contents from that network.
An equally important topic is: how can you publish contents into the backbone network?
As mentioned in the last post, NDN communication is receiver driven.
Interests expressed by the consumer application are forwarded toward the producer following the routing table, and Data packets carrying contents flow back on the reverse path of Interests.
Every end host and router along the path between consumer and producer needs to have a route in its routing table, so that NFD can forward the Interest, hop by hop, toward the producer.
On your own machine, nfdc register command adds a route to the routing table; however, if you want to publish contents into the backbone network and make them available for others to retrieve, you won't be able to directly execute nfdc register command on a terminal of the routers.
How can you add a route without console access?
Prefix Registration Protocol
Before I talk about how to add a route onto a router, let's have a look at how nfdc register works under the hood.
nfdc register implements NFD Management Protocol.
When you execute nfdc register /A udp4://192.0.2.1:6363, the program connects to the local NFD instance via a Unix socket, and sends a command to instruct NFD to add a route for /A prefix toward the specified UDP tunnel.
The command is encoded as an NDN Interest.
All the parameters you entered on the command line are encoded into the name of this Interest.
The name also contains a timestamp to prevent a command being processed twice, and a signature which identifies who is sending the command.
When NFD receives this Interest, it dispatches the Interest to the management module, which would check the signature and the timestamp, and then decode and execute the command.
If everything goes well, the management module generates a successful response as a Data packet, which goes back to nfdc register program and gets displayed on your terminal.
Since the prefix registration command is actually an Interest, you could manually construct the Interest and send it to NFD via a Unix socket, and NFD would execute it indiscriminately, as long as you get the syntax right.
While hackers do good most of the time, we occasionally do evil and play a prank.
The ESP8266, unlike JSON, allows me to do evil.
Thus, I programmed the microcontroller for an evil purpose: slow down the WiFi.
How it Works
802.11 WiFi typically operates in infrastructure mode, where a router acts as an access point, and other hosts (stations) connect to the router on a wireless frequency (a channel).
One property of the wireless channel is that, at any moment, only one party (station or access point) can be transmitting.
If multiple senders are transmitting at the same time, the wireless signal will be jammed, and the recipient is unlikely to receive the packet correctly.
In this case, the sender would have to transmit the packet again at a later time.
Packets can be transmitted at different speeds on the wireless channel.
With 802.11g standard, the maximum speed is 54Mbps, and the minimum is as slow as 1Mbps.
The sender (station or access point) dynamically chooses a speed for every packet depending on its perception of wireless channel quality.
Usually, we prefer to transmit at a higher speed, so that the wireless channel can be freed as soon as possible for other senders to use.
However, if the sender and recipient are far apart, high speed transmission is less likely to succeed because signals can be faded, and a slower speed is necessary to increase the chance of a successful transmission.
Witty Cloud board is an ESP8266 development board that has a unique two-PCB design: the top PCB carries the ESP8266 microcontroller and an AMS1117 voltage regulator, and the bottom PCB carries a CH340G USB-serial chip.
The top PCB can operate independently.
It has a pair of 8-pin male headers that expose ESP8266's GPIO pins, which can be used to control peripherals such as LEDs and buttons.
The bottom PCB is needed only for flashing the ESP8266.
It has a pair of 8-pin female headers.
The top PCB should be inserted into the bottom PCB when the firmware is being flashed from a computer, or when we want to use Arduino's serial monitor.
Sometimes, we may want to simultaneously connect ESP8266's GPIO pins to peripherals, and keep the ability of flashing the firmware or monitoring the serial console from a computer.
Can we achieve that?
From electric point of view, when the male headers on the top PCB are inserted into the female headers on the bottom PCB, each of the 16 pins on one PCB is connected to the corresponding pin on the other PCB via a wire.
Thus, if we connect the two PCBs with 16 jumper wires, everything should work.
But it's tedious to connect 16 wires every time.
Can we connect the two PCBs with less jumper wires?
Let me find out.
One of my favorite electronic elements is the photoresistor, an element whose resistance decreases with increasing incident light intensity.
I played with a photoresistor as part of an electronic building blocks toy kit when I was in elementary school, and made a geocaching trackable out of that experience.
But I want a deeper understanding of the photoresitor: what's the correlation between its conductivity and the light intensity?
Recently I acquired some Witty Cloud boards.
This board is built around an ESP8266 microcontroller; a photoresistor (aka Light Dependent Resistor, LDR) is connected to the analog input port of the ESP8266.
With one line of code in Arduino (analogRead(A0)), we could read the light intensity as a number between 0 and 1023.
However, what's the unit of this number, and how does it translate to the standard units such as lumens?
The readings taken are not in any useful units of light intensity.
Photoresistors are not carefully calibrated sensors.
If you wanted to make a light meter, with absolute measurement of light intensity in meaningful units, you would need to create a lookup table that related readings with readings taken from a properly calibrated light meter.
I get addicted to ESP8266 ever since Losant sent me a builder kit which includes an Adafruit Feather HUZZAH.
Witty Cloud GitWits is one of the cheapest ESP8266 device you can get on the market.
It has a microUSB port with USB-Serial interface, which means no soldering!
The board also contains an RGB LED and a button, which allows me to use it without a breadboard.
So, I decide to go for it!
I ordered the Witty Cloud board from AliExpress, a Chinese E-commerce site.
Ordering experience isn't so good.
For some reason, they cancelled my order due to "difficulty in verifying payment".
I had to upload a scanned copy of my passport and credit card statement, before they would ship my items.
After getting past those non-technical steps, the Witty Cloud development board is in my mailbox 2 weeks later.
There's no doubt I'm excited!
The board is very small and lightweight.
Its dimension is 31mm x 30mm x 18mm.
Its weight is roughly the same as an Adafruit Feather HUZZAH.
Witty Cloud board has two PCBs connected via a pair of 8-pin headers.