How-to configure Wi-fi in pfSense

Netgate offers the 802.11a/b/g/n wireless kit for APU but configuring pfSense to use it is not immediately apparent and I was not able to find a recent how-to or tutorial on how to do the setup. This tutorial is using pfSense 2.2 but should work with 2.1 as well.

This tutorial will help you configure a bridged LAN Wi-fi network. We won’t be dealing with creating a guest wifi network but if requested I’m willing to do that later.

It’s all about the bridge

The most tricky part of this is configuring the LAN bridge to the Wi-fi interface. I’m going to assume that you already have a LAN interface configured and your pfSense is working great. Now all you want to do is configure the wireless.

If you go to Interfaces->(assign) you probably see something like this.
Screen Shot 2015-02-20 at 21.17.13

Now in order to create the bridge without getting disconnected we need to do a bit of trickery.

Assign a new interface to something that is not in-use. For example a network port that you’re not using or even create a PPP interface temporarily just so you have something to assign it to. Once created it will probably be called OPT1 or OPT2. Go ahead and click on it, enable it, and rename it to LAN_PORT. It should then look something like this.
Screen Shot 2015-02-20 at 21.23.31

You should also have an interface assigned for you wifi card such as the wireless kit from Netgate. It might look like this.

Screen Shot 2015-02-20 at 21.26.44

And if you open the interface it should be enabled.

Screen Shot 2015-02-20 at 21.26.55

IPv4 and IPv6 configuration should be set to None for both the Wifi and LAN_PORT interface.

Now it’s time to actually configure the bridge. Under Interfaces->(assign) click on the Bridges tab. Click the + icon to add a new bridge.

Under Member interfaces select both the Wifi and LAN_PORT interfaces that you setup.
Click Save and apply these changes and you should see something like this.
Screen Shot 2015-02-20 at 21.33.18

Now go back to Interface assignments, and we want to adjust the assignments a little.

Assign the BRIDGE0 port to your LAN interface. And assign the port that was originally assigned to your LAN interface to the LAN_PORT interface. It should then look something like this.
Screen Shot 2015-02-20 at 21.34.46 Screen Shot 2015-02-20 at 21.34.54

In my case re2 was originally assigned to LAN and is now assigned to LAN_PORT.
Save these settings and apply, and you’re finished with the bridge!

More Wi-fi Settings

Now it’s time for the wireless settings. There are some gotchas that we’ll mention, but first here are screenshots of my configuration that is working great.

(To get to this configuration click on the Wifi interface from the Interfaces assignment tab.)

Screen Shot 2015-02-20 at 21.40.32 Screen Shot 2015-02-20 at 21.40.45 Screen Shot 2015-02-20 at 21.41.28

WPA Pairwise has to be set to Both, if you set it to AES the wifi will stop working. In my testing I found it was best to set WPA Mode to WPA2 and leave the Pairwise set to Both.

Otherwise you should be fine copying all the wireless settings from my screenshots, of course you’ll choose a different pre-shared key and SSID 🙂

Remember that your LAN IP address and other network settings must now be configured on the interface that you assigned to the bridge, and also DHCP should be enabled on that same interface.




How to install R1soft Backup Manage Agent on openSUSE

I’ve been having some fun getting the R1soft Backup Manager agent installed on some openSuse servers and so decided to write a blog post on some tips.

First of all you’ll need to download the agent package and install the RPM packages using the command:

rpm -i *.rpm

And you’ll want to get the backup manager’s key using:

serverbackup-setup --get-key [Manager_URL]


You’ll need to install the kernel source package. Use this command:

zypper install kernel-source

You may be getting the following error when trying to run the command “r1soft-setup –get-module”.

Cannot find the kernel-source package for your kernel

And if you enter the command “uname -r” and compare that with the version of the linux headers stored under /usr/src you’ll notice that the versions are different.
This can be resolved be running the following commands:

zypper refresh
zypper update kernel-default kernel-default-base kernel-firmware

That should bring the installed kernel up-to-date with the installed kernel source.

Now all you need to do is run the following command and reboot. You should be all set!

r1soft-setup --get-module


Share Sessions between Google Cloud Endpoints and webapp2

There are some cases where you want to be able to use the Google Cloud Endpoints feature on App Engine but you would also like to be able to access your session data that is managed by webapp2 backed by either memcache or the NDB datastore. Well you can! And here’s how.


You’ll need to import the following modules in your API script. Note that I’m assuming that you’re using NDB backed sessions just like me. If you’re using session_memcache instead of session_ndb this won’t work.

I’m also using werkzeug because it makes it easier to work with the cookie data.

from webapp2_extras import sessions_ndb
import webapp2_extras
import werkzeug
import hashlib
import hmac

Helper Methods

Here are 2 helper methods. One verifies the cookie signature to make sure it’s not been tampered with. You want to make sure that COOKIE_SECRET_KEY is set to the value of secret_key under webapp2_extras.sessions from your webapp2 config.

def compare_hashes(a, b):
    """Checks if two hash strings are identical.

    The intention is to make the running time be less dependant on the size of
    the string.

    :param a:
        String 1.
    :param b:
        String 2.
        True if both strings are equal, False otherwise.
    if len(a) != len(b):
        return False

    result = 0
    for x, y in zip(a, b):
        result |= ord(x) ^ ord(y)

    return result == 0

This is what does all the magic.

def get_current_session(request_state):
    cookies = werkzeug.http.parse_cookie(request_state.headers.get('Cookie'))
    sess_cookie = cookies.get('mc_session')
    parts = sess_cookie.split('|')
    if len(parts) != 3:
        logging.error('Cookie does not have 3 parts')
        return False

    signature =, digestmod=hashlib.sha1)
    sig_hex = signature.hexdigest()
    if compare_hashes(sig_hex, parts[2]):
        logging.error('Cookie signature mismatch!')
        return False

    cookie_data = webapp2_extras.json.b64decode(parts[0])
    return sessions_ndb.Session.get_by_sid(cookie_data['_sid'])

Now in your API method you would simply add the following line:

session = get_current_session(self.request_state)

Now session will contain all your session data. You can for example do session.get(‘mystuff’).

Happy coding!

NerdFaxing – Automatically Print Faxes from Email

fax-historyNerdFaxing has just been uploaded at and is a fax to email to print automation script.

It will download PDF email attachments from a POP SSL mail account and send them to whatever Windows printer you want. It’s written in Python and uses gsprint from GSView to do the printing.

It’s designed to run on Windows but it could be easily adapted to run on a Linux platform. My specific need was for it to run on Windows where all the network printers are setup.

Connect to FPM Socket Permission Denied after upgrade to PHP 5.5.12

If you’ve just upgraded your web server to PHP-FPM you probably noticed that your web sites went down and your Nginx logs or whatever server you are using are giving you an error message that include the following statement:

connect() to unix:/var/run/www.sock failed (13: Permission denied) while connecting to upstream

To provide some context for this problem see

What was happening before is that the sockets were being created with a mode (permissions) of 0666 which makes it possible in theory for any web site to connect to them. This could be a security issue for shared hosting as an example.
So the security fix was to have PHP-FPM create the sockets with a permission mode of 0660 instead.

Now the problem with most default web server configurations is that the sockets are created under the root user while nginx or apache are running as a web server such as www-data. This means the web server is not able to read the PHP socket.

The Solution

The solution is very simple which you can find at stackoverflow

You simply add the following 2 lines to your PHP-FPM web site configuration before or after you set the path to the socket itself.

listen.owner = www-data = www-data

This causes the the socket to be created with the owner and group of www-data which allows the web frontend to access the socket without any permission issues.

Happy administration!