In an earlier blog post I noted that I like things that just work. To this end one of the User Stories I related to the Library in a Box team was “As a mobile app user I would like the library to be found automatically if the library service is available on the network so that I can connect to it without requiring intervention (typing in a computer name or IP address).”
This sounds simple enough, and indeed it should be. But like many things in the world of technology things aren’t as simple as they might first seem.
Read on to share some of our discoveries about challenges with zeroconf networking.One of the features I appreciate on Apple products is their ability to recognize services offered by other Apple products on the same network. Apple accomplishes this through the use of Bonjour, a zero-configuration networking protocol implementation. The same multicast DNS approach used by Apple is also available under Linux operating systems through the Avahi daemon.
Our Library in a Box is running under Ubuntu 14.04, so a quick
apt-get install avahi-daemon
and the service was installed and started. With the service up and running I created a library.service configuration file
<?xml version="1.0" standalone='no'?>
<!--*-nxml-*-->
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name>library</name>
<service>
<type>_http._tcp</type>
<port>8080</port>
</service>
</service-group>
under
/etc/avahi/services
which identified that the library was running on port 8080 and a restart of the avahi-daemon
/etc/init.d/avahi-daemon restart
and we were good to go. The service availability was broadcast and things worked beautifully in my local environment.
With things working well in the local environment I went to the production system and worked with a team member to get the avahi-daemon installed and the library.service added. Getting things installed and configured took less than a minute, and I returned to my desk satisfied. I fired up the library application on my iPhone and…
Hmmm…
the service wasn’t discovered.
I reconfirmed that it wasn’t discovered using Bonjour in Safari. Why wasn’t it working.
Some digging and discussion with my IT guys revealed the problem. The server that our Library system was running on is on a different subnet than all of the other computers, a subnet reserved exclusively for servers. The multicast DNS information isn’t forwarded out of that subnet, so neither the mobile clients or desktop computers would receive the multicast advertising of service availability.
Understandably our network is more complex than what many companies have or need. To ensure confidentiality of client information strict network segmenting is put in place so every team operates within a sandbox that is inaccessible to other teams. A few key internal servers and related services are made available to these isolated networks, but broadcast services are not forwarded. If we were operating in an private company configured with a single network segment, things would work fine.
Since we anticipate that our Library system might very well be deployed into this more common environment, we still wanted to test to make sure that auto-configuration would work. How can we do this without opening firewalls and or making other changes to the network?
The answer came in the form of pi, Raspberry Pi, to be exact. The Raspberry Pi is a very small computer, consisting of a System on a Chip (SoC) connected to a circuit board providing USB, HDMI, SD Card, and other component connectivity options. Basically a tiny and very inexpensive (US$35) computer. I have several Raspberry Pis that I’ve done different things with. One powers a display in our lobby that we use to great visitors, show project status, etc. Another couple I use to conduct various experiments on. I’m running Raspbian, a version of Debian Linux specially designed for the Raspberry Pis ARM architecture. Since both Raspbian and Ubuntu are based on Debian Linux, the tools available are very similar. The Pis would be perfect for what I needed.
I set one Rapsberry Pi up for both of the networks — one wired, one wireless — that my Library in a Box team was working from. Using the Raspberry Pi I could broadcast the service as if it was being delivered from the Raspberry Pi, then, using iptables, I could transparently forward requests sent to the Raspberry Pis to the server actually providing the Library service. This allowed the mobile clients to see the service advertisement and connect to the advertised address as if it were the end-point, allowing us to test the automated service discovery feature without making any changes to the network configuration.
In the spirit of transparency I’ll share that getting the iptables configuration working properly was time consuming for me. While I’ve had some exposure to iptables in the past including a similar port forwarding scenario this was the first time I’ve tried to use them in earnest. I spent a very long day trying to get everything working on both Pis. Day one I learned a lot about iptables, but I didn’t have things working yet. Early the next morning I got things working properly. Actually it only took about four commands to get everything to work properly, but figuring out the right four commands was a challenge.
Remember the opening of this blog: “But like many things in the world of technology things aren’t as simple as they might first seem”? The ad-hoc discovery of the zeroconf broadcast not propagating across our segmented networks and trying to get my Raspberry Pis configured as a work-around to this problem both underline this point. Great learning, simple solution, but getting there took a lot more time than I expected. That’s life in the world of technology. I’m sure anyone who’s worked in IT can empathize.
Our “in a Box” projects continue to be an interesting learning ground. If you have questions regarding the application or any of the techniques or technology we’re applying don’t hesitate asking us. We’ll be happy to share.
