Sunday, 29 January 2017

Setting up a VPN on Android and Raspberry Pi (Private Internet Access - PIA)

There are a number of reason you might want to get access to a VPN, some legitimate and some a little shady like protecting yourself while downloading torrents. My main reason is that I do a bit of travelling and find myself connecting to random free Wi-Fi services and it's always bothered me that someone is probably intercepting any messages that are unencrypted and using my data (man-in-the-middle attack). It also doesn't hurt to be able to access any websites I want, regardless of and government mandates blocks to ISPs.

I decided to go with Private Internet Access as my VPN provider, they seemed to offer a wide range of functionality and multi-platform support. In my case I was focused on an Android app and easy Raspberry Pi configuration.

Note: I paid for my subscription using the website which charged me in USD. After downloading the app I realised it would have been cheaper to sign up through the app, it was advertised about $5 cheaper than I paid in AUD after conversion.


  1. Download the Android app from the app store
  2. Enter your username and password from the email you got when you subscribed
  3. Done! It's that easy

Raspberry Pi:

I used this description on the PIA forums to get my Raspberry Pi configured but had to make a couple of small changes to get it to work. It's a bit of a process, but here are the steps I followed:

  1. Log in to your device, I use the terminal app Putty for Windows to remote in to my device
  2. Make sure you device is up to date
    • sudo apt-get update
    • sudo apt-get upgrade
  3. Install openvpn and the network manager to configure the VPN on the Pi
    1. sudo apt-get install network-manager-openvpn openvpn
  4. Create a new folder for the PIA configuration files and download the PIA openvpn configurations
    • sudo mkdir  openvpn-pia
    • cd openvpn-pia
    • sudo wget
  5. Extract the openvpn zip file
    • sudo unzip
  6. Try to connect using one of the default openvpn configurations for your region. You'll be asked for your username and password
    • sudo openvpn --config ./AU\ Sydney.ovpn
    • enter username and password
  7. Once the script is running you should see a number of messages printed to the terminal, one of which should be 'Initialization Sequence Completed'. If this doesn't happen you may have mucked up one of the previous steps.
  8. The Raspberry Pi will not terminate the script when it is finished, you'll need to do this yourself by pressing 'CTRL -c' to kill the script
  9. Assuming everything went well we will now create a config file to store our username and password
    • sudo nano /etc/openvpn/login.conf
  10. The file created will be blank, enter only your username and password on separate lines as I have below
    • p123456 
    • AbCdEF123
  11. Press 'CTRL -x' to exit and enter 'y'  and 'Enter' to save the file
  12.  Change the file permission with the following command
    • sudo chmod 400 /etc/openvpn/login.conf
  13. Make a copy of the configuration file we have been previously using in the /etc/openvpn/ folder and change the file extension to .conf
    • sudo cp AU\ Sydney.ovpn /etc/openvpn/Sydney.conf
  14. Edit the .conf file we copied and add the login.conf file to the file at the line auth-user-pass. It should change from the first point to the second as shown below
    • sudo nano /etc/openvpn/Sydney.conf
    • auth-user-pass [CHANGE THIS LINE]
    • auth-user-pass login.conf [THIS IS HOW IT SHOULD LOOK AFTER CHANGE]
    • hit 'CTRL -x' to exit and type 'y' and hit 'Enter' to save
  15. You now need to copy the ca.rsa.2048.crtfile and the crl.rsa.2048.pem file to the /etc/openvpn folder. You won't see these files in your folder using the standard 'ls' command, you will need to use 'ls -a' to show hidden files
    • sudo cp ca.rsa.2048.crt /etc/openvpn/
    • sudo cp crl.rsa.2048.pem /etc/openvpn/
  16. Navigate to the openvpn folder and test the configuration file we have edited to make sure it is still working as it was in step 7
    • cd /etc/openvpn/
    • sudo openvpn Sydney.conf
  17. If everything went well you should see the 'Initialization Sequence Complete' again
  18. Now we need to add the configuration to the startup sequence so the VPN connection is made on boot. We will need to open /etc/default/openvpn file and add an autostart option
    • sudo nano /etc/default/openvpn
    • add the line 'AUTOSTART="Sydney" to the autostart commands so it looks like:
      • #AUTOSTART="all"
      • #AUTOSTART="none"
      • #AUTOSTART="home office"
      • AUTOSTART="Sydney"
  19. Done! Everything should be working, but we should test the setup to make sure everything is working on boot
    • sudo reboot
    • wget -O - -q ; echo
  20. If everything worked you should see a different IP to the one your ISP has given you

Happy restriction-free browsing

Saturday, 21 January 2017

HOME AUTOMATION: WeMo Maker as electric door latch relay

I recently tested the WeMo Maker to replace the electric door strike relay I had installed that was controlled via my doorbell. I picked it up for $69 from Bunnings Warehouse.
The idea was that I would replace the wireless relay that came with my doorbell for the Wemo Maker and then use the WeMo app (possibly with IFTTT) to unlock the door from my phone. I didn't plan to use the sensor input feature on the device. 

Setup was easy, I followed the instructions that came with the device and was up and running in about 15 minutes. It was soon after setup that I realised the limitations of the device...

The issues:

In order to work as an electric door strike relay I required the device to function as a momentary switch, turning on for a short amount of time and then turning back off to lock the door again. Typically devices built for door unlocking operations have a latching delay that can be set by a jumper, meaning that when the door is remotely unlocked it will be held unlocked for the set amount of time. So with the WeMo Maker I needed it to do the same.
When I took a look at the settings of the device I noticed there was no setting for the 'on time' of the relay. Some googling led me to discover that the WeMo Maker is only capable of a 300ms on time as set by the firmware, making the device pretty much useless for my remote entry needs without some extra circuitry.

IFTTT to the rescue:

WeMo have made their products compatible with the IFTTT platform making it possible to connect hundreds of services to the device.
After sifting through all the services trying to find one that allowed me to connect a countdown timer to the device, I found that one of the default WeMo Maker IFTTT actions was "on then off after 2 seconds". Perfect!

The results:

In reality the way this setup had me using the device was not ideal, be default the device didn't allow me to set a relay 'on time'. While I was able to get around this with IFTTT the reality of the service was that I was getting an approximately 8 second delay from pressing the button widget on my phone to having the door lock open. Combine this with the relatively short amount of time that the lock was open and the result was me having to just repeatedly pull on the door waiting for it to unlock after pressing the unlock button. Not ideal given the cost of the device. 

Securing IoT Devices from Mirai BotNet Vulnerability

I use the tinyCam Monitor app to view an IP camera I have setup at home. One of the more recent updates introduced a nice initiative to check network devices for the Mirai botnet vunerability by checking known default usernames and passwords that were given when the hackers released the Mirai source code.

I opened the app to change some settings and noticed my network enabled door bell (probably routing through China) was listed as a vulnerable device. Pretty scary!

You can read about it on the wiki page, but here is a quick summary of Mirai: devices infected by Mirai scan the internet for IoT devices with default username and passwords and attempt to gain access and infect other devices. On command the infected devices (bots) can be used to create a massive distributed DDoS attack. Luckily the malware isn't written in to memory so rebooting the device should clear it, but if vulnerable devices are not patched then the malware will quickly reappear.

I did some searching and didn't find any simple tools that would scan my network for vulnerable devices, so I wrote a little python script that checks a given host (I used my router to see what devices were connected on what IPs) against the list of known default usernames and passwords put out when the Mirai hackers released the source code.

import getpass
import sys
import telnetlib

HOST = ""

userPassList = [["666666","666666"],["888888","888888"],["admin",""],

print "Testing Mirai botnet default usenames and passwords on host:" + HOST

for userPass in userPassList:
    user = userPass[0]
    password = userPass[1]

        tn = telnetlib.Telnet(HOST, 23, 5)
        tn.read_until("login: ")
        tn.write(user + "\n")
        if password:
            tn.read_until("Password: ")
            tn.write(password + "\n")
     print "######WARNING###### Connected on port " + portNumber + " with Username:" + user + " Password: " + password
        print tn.read_all()

        print "Unsuccessful attempt Username:" + user + " Password:" + password

It's a work in progress but so far it works well enough for me.

I already knew my wireless door bell had a default username and password for the telnet port so I set out to change this to something else.

Changing the Telnet Password

My device didn't have the usual passwd command in linux that you would use to change the password of a user. I did some hunting and found a command chpasswd in the /usr/sbin/ directory. I followed the instructions here to work out how to use the command, then I changed the password of the root user by doing the following:

  1. Telnet in to the device (I use PuTTY)
  2. Enter the default username and password you discovered earlier
  3. Type the command "chpasswd" in and press enter
  4. Enter the new username and password in the format "username:password" and press enter
  5. Hit ctrl+d to exit the script
That's it! You have gone a long way toward making your device (and the internet) a safer place

Wednesday, 18 January 2017

HOME AUTOMATION: Automated blinds - Teptron Move

Adding automated blinds to my home automation system has always been something I wanted to do. The promise of waking up to natural lighting the morning or coming home to a cool house on a hot day is what I imagine is an essential part of the house of the future.

I did some research and didn't find much in the way of a cheap DIY solution on the market, most of the solutions were at least a couple of hundred dollars per unit and required 240v wiring.
That was until I found the Teptron Move Kickstarter campaign, promising to give me everything I wanted for about $60 per blind including a solar charging panel. It was the cheapest of the DIY solutions I found and didn't require and extra wiring.

The reality:

The Kickstarter campaign took longer than expected (as usual) but I did eventually get my Bluetooth controlled blinds. I'm using the units on block-out roller blinks and opted to install with the double sided adhesive tape to try the system out before drilling any holes.
My experience with the system has been mixed, but here are the main points:
  • Be careful where you place the mechanism. May work on the way up but not down. My blinds catch on the Move unit on their way down so I need to stand by the unit to flick the bottom of the blind over the unit.
  • When I initially ordered the device there was no mention of load rating. I have big blinds and am right on the edge of capability for two out of three blinds and overweight on the third. This is probably not an issue if you are using the device for vertical blinds
  • Being over the load rating I needed to pull some serious tension on the beaded chain to get the device to work properly. As you can imagine this does not work well with the double sided tape over a long period of time in the heat of summer.
  • It's not always convenient to use my phone to open the blind. This point has probably been my single biggest issue with the Move unit
  • In my situation the physical buttons are impossible to get to when the blind is closed

Chain tension and double sided tape over time

Chain cover moved as it was getting in the way

Physical buttons hidden by the blind when closed

App (Android) v1.02

It was immediately obvious that the developers had over promised on this one. It's been a few months now and updates don't seem to be making it out, there is not much functionality at the moment and a few things are clearly missing:
  • I was only able to pair with one phone. I initially did it from a tablet then had to reset the device to connect with my phone, but somehow now both my phone and tablet can connect with the unit and set blind position
  • No automation functionality at the moment
  • No IFTTT support 
  • My blinds are back to front to the pictures shown
  • Blind doesn't always go to the correct position as per the slider bar, but has never gone past the end points
My blind is closed in the state shown

No automation support


After using the devices for a little over one month the biggest issue I have with my system is not the devices fault, but my blinds catch on the way down and jam up on the unit itself. It's really annoying. I'm waiting on another Kickstarter campaign to send me my 3D printer so I can make a deflector bracket for the blind.

Blind caught in chain on the way down

My second biggest pain point with the device is that it's not as convenient as I thought it would be due to the placement of the manual control buttons. In my configuration the physical buttons are hidden behind the blind and it's really annoying to access.

Move unit hidden behind the blind

In reality without the automation component of the blinds I use the physical buttons 95% of the time, so it's pretty annoying to use at the moment. I'm considering a couple of hacks to expose the buttons for use with a wired remote but I'm not of the possibility of that at the moment, the unit isn't as easy to pull apart as I first though.

Update - 21/01/2017

I've tried to disassemble my move unit with no luck. The unit really doesn't appear to be made to disassemble...

Update - 24/01/2017

I contacted Teptron directly, they tell me the device is glued together and would need to be destroyed to be disassembled. Going to need to think of something else...

Tuesday, 17 January 2017


I found a few sites showing how to link Blynk with IFTTT using the Maker channel service. This thread on the Blynk forums gives a good rundown of how to create a recipe but some of the details seem to be out of date. To get it working you will need to do the following:

  1. Ping the Blynk server ( and copy the IP address. In Australia I'm getting
  2. Create a new IFTTT recipe using the Maker service and use the following parameters:
    1. URL:
    2. Method: GET
    3. Content Type: application/json
    4. Body: leave it blank

Remember to replace "YOUR_AUTH_TOKEN" with you actual token from you Blynk project, PIN_NUMBER with the pin you want to set (eg: D1 or V0) and VALUE with the value you want to set. You should end up with something like this:

Sunday, 15 January 2017

HOME AUTOMATION: Web Enabled Relay with Blynk

One of the most useful parts of my home automation system is internet enabled entry control that lets me use my phone to get in to my house when I don't have keys on me or it's just easier to use my phone. This setup requires an electric door strike and an wifi enabled relay.

I've tried a number of ways to get an easy to use solution to work from both the web and my phone including:

I won't go over the pros and cons of each here, I'll just give the details on how to get it working with Blynk.

Why Blynk?

There are a lot or reasons listed on the Blynk website, but the reasons I went for it over the competition were:
  • Android and iOS app
  • Arduino support 
  • Really easy to use
  • Free account option 
  • SSL support
  • Local server support
I'm yet to find anything that was as simple to use as Blynk. From the time I took out my tub of Wemos modules it took me 15 minutes to get a working example (including some troubleshooting!)

To get my wireless relay set up I used the following:
  • Wemos D1 mini (ESP8266)
  • Wemos D1 mini relay shield 
  • 12v power supply 
  • Electric door strike 
  • Soldering iron and heat shrink 
  • Blynk account (done via the app)
  • Computer with Arduino Studio installed and Sparkfun ESP8266 library installed via the library manager
  • Android or iOS device with the Blynk app installed

The default Blynk examples only show how to mirror the pins of the Arduino from the Android/iOS app. I wasn't able to find any way to hold a pin high once triggered for a set period of time within the Android app, so I developed an Arduino sketch (below) that uses virtual IO to trigger and latch physical IO.

Arduino Programming

The Wemos D1 Mini board has a built in USB to serial converter so all we need to do is plug in a micro USB cable to the device and install the required drivers.
Once we have Arduino Studio installed we need to install the toolchain for the ESP8266 board, I did this by following the instructions on the esp8266 github page. Wemos also has some libraries for their boards that give some examples of using their shields.

Once this is all setup the D1 mini can be programmed as you would any other Arduino board. Blynk also has a library that can be installed from the library manager with examples for the ESP8266 boards. One of those examples shows how to connect to Blynk servers using SSL.

Tip: Debugging over serial can be useful to ensure your device is connecting to your wireless network. Make sure your serial terminal is set to the correct baud rate, in the default examples the baud rate is set to 9600 but the default terminal rate is 155200 kbps

I'm using the below program to set the relay on-time via a virtual input and then toggle the relay via another virtual input. You will need the Blynk and Ticker libraries to compile the example.

  * Blynk is a platform with iOS and Android apps to control  
  * Arduino, Raspberry Pi and the likes over the Internet.  
  * You can easily build graphic interfaces for all your  
  * projects by simply dragging and dropping widgets.  
  *  Downloads, docs, tutorials:  
  *  Blynk community:  
  *  Social networks:  
  * Blynk library is licensed under MIT license  
  * This example code is in public domain.  
  * This example runs directly on ESP8266 chip.  
  * WARNING! ESP8266 SSL support is still experimental.  
  *     More info here:  
  * Note: This requires ESP8266 support package:  
  * Please be sure to select the right ESP8266 module  
  * in the Tools -> Board menu!  
  * Change WiFi ssid, pass, and Blynk auth token to run :)  
 #define BLYNK_PRINT Serial  // Comment this out to disable prints and save space  
 #define RELAY_PIN D1  
 #include <ESP8266WiFi.h>  
 #include <BlynkSimpleEsp8266_SSL.h>  
 #include <Ticker.h>  
 // You should get Auth Token in the Blynk App.  
 // Go to the Project Settings (nut icon).  
 char auth[] = "XXXXXXXX";  
 // Your WiFi credentials.  
 // Set password to "" for open networks.  
 char ssid[] = "XXXXXXXX";  
 char pass[] = "XXXXXXXX";  
 bool vPinState = false;        // Set the default virtual pin state  
 int maxRelayOnTime = 10;       // Set the max on time of the relay   
 int minRelayOnTime = 1;        // Set the minimum on time of the relay  
 int vDelayTime = minRelayOnTime;   // Set the initial delay time value  
 Ticker doorLatch;           // Callback fuction instance  
 void setPinLow()  
  digitalWrite(RELAY_PIN, 0);  
 void setup()  
  Blynk.begin(auth, ssid, pass);  
  pinMode(RELAY_PIN, OUTPUT);  
  digitalWrite(RELAY_PIN, 0);  
 void loop()  
  // Get the virtual input state  
  vPinState = param.asInt();  
  // If the virtual input went high  
   // Open the relay  
   digitalWrite(RELAY_PIN, 1);  
   // Turn off the relay after the defined delay time  
   doorLatch.attach(vDelayTime, setPinLow);  
  // Get the input from the virtual input slider  
  vDelayTime = param.asInt();  
  // Constrain the virtual slider input to within the preset bounds  
  vDelayTime = constrain(vDelayTime, minRelayOnTime, maxRelayOnTime);  

Android App:

My Blynk project (Android) looks like this:

New device setup screen
Physical Pin and Virtual Pin Mapping
Slider controlling the unlocked time using Virtual Pin 1
Unlock button linked to Virtual Pin 0

Example configuration of relay on physical pin D1

Example configuration of relay on Physical Pin D4. Note the inverse logic configuration of the LED as it is ON when pin D4 is pulled low.

Tip: if you are using the Wemos boards and use the generic ESP8266 board in the Blynk App the built-in led is pin 2 and the relay is pin 5 (D1 on the wemos web page)


My door strike is set up as per the wiring diagram below. I followed the instructions that came with my door strike.


And that's it! It's as easy as that. I've had my setup running for a few days now with no issues. My past experience with ESP8266 solutions doesn't give me the greatest confidence in device up-time so I'll monitor the solution and see how stable it is.

It's worth noting that I'm not entirely sure how secure Blynk is, so at the moment I'm being cautious and running a local copy of the Blynk server hosted on my local network. I'll need to do some investigating in to this one.