Network applications demos in coffeehouses

Preparing a demo in your office is stressful enough – the demo need to be tested and rehearsed again and again until the time of the demo itself. A demo of a network application is even more challenging because even in a controlled environment like an office you never know when a coworker will bring down the network by transferring huge files, or when a system admin will decide to do maintenance on a server at the same time (all real life examples, sadly). But there is nothing worse than having to demo a network application in a coffeehouse or a restaurant, which is, it seems, where 99% of these demo are done in the Bay Area. I did a lot of demos of a network application in such conditions in the last 18 months, without one single failure, so this blog entry will explain the environment I used, in the hope that it will be useful to someone else.

The WiFi in these places is generally slow and flaky, so the worst thing to do would be to use it. That’s OK, I do not trust so-called experts to provide me a decent network, so why would I expect people whose job is to prepare a good cup of coffee to do better? Instead I used a laptop on which I installed the same software that is running in our data center, and I configured the laptop to be a WiFi Access Point. It was not the network application that was tailored to run on a special network (which would required to build an application that is different from the real product), it was my laptop that was simulating a very small instance of the Internet.

The first step was to find a Wifi adapter that could be used as a a Wifi Access Point (AP). I needed a adapter that is supported by the hostapd Debian package so I chose one from SIIG. The configuration of hostapd looks like this (/etc/hostapd/hostapd.conf):

interface=wlan1
driver=nl80211
ssid=demo
country_code=US
hw_mode=g
channel=5
macaddr_acl=0
auth_algs=3
wpa=2
wpa_passphrase=Wrokwait3
wpa_key_mgmt=WPA-PSK WPA-EAP

The adapter needs an IP address, which is configured in /etc/network/interfaces:

allow-hotplug wlan1
iface wlan1 inet static
  address 10.254.251.1
  netmask 255.255.255.0

We need a DHCP server (package isc-dhcp-server) to allocate IP addresses to the devices that will connect to our AP (/etc/dhcp/dhcpd.conf):

subnet 10.254.251.0 netmask 255.255.255.0 {
  range 10.254.251.10 10.254.251.20;
  option routers 10.254.251.1;
  option domain-name-servers 10.254.251.1;
}

You can see here that the laptop will also be our DNS server. As I explained above we cannot depend on a connection to the real Internet, so we will have to also serve DNS requests. My favorite DNS server is djbdns so after installing the package I created a new tinydns instance (tinydns is the djbdns component that implements an authoritative DNS server):

$ tinydns-conf tinydns tinydns /etc/service/tinydns 10.254.251.1

The next step was to start tcpdump on the IP address of the AP to see what requests the network application will send. For each of them I needed to install the corresponding server and to add the DNS resource records in djbdns. For example the devices I used for the demo (Android Nexus One) need to synchronize with NTP, so I installed the ntp server so it is running on the AP (/etc/default/ntp):

NTPD_OPTS='-g -I wlan1'

Then I added the following lines in djbdns to redirect the devices to my NTP server (/etc/service/tinydns/root/data):

.ntp.org:10.254.251.1:ns1.ntp.org
=north-america.pool.ntp.org:10.254.251.1:3600

Finally because my demo devices were Android based, I printed the QR Code of the WiFi demo network and taped it directly on the Wifi adapter so the Android devices can be easily configured with the ZXing app.