I've recently migrated my site from Anchor CMS to Atlassian Confluence. I also haven't cleaned up my website in ages, so now was a good opportunity.

I didn't want to loose all my articles from the past, but found no real good way to import them easily. So I manually copied each article over, and removed a few that didn't really have any useful content in them.

Hopefully google will update with the new URLs shortly. Now that I have a new platform and more time, I'll be looking to post here more often.

Originally written spring of 2014

Ever need statistics, notifications, or even just server log files emailed to you? This tutorial is for you.

Setting up simple script to have your server automatically email you information every so often is quite simple, just follow these steps. Please note, this tutorial will be for Debian Linux. For CentOS and other linux distributions it shouldn't be too different, but this article only covers debian.

Step 1:You'll need to install MSMTP, a command line SMTP mail client. This can be done by running:

sudo apt-get install msmtp

from command line. Once that installs, we can move on to the next step.

Step 2:Now we need to setup the config file for MSMTP. You'll have to create a config file for it in your home directory. To do this, you'll need to create and edit a file named.msmtprc, which can be done with your favorite text editor. I'll post my example config here:

account default
tls_starttls on
auth login
port 587
password your-password
tls on
tls_certcheck off

Your config file may differ depending on your mail provider, for more information please contact your mail provider.

Now, we need to change permissions of that config file. Make sure your in your home directory, and change the file permissions of .msmtprc to 600. On Debian this can be done by typing: 

chmod 600 .msmtprc

And now we need to test MSMTP, which can easily be done by typing

echo 'Test-Text' | msmtp -a default 

You should receive a message to "" that says "Test-Text". If you got that email, your ready to continue on. If you didn't please re-read above, or leave a comment and I will help you.

Step 3: Automate the process. Because automation is fun. We'll be creating some simple scripts and setting up some cron jobs, so heres where your linux knowledge will come in handy.

This part is up to you, you'll need to figure out what script you want to use. In this case, I'll be using a script that gives me system information.

After setting up the script and making it run, its time to setup the cron job. In my case, I'll be having my server email me usage stats every week, on a monday morning at 6am. My cronjob will look like this:

15 6 * * 1 /home/justin/ | msmtp -a default

Since cronjobs can be confusing, you can use this handy site to create cron jobs. You can customize this to your hearts content, or feel free to use what I have posted.

Originally written back in 2014, settings may have changed since then

Lighttpd is a great webserver software, and in this tutorial I'll be showing you how to setup SSL Encryption on Lighttpd with your own self-signed certificate. Please note, if your looking to setup SSL with a purchased certificate, please refer to this article, which better explains how to setup a site with SSL encryption with a trusted certificate. This tutorial is for a self-generated certificate, which means every time someone visits the site they'll get an error saying the site is not valid. But if your like me and your only doing development testing, then this makes more sense then buying a SSL Certificate for a site that is only for testing.

Step 1: Generate the keys and certificates. First, lets create a directory for them.

mkdir /etc/lighttpd/ssl/
cd /etc/lighttpd/ssl/

Now to generate both the key and certificate.

openssl req -x509 -newkey rsa:4096 -keyout ssl.key -out ssl.crt -days 365

This command will use OpenSSL to generate the key and certificate pair. Once you run this command, you'll see OpenSSL begin the generation process. It will ask you for a"PEM Pass phrase". Enter a password you can easily remember. Now you will be asked questions about your location, organization, etc... Leave these default as we don't need them for a self signed certificate. Congratulations! Your key and certificate are now generated.

Now we need to "unlock" the key. We can do this by running the command below:

openssl rsa -in ssl.key.bak -out ssl.key

You'll be asked for your password that you typed in earlier above. Enter it, and your key should now be unlocked.

Now you have to convert the .key file and .crt file into a .pem file for lighttpd. This can be done by typing:

cat ssl.key ssl.crt > ssl.pem

Make sure you move the keys to the directory we made earlier.This part is essential for getting lighttpd to work with ssl. You may already have them in the right spot, but just to be sure you can always go to "/etc/lighttpd/ssl" and type "ls" to be sure. Run the following commands to move the files if they're not there already:

mv ssl.key /etc/lighttpd/ssl/
mv ssl.crt /etc/lighttpd/ssl/

Step 2: Configuring Lighttpd Now we need to setup the Lighttpd config file to accept SSL connections. Edit the file /etc/lighttpd/lighttpd.conf. Use your favorite text editor.

Scroll to the bottom of the file, and add the following lines:

$SERVER["socket"] == ":443" {
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd/ssl/ssl.pem" = "/etc/lighttpd/ssl/ssl.crt" = ""
server.document-root = "/sites/vhosts/"
server.errorlog = "/var/log/lighttpd/example.error.log"
accesslog.filename = "/var/log/lighttpd/example.access.log"

Configure the above to fit your custom needs.

Step 3: Test and restart lighttpd

Now, test the config file for lighttpd by typing the command:

lighttpd -t -f /etc/lighttpd/lighttpd.conf

If you see the text"Syntax OK", then lighttpd is ready to go. If you did not see this message, please re-read the tutorial and make sure that everything was copied correctly. Now all you have to do is restart lighttpd, just type:

service lighttpd restart

Congratulations! You can now visit your newly encrypted site!

Originally written some time in 2014

So recently, a situation came up where I had to bring wifi to the middle of nowhere. By middle of nowhere I mean no power, no nothing. So I decided to bring along my Linksys WRT54G (Running DDWRT). I have a small battery pack that I built, and I figured I would power the router off that. At first I was just going to bring my inverter and plug the power brick of the router into that. But its pointless to me why you should conver the power from DC -> AC -> DC again. So after my friend on IRC mentioned I could power the router directly from the DC power source. I thought for sure I would need some kind of adapter, but it turns out the router can in fact be plugged directly into the DC power source. So heres the steps below, so you don't have to go though the same guessing game I did.

Step 1: Find an older power adapter that fits your router's power port. Make sure its old, and not the power adapter you need for the router. (Once this is done, you can't use the adapter anymore to plug into the wall).

Step 2: Cut the wire of the adapter.

Step 3: Strip the insulation off the wire. (My picture doesn't show the bare wire, since I put terminals on it so the wires would stay connected to my battery. This is NOT required, you can just touch the bare wire to the battery terminals if you don't have the connectors you need.)

Step 4: Located the positive and negative wire. The positive wire will have a solid white line (As seen in the photo). The negative will have nothing on it. (It could have writing.)

Step 5: Connect the wire to the battery.

Step 6: Plug in the router.

Step 7: ENJOY! Your device is now running off DC power, with no need for an inverter or AC Power source.

This dosen't apply to just my router, in fact anything that runs of a 12v power supply can be powered directly from a DC power source (Such as the battery). This can come in handy when you have to power something in a car or from a battery, and don't want to use an inverter.

Thanks to HeavyMetal in IRC Chat for the idea!

Arduino Halloween Pumpkins

Written some time in 2015

Halloween is always fun. But of course I have to put my touch of "tech" into it. This page will be covering how I made a bunch of these plastic "trick-or-treat" pumpkins into a light show.

First things first, we need to wire up the lights. I chose 12v LED strip lights because I have plenty laying around on hand. I carefully soldered them together, putting 2 strips back to back on a cardboard base. I then placed these LED Units in each of the plastic pumpkins and covered the top with electrical tape for waterproofing (Since it will be outside).

LED Lighting Units inside pumpkin: 

Now there is just one problem, the Arduino doesn't have enough power to light up the 12V LEDs. So I will have to use an external 12V power source. To accomplish this, I used some TIP122 transistors. This youtuber, "thecustomgeek", explains it much better than I can in his video. 

Now comes the code. To make the LEDs light up in patterns, I used an Arduino library called "ALA" (Short for "Arduino Light Animation"). The source code can be found on github. I used the author's example from his blog page that gives an excellent explanation on how to setup the LEDs.

The finished product:

Originally written some time in 2015

There are many situations where you may not be able to open ports from whatever internet connection your on. Whether your trying to access a remote IP Cam over a 3G connection that has a Carrier Grade NAT, or you just want to run your own server, but your ISP blocks ports, this tutorial is for you.

First, you'll need a "VPS". I recommend picking one up off Next, get an openvpn server up and running (I choose to use the openvpn-install script made by "Nyr" on github. Its a great script that gets you a working openvpn server in minutes.) link to install script:

To port forward to clients on the OpenVPN server, the process is fairly simple and can all be accomplished with IPTables commands. For example, I want to open port 80 on a webserver running behind a mobile 3G connection. To open Port 80, this is what I would type:

iptables -t nat -A PREROUTING -d -p tcp --dport 80 -j DNAT --to-dest 

Confused? No problem. The rule goes like this, where you see , put the WAN IP of your VPN server. After --dport 80 change that to the port you want to forward to the VPN client. Last, after --to-dest paste the OpenVPN CLIENT IP.

So to wrap things up, the above rule would open port 80, forward it to the openvpn client running at, and be accessible from the VPN's WAN IP of So typing would actually be loading the page from the OpenVPN client running at

Originally written some time in 2015

A friend of mine showed me a tiny CRT monitor. So I was curious if my old camcorder from the 90s would have it as well. Turns out the viewfinder was actually looking what seems to be a tiny LCD. Photos below.

Click each image to make it larger.

Originally written some time in 2015

The insides of an an Actiontec MI424WR Rev. E.

I was really hoping that OpenWRT would support this router, as the hardware is quite nice hardware wise, but it seems they have not created a build for it yet. So instead, in the meantime, I'll use it as a MoCA Coax to ethernet bridge for my media center.

Click on the images to enlarge.

Originally written late 2015

Recently, a drive failed in my software RAID 5 Array. These are the steps I found to take.

1st, remove the dying drive from the RAID.

mdadm --manage /dev/md0 --fail /dev/sde1
mdadm --manage /dev/md0 --remove /dev/sde1

Once the drives are removed from the RAID array, power down the server and replace the drive. Be certain that you are replacing the correct one. I used my drive's serial number to identify which one to remove.

Boot the server again, and login to a terminal. Now, the new drive should appear in the same /dev/sd* format as the previous drive. Now we copy the partition table from the other drives to the new drive.

/sbin/sfdisk -d /dev/sda | /sbin/sfdisk /dev/sdb

Once that has completed, verify that the drives have appeared in the /dev directory.

ls /dev/sdx*

Now just add the drive back to the RAID with the following mdadm command.

mdadm --manage /dev/md0 --add /dev/sdb1

X2X, The Underrated Program

Originally written late 2015

Recently, I've found myself in need of a "Keyboard and mouse" sharing application for my linux work stations. I've acquired 2 more work stations, and naturally I couldn’t fit anymore keyboards on my desk... So I needed to find a way to share my keyboard and mouse from one computer to another. A good friend of mine uses a program called a cross-platform program called Synergy to manage his linux computer from his main windows workstation. This program is great, but it is a paid program. I couldn’t quite justify the cost, and I knew the open source community had to have something out there.

I searched for quite a while before stumbling on the "Jewel" of linux mouse & keyboard sharing software. (At least in my opinion.) This program is called X2X. I honestly love this program. It allows seamless mouse and keyboard sharing from one linux desktop to another, all over an encrypted SSH connection.

The downfall? The project has been updated in forever, and some of the files in the github repository date back to almost a decade ago. I'm saddened by the fact that this program has no real home page, and isn't as popular as it should be. With a little TLC, this program could be so much more. I wish I had the coding skills required to contribute to the project, but its beyond my league. Anyway, heres a small guide for myself (And possibly the few readers who see my blog) on how to get this working.

Automating X2X

X2X Can be setup in a way that connecting is seamless. Personally, I have a setup where on my main control PC, I have a desktop shortcut that executes the SSH command. Please note, this method may not be the best way of setting up X2X, but with the lack of support I could find no other way. To begin, I installed x2x on both computers. This is as simple as running:

sudo apt-get install x2x

Next, I setup SSH keys for my SSH session, so I would not be prompted for a password when launching my X2X connection from a desktop shortcut. If you don't know how to setup SSH keys, theres plenty of tutorials online, such as this excellent one from Digital Ocean.

Last, I setup a desktop shortcut to run the following SSH command. Note: This step is not required, and running this command straight out of terminal will work as well.

ssh -XC user@ x2x -east -to 0:0

The above command can be customized. Where -east is, you can set this to where your other workstation will be (North, east, south, west). Leaving the other arguments of the command as default should work fine.

This was just a brief overview of the X2X command, a severely underrated program in the linux world, at least in my opinion. Let me know if you run into issues in the comments.

Raspberry Pi Powered Garden

Originally written spring 2016

Just a little project I've been working on that consists of a Raspberry pi, relays, a temperature sensor, and a webcam. The raspberry pi controls the relay on a set schedule, as well as logging and graphing the temperature sensor. The pi also takes a picture from the webcam every day to make a timelapse video in the end of plants growing. Details on construction to come.

Originally written some time in 2016

While setting up a site for a client, I ran into some trouble with OpenCart and HTTPs. Apparently, for whatever reason, the developers decided to only use HTTPS for the checkout portion of the site. For an e-commerce site, this was completely unacceptable for my client, as we wanted EVERYTHING on that site to use HTTPs. So finally after some time spent with Google, I discovered a wonderful forum post. Here is the link.

The poster said to do the following, and sure enough, it worked!

Look in upload/system/config/catalog.php and upload/system/config/admin.php. Set $_['site_ssl'] = false; to $_['site_ssl'] = true;

Now all pages successfully load over HTTPs.

Originally written some time in 2016

For my job I have to run a Jira application server. This server needs to be run behind a Apache reverse proxy. The apache server needs to be the one serving the HTTPS. For this, after hours of testing, I realized that you need to use Apache's "AJP Proxy". To install, firstly run:

a2enmod proxy_ajp

This turns the module on in Apache. Next we need a virtualhost config. This config is done the same way that we normally do apache reverse proxies, only instead of http:// we put ajp://. 

Example config:

<IfModule mod_ssl.c>
<VirtualHost *:443>


    ProxyPreserveHost On

    ProxyPass / ajp://
    ProxyPassReverse / ajp://

    ErrorLog ${APACHE_LOG_DIR}/
    CustomLog ${APACHE_LOG_DIR}/ combined

SSLCertificateFile /etc/letsencrypt/live/
SSLCertificateKeyFile /etc/letsencrypt/live/
Include /etc/letsencrypt/options-ssl-apache.conf


Next we need to change the config files of the jira server itself. Follow this part exactly. 
1. Stop the Jira server. sudo service jira stop
2. Nano the server file located at /opt/atlassian/jira/conf/server.xml
3. Replace it with the following config:

<?xml version="1.0" encoding="utf-8"?>

   Atlassian JIRA Standalone Edition Tomcat Configuration.

   See the following for more information

  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the "License"); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  See the License for the specific language governing permissions and
  limitations under the License.
<Server port="8005" shutdown="SHUTDOWN">
    <Listener className="org.apache.catalina.startup.VersionLoggerListener" />
    <!-- Security listener. Documentation at /docs/config/listeners.html
    <Listener className="" />
    <!--APR library loader. Documentation at /docs/apr.html -->
    <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
    <!-- Prevent memory leaks due to use of particular java/javax APIs-->
    <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
    <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
    <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />

    <!-- Global JNDI resources
         Documentation at /docs/jndi-resources-howto.html

    <!-- A "Service" is a collection of one or more "Connectors" that share
        a single "Container" Note:  A "Service" is not itself a "Container",
        so you may not define subcomponents such as "Valves" at this level.
        Documentation at /docs/config/service.html
    <Service name="Catalina">

	<!-- Standard HTTP Connector -->
        <Connector acceptCount="100" connectionTimeout="20000" disableUploadTimeout="true" enableLookups="false" maxHttpHeaderSize="8192" maxThreads="150" minSpareThreads="25" port="8081" protocol="HTTP/1.1" redirectPort="8443" useBodyEncodingForURI="true"/>

      <!--  <Connector port="8080"


                   disableUploadTimeout="true"/> -->


        For full steps on running JIRA over SSL or HTTPS for production and testing, see:

        A quicker method can be found below, which we recommend only for evaluation and demonstration:

            * Uncomment the Connector below
            * Execute:
                %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA (Windows)

                JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA (Unix)

                with a password value of "changeit" for both the certificate and the keystore itself.
            * If you are on JDK1.3 or earlier, download and install JSSE 1.0.2 or later, and put the JAR files into "$JAVA_HOME/jre/lib/ext"
            * Restart and visit https://localhost:8443/

            <Connector port="8443" protocol="org.apache.coyote.http11.Http11Protocol"
              maxHttpHeaderSize="8192" SSLEnabled="true"
              maxThreads="150" minSpareThreads="25"
              enableLookups="false" disableUploadTimeout="true"
              acceptCount="100" scheme="https" secure="true"
              clientAuth="false" sslProtocol="TLS" useBodyEncodingForURI="true"/>


         If you have Apache AJP Connector (mod_ajp) as a proxy in front of JIRA you should uncomment the following connector configuration line

         See the following for more information :



              <Connector port="8009" redirectPort="8443" enableLookups="false" protocol="AJP/1.3" URIEncoding="UTF-8"/>

        <Engine name="Catalina" defaultHost="localhost">
            <Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true">

                <Context path="" docBase="${catalina.home}/atlassian-jira" reloadable="false" useHttpOnly="true">


                     Note, you no longer configure your database driver or connection parameters here.
                     These are configured through the UI during application setup.


                    <Resource name="UserTransaction" auth="Container" type="javax.transaction.UserTransaction"
                              factory="org.objectweb.jotm.UserTransactionFactory" jotm.timeout="60"/>
                    <Manager pathname=""/>



                 Access Logging.

                 This should produce access_log.<date> files in the 'logs' directory.

                 The output access log lies has the following fields :

                 IP Request_Id User Timestamp  "HTTP_Method URL Protocol_Version" HTTP_Status_Code ResponseSize_in_Bytes RequestTime_In_Millis Referer User_Agent ASESSIONID

                 eg :

        1243466536012x12x1 admin [28/May/2009:09:22:17 +1000] "GET /jira/secure/admin/jira/IndexProgress.jspa?taskId=1 HTTP/1.1" 200 24267 1070 "" "Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/2009042523 Ubuntu/9.04 (jaunty) Firefox/3.0.10" "C2C99B632EE0F41E90F8EF7A201F6A78"


                 The RequestId is a millis_since_epoch plus request number plus number of concurrent users

                 The Request time is in milliseconds

                 The ASESSIONID is an hash of the JSESSIONID and hence is safe to publish within logs.  A session cannot be reconstructed from it.

                 See for more information on Tomcat Access Log Valves


            <Valve className="org.apache.catalina.valves.AccessLogValve"
                   pattern="%a %{}r %{jira.request.username}r %t "%m %U%q %H" %s %b %D "%{Referer}i" "%{User-Agent}i" "%{}r""/>


4. Chown JIRA to the proper directories sudo chown -R jira /opt/atlassian/jira/
5. Start Jira sudo service jira start This takes up to 7 minutes, so don't think you broke the install
6. Enable the apache VHOST, ensure you can access it from the web browser.

MoCA in my opinion is an awesome technology. However, the current MoCA adapters on the market are extremely overpriced, turning many away from MoCA. However, using a cheap old Verizon Actiontec router (can be found on ebay for around $15-20 used), we can create our own MoCA bridge for 1/10th the cost.

After seeing the need for a documented tutorial, I have written the following, which describes how to configure an old Verizon actiontec router as a dumb MoCA bridge, to extend your home network anywhere that coax exists.

Please, feel free to leave comments or shoot me an email if you need help!

Comprehensive guide to converting an old Actiontec router into a MoCA bridge

1. Purchase any old actiontec router off ebay. You can find them for cheap now that Verizon has started rolling out its new G1100 router. The revision or model does not matter, as long as its in the MI424WR family.

*Note: This tutorial assumes the device is not plugged into to the coax MoCA network at the time of setup.

2. Boot the router. You will need to plug your computer into one of the yellow LAN ports on the back of the router. Wait for your computer to connect, then open a web browser, and navigate to

* Note: This guide assumes that the router is in the stock factory state as shipped from Verizon. If you purchased your router 2nd-hand, you may want to do a quick factory reset to ensure a clean configuration. This is done by holding the reset button in on the back for about 30 seconds, until the Power LED turns red and flashes.

3. Login to the router. The username and password for some models is on a sticker, on the bottom of the device. If there is no sticker, the username and password are most likely admin / password.

4. Next, you will be brought to the router's main web interface. First, click on "My Network". Then go to "Network Connections".

5. After clicking "Network Connections" you should see the following page. There are two options here that we will need to click on. Repeat this process for both the "Broadband Connection (Coax)" and "Broadband Connection (Ethernet)" interfaces.

Click the interface. You should be brought to another page. Click the blue Disable button.

Click apply.

The router will reboot. Wait for the Power LED to turn green again, and the webpage should reload itself. Login to the router once more. Follow the instructions above to disable the other "Broadband Connection" interface.

After, you should see that both "Broadband Connection" interfaces are set to Disabled on the Network Connections page.

Next, click Network (Home/Office).

You will see a page titled Network (Home/Office) Properties. Click the blue Settings button at the bottom of the page:

The next page will show many options. It may seem overwhelming, but we only need to change a few settings. First thing we will need to change is the router's IP address. This is so you can still access the device once its put into bridge mode. Look for the section with the dropdown menu "Use the following IP address". Change this to something such as or anything other than your current router's IP (Usually Not performing this step will cause issues in your network, as it will conflict with your main router!

Now, scroll down a bit more to the section that says IP Address Distribution. There should be a dropdown menu with the option DHCP Server selected. We need to change this option from DHCP Server to Disabled. Once you choose Disabled, the page should look like this.

The router will ask you to wait while it applies the changes. From now on, you need to access the router by the new address you gave it (in the above example, we would now type into our browser to access the router).

At this point, your router is ready to be a MoCA bridge. Plug it into the Coax coming from your wall, then plug a client device into one of the yellow LAN ports of the router (DO NOT Use the white WAN port for plugging in devices!)

The connections should look like this:

If all is well, you will see an LED light up that says "LAN Coax".

Test by connecting a device to the LAN port of the newly configured MoCA bridge and ensure it has internet access.


Disable WiFi - Strongly recommended if router is being used as just a MoCA bridge and not a wireless repeater.

1. Login to the router again. (Remember, it has a new address now!)

Navigate to Wireless Settings > Basic Security Settings > Turn Wireless ON

Click the Off option nex to the "Turn Wireless ON" option.

Scroll down and click the blue Apply button. A page will ask you to confirm. Click Apply again. WiFi is now disabled.

You now have a fully functional MoCA bridge, for 1/10th the price.

Please feel free to copy this documentation and share it everywhere.

If you need assistance, please email me anytime,

Originally written May 5th, 2017

I strongly suggest using GL-Inet Routers for all your OpenWRT needs!

If you have any trouble or questions, please email me at, or message me on, username "Justin", I should be available to help!

Start with a clean OpenWRT with only default packages installed. Make sure your router has a connection to the internet, as we'll need to install some packages.

Remove the default wpad-mini package.

opkg remove wpad-mini

Install the required packages. This may seem like alot, but most is for OLSR. wpad and authsae is for WPA2 over Ad-Hoc

opkg update

opkg install luci-app-olsr luci-app-olsr-services luci-app-olsr-viz olsrd olsrd-mod-arprefresh olsrd-mod-bmf olsrd-mod-dot-draw olsrd-mod-dyn-gw olsrd-mod-dyn-gw-plain olsrd-mod-httpinfo olsrd-mod-mdns olsrd-mod-nameservice olsrd-mod-p2pd olsrd-mod-pgraph olsrd-mod-secure olsrd-mod-txtinfo olsrd-mod-watchdog olsrd-mod-quagga wireless-tools luci-lib-json kmod-ipip wpad authsae

Configure Wifi.

Login to your router's web GUI. In the top navigation bar, select "Network", then click the "WiFi" option.

You'll see on clean installs that the wifi will show "Disabled". Click the "Enable" button. This enables the WiFi.

Now, go back to SSH, and open the file /etc/config/wireless.

You will see a section titled "config wifi-iface". Delete that entire configuration and replace it with the following:

config wifi-iface
        option device 'radio0'
        option encryption 'psk2/aes'
        option key 'goodlife'
        option ssid 'Sensor-Backhaul'
        option mode 'adhoc'
        option network 'mesh'

Change Option SSID to your desired Ad-Hoc SSID. Note, this MUST be identical on all devices attempting to join the network.

Change option key to your password. Again, this value MUST be the same on all the devices or they will not mesh.

Now in terminal run the "wifi" command. Refresh the Web GUI page to make sure it looks like this:

Now we need to configure OLSR.

First we need to create an OLSR interface. Go back to Network > Wifi. Click the "Edit" button next to the SSID information.

Under "Device Configuration", click the "Advanced" tab. 
Scroll down to "Interface Configuration". 
Look for the "Network" options. Put a checkbox in the option next to "create", and enter a new interface name. For simplicity sake, I reccomed leaving it named "mesh".

Click Save & Apply.

Now we need to setup a static IP for the device. Go to the "Network" tab, and click "Interfaces". You'll now see a "MESH" Interface. Click the edit button next to it.

On the next page, change the "Protocol" dropdown menu from "Unmanaged" to "Static Address".

Now click the "Switch Protocol" button.

You'll be brough to a new page. Enter an IPv4 address. Note: this IP should be in the range that your other nodes will be on. For simplicity sake, I will be using So in this field, I will put

If using a /24 (standard), set the IPv4 netmask to

Leave the IPv4 Gateway blank. 
Leave all other options blank.
Click save and apply.

Now we need to configure OLSR to listen for other nodes on this interface.

Go to Services > OLSR IPv4.

The first thing we need to do is enable the "jsoninfo" plugin so we can manage OLSR via the web interface. Go to the "Plugins" tab, and click the checkmark next to ""

Click save and apply.

Return to Services > OLSR IPv4 from the navbar. Scroll to the bottom of the page.

You will see an "Interfaces" section. There will be one entry. Click the "Edit" button on this entry.

You will be brought to a page. Locate the "Network" option. Click the "mesh" interface for the network option.

Leave all other options as is, and click save and apply.

Now we need to allow OLSR through the firewall. Go to The Network option > Firewall.

Under general settings, change Forward from "Reject" to "Accept".

We should be done at this point. Go to the "Status" > "OLSR" Tab to view more info.

If all is done right, we should see a number next to "Neighbors".

NOTE: For routers with internet access, we need to change one other option to allow that router to broadcast to the network that it has internet access. Go back to "Services" > "OLSR IPv4".

Click the HNA Announcements tab.

You will be brought to a new page. Click the "Add" button.

In both boxes, put the value "". Only do this on the router with internet access or the other routers will cease to route. 

Click save and apply. Test on a different router that it can access the internet.


I have only successfully configured this setup on Atheros/Qualcomm chips. I have been unsuccessful with any form of MediaTek chips regarding WPA2 and Ad-Hoc.

I reccomend using Gl-Inet routers for best performance with OpenWRT

Some of us have found that using a router that is currently connected as a client to another access point causes this configuration to fail. It is advised to not have the router connected as a WiFi client to another access point with this configuration.