Category Archives: Web Architecture

Creating OpenVPN .ovpn Files for Android (Any?) Clients

In another post I cover setting up and OpenVPN server on a Tomato powered router and making client connections to that server.

In setting up a new phone, I see the OpenVPN for Android app will now import yourVPNclient.ovpn files (much easier than transferring and importing the separate key and cert components as covered in my prior post). It took a bit of Googling to find out how to create the .ovpn files, but now that I’ve found the file format, setting one up turns out to be a piece of cake. Here’s the template:

proto udp
port 1194
dev tun

key-direction 1

# insert base64 blob from ca.crt

# insert base64 blob from client1.crt

# insert base64 blob from client1.key

-----BEGIN OpenVPN Static key V1-----
# insert ta.key
-----END OpenVPN Static key V1-----

I edited the “remote” directive to point to my VPN (router’s) dynamic DNS address and then copied the specified parts of the files from the /etc/openvpn directory as created in my prior post to this template. Then saved the consolidated file as myserver+clientname.ovpn.txt on my linux box.

Why with *.txt extension? Because otherwise the bluetooth file transfer from my desktop linux box to my phone would fail (unsupported file type). Text file transfer is supported, .ovpn is apparently not.

I then simply renamed the file on my Android phone to drop the .txt suffix and imported the resulting file in the OpenVPN for Android app (it turns out you can leave it, but the app will include that text in the connection name by default, so I now simply cut it there). I still needed to go through and set some options properly in the app to match my server config (LZO, persistent TUN, etc.), but the heavy lifting was already done.

Connected successfully on my first try! I see no reason why the same file set up would not work in NetworkManager on Linux or some other client, but I haven’t tried myself. Good luck!

Credit for the .ovpn template content goes to this ServerFault discussion thread .

QR Codes as a Password/Key Storage Mechanism

I was doing some recent volunteer work for the Concord Scout House, Inc., setting up a new network and telephony infrastructure for this non-profit enterprise. In setting up the various pieces of equipment, I was sure to create strong passwords and use key and certificate based encryption or similar security mechanisms in order to keep things secure.

Of course, I kept copies for my own records in a suitable electronic format (I personally do local plus encrypted cloud backups of critical files via Spider Oak). As this is a volunteer job, it is very possible someone else will need to do something with this infrastructure at a later point – when I may no longer be involved with the organization. This left me with the problem of how to document and pass on those passwords and keys in a convenient and durable fashion to those who may follow.

I could prepare a DVD or flash drive with the passwords and keys, etc. in simple text files to hand over. This could work fine but also quickly fall prey to changes in applications or operating systems (e.g.: Wordpad or vi? Unix or DOS line feeds?), hardware technology (how many Android phones have a DVD reader? will USB2/3 ports be usable in 10 years?) or simple hardware failure (scratched DVD). For convenience’s sake, I will provide a soft copy on DVD (as that may be stored easily in a file folder) but there’s one medium all organizations still know how to deal with and store safely: paper.

I could simply print out the passwords and certificates/keys as plain text on sheets of paper, but then someone trying to use it would have to accurately type in that text at a later point where/when required. As we’re talking 100+ characters in some cases, this simply won’t work. Here’s where QR codes come in. I happened upon this blog post which mentioned the idea of using QR codes to store such text as a paper record, able to be machine read for accuracy at a later point. Brilliant!

So here’s a practical example of generating such a paper copy of a password using only online free resources, so no software installation required (of course, there are many programs or apps you may install, should you wish to be off-grid):

The password example:


This is a very strong password which, although it isn’t simply random, is still quite secure due to its length (66 chars.) alone. Even the NSA with all its resources would take a very long time to crack it, provided the encryption mechanism doesn’t suffer from a back door or other systemic vulnerability. Given the pseudo english phrasing it would be possible to type or even memorize this password, but it wouldn’t be easy. And a single character discrepancy means not getting in to wherever it protects.

Generating the QR code:
One of many free online QR code generation sites is Taking the above password there, we can plug it into their on-line code generator:
Generating the QR code online

And download the image file of that password in a QR code:
Generated QR code

This QR code can then be placed on a printed page.

Reading the QR code to “reawaken” the text:
There are also many online QR reader/decoding sites, including:

This site provides for you to either take a picture of the code via your device’s camera, or upload a file with the code image (say from a scanner or photo of the paper page) and returns the code content.

Uploading the above QR code image file results in the following:
Decoding the QR image

A perfect copy of the original plain text password!

Unlimited Home Phone Service for Under $3/Month

UPDATE JUN 2015: We’re now two years in and the Anveo solution has been working great. We added an 888 toll-free number for emergency calls to home and to give out for other purposes. SPAM callers are routinely added to our blacklist and have become much fewer as a result. Monthly cost of service is well under $5 typically at our usage, including the extra 888 number. Call quality remains great (the only quality issues we’ve had were a result of our cordless phone being in the same frequency range as our wireless router – sound on a wired phone is fantastic). I’m looking at doing some stuff with Anveo’s new web API to automate some telephony in the future.

UPDATE OCT 2014: Well, it appears Google has changed their mind and what I describe below continues to remain available via Google Voice and the Obi device. I took their word for it and moved my solution over to Anveo (including porting my number to them), which has been pretty robust and much more flexible, but does cost a bit more a month (peanuts, really). However, had I known then that GV would stay available on the Obi, I would have stayed with the solution documented below.

UPDATE OCT 2013: Google has announced that the interface that the Obi device uses to connect with Google Voice will stop working on May 15, 2014. This means that the days of free voice calls using the Obi/GV solution detailed below will be coming to a close at that time. The Obi will still provide VOIP access to other low cost services (like Anveo, as detailed below) going forward.

I’ve been using VOIP (voice over internet protocol) phone service since 2006. I was previously using a small local company, Galaxy Voice, with pretty much zero problems from the start (just an occasional need to reboot my Grandstream ATA or network gear periodically after a power outage, etc.). I was very happy with their plan I had – which cost basically $5 or less monthly (usage-based). Unfortunately, I got a notification email that they were effectively going out of business (due to the failure of their supplier) at the end of June 2013. So the hunt was on for a replacement carrier!

I knew about the possibility of using Asterisk PBX software on a local linux machine to be able to make low/no cost calls using Google Voice (hereafter referred to as “GV”), but setting up an Asterisk server with dialplans, etc. is not for the faint of heart. So I was really looking for a traditional VOIP provider that would replace Galaxy Voice at the cost level we had been used to. The basic consumer-oriented VOIP companies (e.g.: Vonage {which I’d used before for my work-from-home business line} or VoIPo, etc.) all seem to have decided that the ~$10-15 price point is their target, unless you pay for two years in advance. Paying in advance for a long term commitment to something I had no experience with was a bit of a leap and their long term pricing was still on the high side of my target (given that both my wife and I use our cell phones for much of our calling, so the home phone has been mostly just for accounts contacts, etc. and not daily use). So another solution was desired.

Google Voice

I’ve had GV in place for several applications up to now and was very pleased with the service and features. For instance, I set up the New England Folk Festival Association (NEFFA), a purely volunteer-run organization, to use a GV account as their main number which then sends to select board members an email transcription and vmail link for follow up action. Also my wife and I have GV numbers which we give out so folks have “one number” access to us on both our cell phones and home phone. Additionally, GV offers SPAM filtering for calls much like their well known email filtering! So going with GV was a great idea from my perspective. Now, just how to do it without major complications…

Obihai ObiTalk Devices

My research ultimately accidentally uncovered the Obihai tech ObiTalk devices, which promised easy GV configuration right out of the box. As I sometimes subscribe to the “pay just a little more to get disproportionately more” school of tech purchasing, I went with their model 110 device (~$50) instead of a 100 (~$40). This way, if I ever found a need to connect my new Obi110 with my old Grandstream HT-386, I’d have the analog phone port available.

Porting Fun

The biggest difficulty in the whole process was working through porting our old home phone number from the rapidly dying Galaxyvoice through to Google Voice. Because Google only supports porting in mobile numbers, I had to port the number twice: from Galaxy to a cell phone provider (I used Tracfone as I already had an old phone for them sitting around) and then from Tracfone to Google Voice. Long story short, this process cost ~$40 total and took a little over a week including the shipment of a new SIM card.

Setting Things Up with the Obi110 and GV

As the first stage of the porting process was under way, I created a new Google account to use solely for the home phone service. I did this standalone account as a security mechanism so, even if the account got hacked, there would be no additional risk of my primary account’s other personal information (email addresses, etc.) being leaked. This let me pick a new local phone number to use as a GV number in the interim. I then used that account’s details to set up and test the Obi110 device. It worked great, no issues with call quality and NO bill. The one major limitation I discovered is that GV doesn’t support 911 calls.

E911 Support and Other Feature Needs – Anveo

So to cover the 911 need (we have a small child at home and working 911 is always a great idea), I opted to sign up for inbound and outbound service through (see link below) and use that as the second VOIP service registered on the Obi110. This worked out for several reasons… for one, I needed to provide a number in my parents’ area code ($2 per month with unlimited incoming minutes) so they could call me from the facility they are now living in (which only allows local calls) and Google Voice did not currently have any local numbers available – so GV was not an option. Secondly, they provide E911 service for a very low monthly fee ($0.80/month) plus the outgoing call rate (low, and we hope to never have to dial 911). As a bonus, Anveo supports both FAX receipt (free) and sending (very low rate) using that same number. Third, as Google Voice does not allow for one GV number to forward to another GV number [*I later discovered a unique workaround for this, see below], we’d need a new number for my wife’s and my GV “one number” numbers to forward to. Fourthly, Anveo allows you to set the outgoing caller ID to be any number you can prove you own (by answering a call at that number), so any call we place via either GV or Anveo will always show our home phone number as the caller ID.

Setting up the Anveo service on the Obi110 was really easy through their portal and worked straight away. Anveo provides a ‘933’ number you can call to test 911 without bothering your local emergency center, which showed all was set up properly. BTW, Anveo’s payment scheme is pre-paid, much like filling a gas tank: you use some payment mechanism (PayPal is preferred) to put funds on account with them and they bill against (deduct from) that balance automatically for the service used. They’ll alert you when your account balance gets low so you can top it up. So far I am very happy with Anveo – they responded to (by implementing!) a couple of feature requests/fixes I submitted to their feedback form in under 24 hours! When did you ever see that from the likes of AT&T or Comcast?

Buttoning Up

Once the Tracfone port completed (which required much hand holding/follow-up on my part due to the Galaxyvoice situation), the GV porting was submitted and finished in just a couple of days. When done, the old home phone number now rang straight through to the phones attached to the Obi110. Success! The interim GV phone number will go away in a short while (but if I wanted to keep it as a second number they offer to do so for a one time fee of $20, before that expiration date). As with any VOIP solution, the Obi110 is subject to power outage downtime, so I added it to the set of machines powered through our UPS for battery back up. And we can always call on one of our mobiles during an extended or widespread outage.

Bottom Line

We now have a full phone solution fielding more features than we were looking for, paying just $2.80/month (even lower once I take advantage of Anveo’s 1 year prepay service discount).

Regular calls come in and go out through Google Voice. Calls from my parents (and FAXes) come in through Anveo and should we ever call 911 it will go through them (as can outbound FAXes via their web portal). We don’t have to do anything special for calls, just dial (or answer) the home phone and the Obi110 routes it all correctly. We’ve been using this solution for over a month and nobody has said a thing about the GV call quality or not being able to reach us – so all is well. The one downside is caller ID. Unfortunately GV has very limited caller ID – all calls processed via GV show only the phone number (not name) passed through (both in- and outgoing) to any phones involved (there’s a lot of folks clamoring for caller ID with name to be added, which I hope they do). Google does offer somewhat better caller ID via the voicemail and contacts system – so long as you tag a contact to a given phone number, the GV web portal shows the contact name you set (for instance, on a voicemail transcription).

The biggest chore with the transition was researching the possible solutions (which I hope you benefit from here :)). Should you value this info and sign up for Anveo service, I hope you will provide my referral code 3018755 at the time of sign up so I can get a small service credit, you enter it here in the signup form:Anveo-Referral

Google Voice to Google Voice Forwarding Discovery

As has been widely lamented on the web, GV does not allow for one GV number to forward to another. This is a significant limitation for many hoping to use GV as their primary carrier, and I anticipated running into it once we ported our home phone number over to GV. I expected that my wife and I would need to change our personal GV “one number” numbers to point to the new Anveo number we provisioned above (which is why I went for the Anveo $2/month unlimited incoming service vs. the $1/month + usage minutes service – our monthly total cost could be as low as $1+0.80/month as a result of my GV internal forwarding discovery).

Remember, we had already had our separate GV numbers set up with the home number as a forwarding phone (whilst provisioned via the old VOIP supplier). To my happy discovery, our separate GV numbers continued to ring through to our home phone number after it was ported to GV! So it appears that the GV system is perfectly capable of forwarding from one GV number to another, they just preclude it when you set up a forwarding number. The key is to already have the forwarding set up while the target number is outside the GV system and then to port the number in, which will bypass the apparent step of checking for GV internal forwarding.

Again, I hope you find this information helpful and I definitely recommend implementing this solution if it meets your needs. Please do consider using my Anveo referral code 3018755 if you follow our path and use them. Happy calling!

Fun with 1-Wire Devices in Linux using Digitemp and owfs

I’m currently working on a Christmas present for my new in-laws.

The goal is to be able to remotely monitor the temperature and humidity at another location over the internet. I want to do this at a reasonably low cost, using very little power and not taking up a lot of space in the target location.

To meet these goals, I’ve designed a solution using Dallas/Maxim 1-Wire devices. These are low cost sensors that interface using a very simple parallel bus, wired (with, despite the name, 2-3 wires) over either a standard cat-5 ethernet cable or RJ-11/RJ-12 style cable. I’m going to drive them using a small embedded Linux system for silent and low power operation.

The sensors and adapters arrived a couple of days ago. I had other projects under way, so playing with them had to wait until today. I’m posting the following because the adapter I’m using is relatively little known, meaning that almost everything I could find for software usage examples did not cover this adapter. After several hours, I have now found the secret sauce and I’m going to pass along the recipe to you (and me, in case I forget!).

Here’s the parts I’m using:

  • Linksys NSLU-2 Network Storage Link, hacked to run Unslung 6.8 (a modification of the original embedded Linux provided by Cisco on this unit, which allows running many other SW packages)
  • iButtonLink LinkUSB-SD 1-Wire Bus Adapter
  • iButtonLink T-Sense-SD Temperature Sensor
  • and, eventually, a AAG TAI-8540 humidity sensor

I’d planned to use a DS-9490R adapter, which is very well documented for SW use, but was finding them sold out wherever I looked. Same deal for the TAI-8540 (but we could always add the humidity sensor later). Looking for alternatives so the gift would be available on time got me to iButtonLink. Their LinkUSB series are supposed to be superior performing masters, and they were available.

My first task was to determine and get the required software installed. My original desire was to use the oww (1-Wire Weather) package, which was developed to work with a dedicated hobbyist weather station product that Dallas once had available. It has since expanded to support other standalone sensors and is available in the Unslung ipkg feed, so it can be installed and used without needing to be compiled. It has a bunch of great features, including the ability to upload/push data to a server for viewing, so no firewall and DNS shenanigans would be involved. This all would be great, but I’ve not yet been able to get it to work with the LinkUSB adapter. So searching on… I landed on two other packages: owfs (1-wire file system) and DigiTemp. Again, both of these are available as native ipkg feeds for Unslung (the selection is impressive).


I tried owfs first, as there were many on-line comments about DigiTemp being limited to temperature measurement only, and I knew we wanted to do humidity too. I installed the software according to the instructions on the owfs site. Here is what I did, running as root:

ipkg update
ipkg install owfs
ipkg install owshell owcapi

This automatically installed the start-up scripts too, so owfs would be there after a reboot. Unfortunately, the parameters it used were not compatible with this adapter and no sensors showed when viewing the resulting summary page via . I also found the output on that web page to be very confusing at first glance and not made plain on their site, so I couldn’t figure out why I wasn’t seeing any sensors and temps. I poked around using lsusb, etc. but couldn’t find the 1-wire file system entries that were supposedly created by this package. After a frustrating period, I punted and moved on to DigiTemp. But I’d be back later… mere SW can’t beat my persistence!


DigiTemp is a package designed to do just what it sounds like, grab temperatures from digital devices. In this case, 1-Wire sensors. Some people have gone all out with it. We had more modest goals, and it turns out that the humidity sensor I wanted to use is actually supported under DigiTemp with a serial (not USB) adapter. There might be hope yet…

So I install DigiTemp following instructions on the NSLU2-Linux site, but run into the problem with using a non-DS9490-R adapter once more (all examples were for that one). It turns out there is no single actual digitemp command, but rather a different one based on each adapter type, and mine isn’t listed as one of them. Out of frustration, I decide to try all of them. Amazingly, the last one works! I can see devices!

# digitemp_DS9097U -w -s /dev/ttyUSB0
DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane
GNU Public License v2.0 -
Turning off all DS2409 Couplers
Devices on the Main LAN
280097A702000098 : DS18B20 Temperature Sensor
28848BD50200005C : DS18B20 Temperature Sensor

So here’s my commands to install, configure and use DigiTemp with the LinkUSB adapter:

# digitemp_DS9097U -i -c /etc/digitemp.conf -s /dev/ttyUSB0
DigiTemp v3.5.0 Copyright 1996-2007 by Brian C. Lane
GNU Public License v2.0 -
Turning off all DS2409 Couplers
Searching the 1-Wire LAN
280097A702000098 : DS18B20 Temperature Sensor
28848BD50200005C : DS18B20 Temperature Sensor
ROM #0 : 280097A702000098
ROM #1 : 28848BD50200005C
Wrote /etc/digitemp.conf
# digitemp_DS9097U -q -c /etc/digitemp.conf -a
Dec 03 18:55:38 Sensor 0 C: 19.50 F: 67.10
Dec 03 18:55:39 Sensor 1 C: 21.19 F: 70.14

Yay, we see sensors and actual temperatures! It works. Now from this, I get some clues that I think might help with owfs. So back to crack that nut.

OWFS Redux

From the above, I know I have a device that looks like a DS9097U to software, and it appears to be seen on /dev/ttyUSB0. Armed with this, I poke around owfs and force it to use other settings than the default start-up scripts supply. This means killing all owftpd, owhttpd and owfs processes (via ps -ef and kill -9). I then restart them using /dev/ttyUSB0:

owfs -F -d /dev/ttyUSB0 -m /tmp/1wire
owhttpd -F -p 3001 -d /dev/ttyUSB0

Note: I’d actually installed a second adapter and sensor in-between activities here, so I modified those commands to add the ttyUSB1 as well (you will see those in the output below). And finally I see something in the /tmp/1wire directory!

# ls
28.0097A7020000 28.75BAA7020000 28.848BD5020000 alarm bus.0 bus.1 settings simultaneous statistics structure system uncached

You can then get some data from a sensor by treating it as a normal text file under Linux, e.g.:

# cat 28.75BAA7020000/temperature

And when I look at the web interface, I can finally browse these devices as well!

Other Magic

There is one other thing I did a couple of times along the way, but I can’t now remember in what exact order I did it for the last time. This may or may not impact the above for you. I got the clue from this oww page. In there is a bunch of info on using the NSLU-2 with oww, which of course includes that more standard adapter but listed other possibilities. From that, I installed the kernel modules that I thought applied to the LinkUSB:

ipkg install kernel-module-usbserial
ipkg install kernel-module-ftdi-sio

After doing so, I then had to load those modules:
insmod usbserial
insmod ftdi_sio
(note the underscore instead of dash here, tricky!).

After this, the NSLU-2 reported via dmesg seeing the LinkUSB adapters (which are connected via a USB hub):

hub.c: new USB device 00:01.0-1, assigned address 3
Device descriptor:8 bytes received.
Device descriptor:18 bytes received.
hub.c: USB hub found
hub.c: 4 ports detected
hub.c: new USB device 00:01.0-1.1, assigned address 4
Device descriptor:8 bytes received.
Device descriptor:18 bytes received.
usbserial.c: FTDI FT232BM Compatible converter detected
usbserial.c: FTDI FT232BM Compatible converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
hub.c: new USB device 00:01.0-1.3, assigned address 5
Device descriptor:8 bytes received.
Device descriptor:18 bytes received.
usbserial.c: FTDI FT232BM Compatible converter detected
usbserial.c: FTDI FT232BM Compatible converter now attached to ttyUSB1 (or usb/tts/1 for devfs)
hub.c: new USB device 00:01.0-1.4, assigned address 6

So this was most likely required for DigiTemp (and/or owfs) to see these devices on ttyUSBn. I will verify this later when I have more time to set up the rest of this project, meaning to: collect the sensor output, create pretty information from it and make it available for remote access.

Off to dinner, but more to come!

Debut of the all new

Tonight I finished initial delivery of a large project I’ve had going with the Concord Scout House, Inc. (CSH). I was approached to do some web work with them as a result of what I’d previously done with

This project has been going on, to some degree, since January of 2010 (non-profits work seems to go in fits and starts). CSH is a group whose prior web site was showing its age. Users and other constituents were frustrated that information on the site was old and inaccurate, but there was no easy way to update the content via the folks then involved. The site was running on an infrastructure that was out of proportion to the group’s needs (but had been provided at no cost), and was too complicated for them to manage themselves.

The solution I composed included using a very simple yet powerful GPL’d Content Management Sysytem (CMS) which their non-technical content managers could use to maintain the public-facing site. At the same time, I secured them a non-profit (aka Education) account for using the Google Apps platform and integrated that with their web presence as a backend suite. The end result meets their current needs and will scale into the future easily. Should I be hit by a truck, the technologies involved are much more mainstream and should be able to be picked up by someone else with the right skills.

And the best part? It will cost them well under $50/year to operate — web, email, calendar, docs: everything. Yep, less than fifty bucks.

I can’t wait to see what CSH do with it, now that the modern tools are in their hands! You can check it out here: .