So Cal Free Net.org

Recently we've been doing a lot of overdue work on our networks. This is the first in a series of articles detailing some of the changes, including some real world experience with exciting new products (like meraki).

This article is about pfSense and its wireless capabilities on a PCEngines Wrap board. In brief, its excellent! So far! Read on to get the full scoop.

For quite a while we've been using a deprecated version of m0n0wall, 1.2b7, which had support for Atheros cards. It has a number of failings (e.g. no sleep mode fix for Prism cards, overall 600k maximum throughput on 802.11b), but its easy to configure and rock solid, so we've lived with the nits and continued to deploy nodes using it.

m0n0wall Hits the Wall

However, it has become apparent that m0n0wall running as an 802.11a client does not work well with m0n0wall running as an 802.11a AP. We're not sure why, and the results are inconsistent. E.g. m0n0wall as an 802.11a client works great when using the old Proxim 802.11a boxes we've written about extensively on this site. And, m0n0wall as an 802.11a AP seems to work great with a couple of 802.11a laptop cards we've tried. Its just the two together that don't work. Typical problems are very poor range, ping times that bounce between 5msec and 1000 msec (but not in between), and not being able to associate at all.

We banged our head against this for a long time until we gave up and started the search for alternatives. One very promising candidate is Pyramid from the great folks at Metrix. Its only downside is that not everything is configurable in its web gui. Many of the people who maintain our networks are not *nix geeks, and although they're quite adept at networking, even relatively simple requirements like setting up static routes are not currently possibly from the GUI. However Pyramid is evolving fast, so we'll be watching it!

We finally decided to try pfSense. This is a close relative of m0n0wall, not really targetted at embedded systems, but they gamely maintain an embedded systems release targetted primarily at Wrap or Soekris systems with a minimum of 128MB of RAM and a 128MB CF.

Setting it Up

The notes below are for pfSense version 1.0 RC3. Expect problems to be fixed in later versions (and some new ones to arise... this is software folks!).

Update the Wrap BIOS. Somewhere in the pfSense notes, they suggest updating to the latest Wrap BIOS, 1.11, to get some important fixes for Atheros cards. In hindsight, this may have also fixed some of the m0n0wall woes, but we doubt it. This is a fairly simple exercise that requires access to the serial port and a trip back in time to words like XMODEM. Note you'll need 38400 baud to talk to Wrap, and press 'S' to get to a menu after its memory test.

Make sure you have 128MB. Early Wrap boards (up until about a year ago?) had 64MB of RAM. More recent ones come standard with 128MB. PfSense is much happier with 128MB, though posts on their forum suggest you can tweak it to work with 64MB. We tried briefly and then swapped boards until we found one with more RAM!

Hookup Serial for Config. Unlike m0n0wall, you'll need access to the serial port when you configure pfSense for the first time. It won't simply make the first ethernet port the LAN subnet and start DHCP. Instead you need to assign interfaces via the serial port before the LAN subnet comes up and you can start tweaking via the gui.

Tweak the Template. The default metallic template causes my old IE6 browser to pause for several seconds on each page before it becomes editable. When I switched the template to pfsense, everything happens much faster. YMMV.

Careful With Assigning Interfaces. When you change settings on the LAN or WAN interfaces with M0n0wall, they won't take affect until you reboot. PfSense tries to make the changes right away. Since we were configuring WAN as ethernet, LAN as ath0 in 802.11b mode and OPT1 as an 802.11a AP, it proved to be tricky to do this while still being able to get into the box afterwards. The WAN port (ethernet) wouldn't allow admin access because of default firewall rules, while the wireless ports didn't default to APs. Anyhow, some juggling (and cursing) later, it all came together nicely.

Back it up!. Just like m0n0wall, pfSense lets you easily save all the settings to an XML file. It also lets you save some of the settings, conveniently grouped, which is also great.

Firing it Up

After configuring and testing, it fired up in the field without any major problems. The first time around there was a glitch with the static routes not being recognised. However re-saving the static routes fixed that and it seems to survive subsequent reboots just fine.

Results So Far

Things we've noticed so far about the pfSense which is now installed at one of our needs and feeding another via an 802.11a backhaul.

• full speed at last! Both the 802.11a and the 802.11b APs can handle the full speed of the connected DSL (2.5MB). Poor m0n0wall's ancient Atheros drivers seemed to max out at 700k (on the AP side only, client side is full speed)
• the built-in graphs are cool! (Not sure what they do to the CF lifetime, but we'll worry about that later huh...)
• admin is fast. All the admin pages are very snappy.
• lots more knobs to tweak. Gotta love all those geeky pfSense settings, even though we're not sure what half of them do and are afraid to touch them!
• the captive portal is sssllllooooowwwww. Not sure what's going on there, but others have noticed too.

The best thing of all we've noticed - the m0n0wall node a block away now works flawlessly. (The other node twice as far away doesn't work at all, but we're hoping that's a configuration problem at that end).

We'll see how this goes over time. Wish us luck!