Standard AP - updated

Recently we returned to an installation of our first standard AP to update the equipment slightly so we could reuse the parts elsewhere. This saved some money, assuming labor is free :-), and also mitigates any (unreported) problems we may have had with the m0n0wall AP powersave mode bug. I hasten to add our m0n0wall client has had no problems running trouble free for 244 days before I rebooted to upgrade the firmware!

Since we first defined and described our standard AP, we've moved from 802.11b-based m0n0wall backhauls running on Soekris 4501 boards to 802.11a backhauls running Pebble on Soekris 4526 boards purchased as kits from Metrix.

Senao AP3 replaces Soekris

The Engenius AP3 (recently replaced with the CB3+ Deluxe) is commonly hacked to turn it into a bridge or to add PoE support, but our needs were simpler. We had already built a PoE splitter/injector that used 12V just like the AP3, so all we needed was an external antenna connector.

The images show the simple steps needed. First open the AP3 using the four screws on the bottom. Remove the top of the case - it should come apart easily. Then remove the existing pigtail connector and add your new one. Make sure the removed connector doesn't touch any of the circuitry. You can drill a hole for a new connector, or dangle it free as we did here. We left the lid off the case to help cooling, and since it was going inside a weather resistant enclosure anyway.

Updating the AP was simple. First we configured the AP via its web-based interface. Then we got on the roof, unscrewed the Soekris board, removed the existing pigtail and then added the AP3 and its new pigtail. Then we plugged it in and ... held our breath when the LAN light didn't go on. Ugh, at first we thought we needed to add a crossover to the Cat-5 cable, but then the LAN light came on and it all started up just fine.

After that it was mostly plain sailing. While there, we updated m0n0wall to the latest firmware version. There was some odd interaction between its auto-firmware update function and the MikroTik captive portal gateway, but after we disconnected the backhaul that went away and we could upgrade first to m0n0wall 1.0 and then 1.11 succesfully.

Now we're ready to install the Soekris board, with m0n0wall, as the captive portal gateway for the 2nd DSL feed in the Golden Hill neighborhood network.

Soekris based Access Point + Relay proposal

Here's some preliminary thoughts following up on this week's SDWUG meeting discussion. I propose that we spec and build a standard relay configuration consisting of:

1. soekris 4501 board (the 64MB miniPCI Card non-POE version)
2. EnGenius (Senao) miniPCI radio
3. outdoor case with N-Female, hole for cat-5 cable
4. m0n0wall software (most likely)
5. standard yagi or omni antenna

My thinking about the various parts of this is:

1. Runs a bunch of stuff, low power, flexible.
2. 160mW, good receiver, cheap, external antenna connector.
   -ve: HostAP software on FreeBSD can't turn down the power which would be handy sometimes!
3. Plastic box that's showerproof. Should run < $50. I hate the extra connector loss but figure its worth it for the convenience of a standard connector and less worries about straining pigtails, sealing holes etc.
4. m0n0wall is rock solid, fast, but most important, ALL the config is stored in one single text (XML) file. Need to convince myself it will do straight bridging for the relay but am 99% sure it will. Configured as an AP, m0n0wall will give us DHCP, DNS caching etc., if we want, and hopefully captive portal in the next couple of months too.
5. yagi is easier than a panel to mount. Less obtrusive than a parabolic.

I further propose that we price all installations at flat fee of $1000. In an easy install we should aim to have $100 left over to put towards site survey equipment etc. Rough cost list including shipping & taxes is: $200 (Soekris) + $80 (Senao) + $100 (case with connector and pigtail) + $50 (POE + cat 5 cable, crimp connectors) + $70 (antenna) = $500. We could probably do a little better in quantity (e.g. Soekris drops to $156 for 5+). A fixed price simplifies quoting for landlords / whoever, and also allows us to pre-purchase in quantity without getting into all the bits of paper that reimbursement requires.

(Hmm, $1000 doesn't include mounting hardware or a tripod if need be... might be barely enough...)

A cheaper option is to put two radios on one Soekris as BAWUG/SFLan do with their kit, http://www.archive.org/iathreads/uploaded-files/AstridB-PICT0017.JPG, but I worry about interference reducing throughput as described here
http://lists.nocat.net/pipermail/nocatnet/2003-July/002138.html ,
http://lists.nocat.net/pipermail/nocatnet/2003-July/002163.html and
http://lists.nocat.net/pipermail/nocatnet/2003-September/002347.html.

Anyhow, this is long enough for one post. I look forward to some feedback!

(Edited Feb 4 to reflect change from Soekris 4511 to 4501).

Soekris based Relay - Parts and Price List

Here's a proposed parts list for a Soekris Relay. Comments welcomed! Did I miss anything?

Open questions: 1) Do we need a lightening arrestor on the Yagi / Patch relay antenna?

Notes:

• This list is subject to review and revision but is considered accurate +/- $100. Some prices are approximate as indicated.
• Both a yagi and patch are included in the above list. Only one is needed. Choice is left to the building owner based on aesthetic concerns.
• Prices exclude shipping and taxes.

• Doubtless some odds and ends will be needed (e.g. mounting screws for the boards).
• I've spec'd 64MB CF. We're not sure which way we'll go for the final O/S and they're only slight more expensive than, say, an 8MB CF (which is all m0n0wall needs).

Please add any comments using the link below.

Updated Feb 4 to reflect switch to 4501 (from 4511) and miniPCI radio from PC Card radio).

Building an outdoor Access Point

Controlling cost is one of the challenges of creating a standard access point. We took photos of the steps we went through to fit the Soekris 4501 into a standard 8"x8" outdoor electrical box. Here are some of them:

See all 20 images

This is part of our Standard Access Point project.

Access Point: Configuring m0n0wall

In our standard Access Point, m0n0wall will run on each of two radios. The basic configuration we're trying to achieve is:

• separate subnet
• local dhcp

Through trial and error it seems the best way to assign these roles in m0n0wall is as follows.

Prepare the Soekris

Not absolutely necessary, but we prepared the soekris boards by connecting a serial adapter, booting it, interrupting the boot sequence within 5 secs with Ctrl-P and then entered the following commands:

set conspeed 9600
set pxeboot disabled
set bootdelay 2

The console speed is set to match the default m0n0wall console speed. Disabling PXE boot seems like a good idea. And the minimum 2 seconds boot delay shaves 3 seconds off the boot time.

Radio 1 - Relay

One radio provides the relay back to 'home base'. This radio also provides DHCP services and routing. We use the WAN port to communicate to the "Home AP" and LAN is hardwired to the local AP radio. Here are the configuration steps:

1. Start with a default configuration of m0n0wall. This has an IP of 192.168.1.1 and has DHCP enabled. Hook up a standalone computer set to DHcP to the first LAN port (for Soekris anyway). Connect to m0n0wall via a browser as usual.
2. Click on Interfaces (assign). For WAN, choose wi0, Save.
3. Click on Interfaces -> WAN. Change Type to static. In Static IP Configuration set the IP to an unused IP in the Home AP's range (e.g. 10.0.0.251). Set the mask to match the destination network (e.g. 24), not 31. Likewise set the Gateway (e.g. 10.0.0.1).
4. Under Wireless Configuration, set Mode to BSS, SSID to the Home AP's SSID (e.g. socalfreenet.org).
5. Uncheck "Block private networks" at the bottom of that page. Click Save.
6. In Interfaces -> LAN, change the IP to reflect the local subnet desired. E.g. 10.0.5.1. Common practice is to end it in 1. Make sure the mask is set appropriately (e.g. 24) as it may change automagically. Click Save.
7. In Services -> DHCP, update the allocated range to match your LAN IP (e.g. 10.0.5.100 - 10.0.5.199). Click Save.
8. Go to Diagnostics -> Reboot System. Answer Yes and wait. With luck your computer will get a new IP in the LAN range.
9. Log back in via the new LAN IP address you set above (e.g. 10.0.5.1).
10. Go to System->General Setup. Enter the DNS server addresses. Set the timezone. Click Save.
11. In Firewall -> NAT, click on Outbound and then "Enable advanced outbound NAT".
    Click Save. (This will effectively disable NAT so the addresses are passed through). Click Apply Changes if prompted.

At this stage your LAN computer should be able to ping the gateway computer beyond the WAN port (e.g. 10.0.0.1). It may even be able ping external links (e.g. www.yahoo.com). A couple of issues may stop this from happening. My gateway to the internet box (at 10.0.0.1) is also running m0n0wall and I had to make two changes to its config before Radio 1 traffic could get to the internet:

• I needed to add a static route so traffic could be sent back to the 10.0.5.0 subnet. Using the values above, I did this in: System->Static Route click '+' to add new route, then enter OPT1 (wireless) for Interface, 10.0.5.0/24 for destination network and 10.0.0.251 for gateway (i.e. the WAN address of the wireless radio).
• I had to expand the subnet from 10.0.0.0/24 to 10.0.0.0/21 (i.e. 255.255.248.0). I'm not sure exactly why this was necessary. At first it was because of a default rule blocking non-LAN IPs internally (i.e. block !10.0.0/24), but that later went away (perhaps because of the static rule above. Perhaps it was because without a wider net, no NAT was performed for the 10.0.5.0 subnet. Anyhow, expanding the subnet mask made everything work.

Radio 2 - Access Point

The AP radio is configured as a bridge. I.e. virtually none of the m0n0wall features are used.

• step by step configuration to follow.

802.11a Relay Overview (Description, Cost, Links to Suppliers)

The key to our 802.11a backhaul project was finding the Proxim 802.11a Harmony 8571 which is a rare 802.11a device because it has removable antennas. These are available at www.justdeals.com for $15, but with $12 shipping for the first and $4 for subsequent devices, they average out around $23 each for two with shipping. Still pretty reasonable for a device that was originally $600!

We took one apart and discovered it has an 'unwrapped' PCMCIA card in it with standard SMA connector pigtails. Its also potentially re-programmable as a bridge which would make this whole relay unbelievably cheap, but we lack the expertise to get that far! The non-standard PoE support was a nice bonus - as is the ability to run with the standard power supply 100 feet away.

The next piece of the puzzle was antennas. Most point to point 802.11a antennas are in the 5.8GHz range where point to point is allowed by the FCC. The proxim is at 5.3GHz as its designed for multipoint. Fortunately SuperPass has a suitable patch antenna that someworks across the entire 802.11a 5GHz range of 5.1-5.9GHz. At 18.5dbi with 12 degree H and 32 degree V beam its a great solution (so far).

We decided to use the Proxim AP unmodified at one end of the link and a Soekris board with a Proxim PCMCIA card removed from another AP at the other. The Soekris adds a lot to the expense, but does provide a lot of configuration flexibility. The MadWiFi Atheros chip drivers work fine with this chipset (at least for our needs).

There's a couple of ways to slice this as some new products are almost available. First, here are the parts that stay the same regardless:

Here's the rest of the parts that reflect how we built the prototype version:

Here's a 2nd variation that replaces the Proxim radio and AP with a miniPCI a/b/g card and uses the latest Soekris boards (available at the end of March):

And then there's the combination option that uses one cheap Proxim AP unmodified, and a Soekris board plus miniPCI radio card (thereby avoiding hacking a Proxim AP):

The cheapest possible version would cost $78 and requite no hardware hacking at all (just outdoor cases) - but it involves changing the firmware in the Proxim. Its possible in theory, but perhaps not in practice unfortunately:

Notes about pricing:

• Prices do not include shipping (except the Proxim APs) or sales tax.
• There'll be other odds and ends depending on your situation, especially mounting hardware such as u-bolts and masts.
• Lightning protection is not included above.
• Some pricing included user group discounts of 5-10%.
• We actually purchased the SMA-N-Female adapters from www.ecommwireless.com but discovered www.radiooutfitter.com has them for $2 less while writing this page.

Assembling the 802.11a Relay / Backhaul

These pages describe how we assembled the first 'prototype' version of the relay. Now that we know its working, we'll refine everything - e.g. by replacing the plastic food containers :-).

The relay has two ends. The radios are configured so that one end is an Access Point and the other is a client. We chose to do it this way because the Proxim only supports Access Point mode, unlike some APs that also have bridge mode capability. The Access Point end is pretty simple: basically a Proxim modified for PoE in an outdoor case with a high gain antenna.

The other end of the relay is more complicated. We chose a Soekris board and installed a second Proxim radio taken from a Proxim AP. We installed Pebble on the board which is probably overkill. We'll try Leaf Wisp for our next install.

tar -xvzf avcNetSNMPv3-0.0.2.tar.gz
remountrw
cp init.d/snmpd /etc/init.d
chmod +x /etc/init.d/snmpd
mkdir /ro/etc/snmp 
cp ro/etc/snmp/snmpd.conf /ro/etc/snmp
mkdir /ro/var/net-snmp
cp ro/var/net-snmp/snmpd.conf /ro/var/net-snmp/
cp sbin/snmpd /sbin
chmod +x /sbin/snmpd 
mkdir /etc/snmp                                   
ln -s /rw/etc/snmp/snmpd.conf /etc/snmp/snmpd.conf
mkdir /var/net-snmp/
ln -s /rw/var/net-snmp/snmpd.conf /var/net-snmp/snmpd.conf

/etc/init.d/snmpd start
cat /var/log/snmpd.log

cd /etc/rc0.d
ln -s ../init.d/snmpd K20snmpd
cd /etc/rc1.d
ln -s ../init.d/snmpd K20snmpd
cd /etc/rc2.d
ln -s ../init.d/snmpd S20snmpd
cd /etc/rc3.d
ln -s ../init.d/snmpd S20snmpd
cd /etc/rc4.d
ln -s ../init.d/snmpd S20snmpd
cd /etc/rc5.d
ln -s ../init.d/snmpd S20snmpd
cd /etc/rc6.d
ln -s ../init.d/snmpd K20snmpd

set conspeed 9600
set pxeboot disabled
set bootdelay 2

/usr/local/sbin/remountrw

auto lo
iface lo inet loopback

iface ath0 inet static
        address 10.0.0.129
        netmask 255.255.255.0
        broadcast 10.0.0.255
        gateway 10.0.0.1
        up iwconfig ath0 ap 00:20:A6:47:F9:77
# alternatively use
#       up iwconfig ath0 mode managed essid socalfreenet.org 

auto eth0
iface eth0 inet static
        address 10.0.3.1
        netmask 255.255.255.0
        broadcast 10.0.3.255

#!/bin/sh
modprobe ath_pci
ifup --force -v ath0

chmod 777 /etc/rcS.d/S99local

modprobe hostap_pci
ifup --force -v wlan0

#NC:23:respawn:start-stop-daemon -S -c nocat --exec /usr/local/nocat/bin/gateway -- -F

/usr/local/sbin/fastreboot

pebble:~# ifconfig
ath0      Link encap:Ethernet  HWaddr 00:20:A6:47:86:7A
          inet addr:10.0.0.129  Bcast:10.0.0.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:633 errors:0 dropped:0 overruns:0 frame:0
          TX packets:30 errors:7 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:199
          RX bytes:46932 (45.8 KiB)  TX bytes:2062 (2.0 KiB)
          Interrupt:10 Memory:c4895000-c48a5000

eth0      Link encap:Ethernet  HWaddr 00:00:24:C1:8C:34
          inet addr:10.0.3.1  Bcast:10.0.3.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:100
          RX bytes:120 (120.0 b)  TX bytes:0 (0.0 b)
          Interrupt:11 Base address:0x7000

PING 10.0.0.128 (10.0.0.128): 56 data bytes
64 bytes from 10.0.0.128: icmp_seq=0 ttl=15 time=59.2 ms
64 bytes from 10.0.0.128: icmp_seq=1 ttl=15 time=1.7 ms

--- 10.0.0.128 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 1.7/30.4/59.2 ms

/usr/local/sbin/remountrw

nameserver 10.0.0.1
nameserver 64.81.45.2

echo 10.0.3.1 >/ro/var/dnscache/env/IP
touch /ro/var/dnscache/root/ip/10.0.3
ln -s /rw/var/dnscache/root/ip/10.0.3 /var/dnscache/root/ip/10.0.3
rm /ro/var/dnscache/root/ip/192.168.*

INTERFACES="eth0"

option subnet-mask 255.255.255.0;
default-lease-time 600;
max-lease-time 7200;

subnet 10.0.3.0 netmask 255.255.255.0 {
  range 10.0.3.10 10.0.3.99;
  option routers 10.0.3.1;
  option broadcast-address 10.0.3.255;
  option domain-name-servers 10.0.3.1,10.0.0.1;
}

/usr/local/sbin/fastreboot

ntpdate -u 10.0.0.1
/sbin/hwclock --systohc

Proxim 8571 802.11a AP dismantled

Here's some pictures of the inside of the Proxim Harmony 802.11a AP with removable antennas:

Update (Dec 2004): The device can be reflashed with Linux, but its 'nontrivial'. Read the gory details. Also the telnet password is 'notbrando'. Not sure what extra facilities that provides.

This radio was recently available for $15 + shipping and tax (originally $600).

Its features, well documented in the manual include:

• detachable antennas using SMA-female connectors (not RP-SMA)
• uses dhcp by default then a web interface for config
• supports channels 56,60 and 64 only
• supports SNMP (disabled by default)
• allows config for RTS/CTS and fragmentation
• has optional integral POE (but its NOT standard), see page 26

Getting inside was a little tricky. The screws are some special type with an outside pattern and inside hump that makes using a screwdriver, torx or hex key impossible. However by drilling out the center hump with a 5/64 bit, its possible to then use a 5/64 hex (allen) key to remove the screws. Failing that you can easily drill out the screw head - but then its hard to get the cover back on.

POE is supported, sort of. Its designed to be used with the Harmony Power System which supplies 24VDC with ethernet pins 4-5 DC+ and 7-8 DC-. Thus a regular 48V POE is likely to be problemmatic (though I don't pretend to understand the POE spec in any detail!). It definitely should be ok to use for short runs with a homebrew POE adapter like this one where we reuse the supplied PS which is marked 12VDC but measures 14V under load. Having the wiring already internal to the AP saves building the splitter part of a standard homebrew PoE injector.

Configuring the Laptop with Debian

First step was to install Debian. I chose this because its package system makes it easy, plus Pebble is also a cut down Debian and thus it shares the same file layout and commands.

There are many guides to installing Debian, so I'll just highlight some of the strangeness I found and some decisions I made.

• Three partitions: one for the OS, one for swap space, and then another for the squid proxy cache. Since the cache is the busy part of the system, I wanted to keep it separate in case it got currupted etc.
• Because the laptop was using a Belkin PCMCIA network card that wasn't in the default distribution, this generated a little research and several installs. The end result was something like:
  • when prompted to install a 'net' device, choose 'dummy'. This will trigger the other network setup prompts. Alternatively you can hack the /etc/network/interfaces file directly if you prefer.
  • Immediately after booting the first time, use <alt><f2> to switch to another login. Login as root with no password required
  • follow these directions which amount to inserting the PCMCIA card info into /etc/pcmcia/config
  • edit /etc/network/interfaces and replace dummy0 with eth0. Issue the command ifdown dummy0
  • finally do a /etc/init.d/pcmcia restart
  • At this point, you should have a working network interface and be able to ping the outside world and be pinged by others. You can go back to the main console and continue with the rest of setup now that you have a working network connection.
• There was still a problem with the network interface not coming up after reboot. A little googling found an answer which boiled down toremoving the 'auto' line from /etc/network/interfaces, and installing the 'hotplug' package.
• Don't choose any options from task select. It just installs a bunch of stuff you won't need. I used dselect instead to install squid and just squid (none of the html config stuff).

Once you have it all installed and running, you can try to use it from another machine. For my subnet, I first tested by putting the laptop on the subnet and then logging in via ssh and making sure it could access the internet and generally work as expected.

When you're satisfied its working correctly, you're reading to configure squid.

Configuring Squid as a redirected transparent proxy server

Once you have the laptop running correctly, you're ready to get squid configured. We want to use squid as a 'transparent proxy'. This means that users won't have to do any configuration on their machine to use squid and benefit from the proxy. And, alternatively, users won't be able to avoid the proxy, and hence we get maximum benefit of the cache (more info, and HowTo).

The squid configuration file for debian is found at /etc/squid.conf. The vast majority of the values can be left as is, at least until you start tuning squid. Here are some settings we changed from the defaults:

httpd_accel_host virtual
httpd_accel_port 80

httpd_accel_with_proxy on

httpd_accel_uses_host_header on

These few lines should get squid going enough to test. Issue the command /etc/init.d/squid restart to force it to re-read its settings (though maybe a SIGHUP would do the same thing more elegantly?).

Now squid should be working. You can test basic functionality by setting the proxy settings of your web browser to point directly to the squid proxy. If you issue the command /tail -f /var/log/squid/access.log you should be able to see the pages you're visiting being logged. (Use Ctrl-C to break out of the tail).

Next up is how to change the firewall / gateway settings to force users to use the proxy.

We did some minor tuning with these settings:

maximum_object_size 8192 kb

Transparent Squid Proxying with MikroTik

Once you have squid working, you can now start forcing traffic to use it. If you have a single gateway box, this is most likely the easiest place to do this. In our network we run MikroTik's RouterOS which is in turn based on Linux and supplies all the hooks necessary to do what's needed.

The basic idea is to redirect all outbound traffic on port 80 to the squid server. The devil is the details!

more to come, but basic idea follows

• Set up a rule for Destination Nat that sends all traffic on port 80 to the squid server, except traffic from the server itself, and, in our case where we have a captive portal, excepting traffic to the captive portal too (though maybe it works ok anyway?).

make sure the squid server is exempt from captive portal signon. The tricky part is making it exempt but not a client that signs on through it (hence exception above that the captive portal destination is exempt).

The squid box must send all replies back to the gateway, not to the requesting machine directly - its not expecting them! So in the squid box's file /etc/network/interfaces is the extra line:

up "route add -net 10.0.0.0 netmask 255.255.255.0 gw 10.0.0.1"

which adds a static route to force all traffic on the squid's subnet (10.0.0.x) back to the gateway which will in turn route back to the correct host.

m0n0wall Captive Portal Design

Many thanks to the Personal Telco CaptivePortal page which formed the genesis of this page.

User Usage Flow:

1. a new user gets physical connectivity to the network


2. they issue a DHCP request and are assigned an IP address (all
   un-authenticated IP's are firewalled so they can only talk on the local
   segment)


3. As soon as they open their browser they will be forced a local web page
   (see below)


4. this web page will have a "Continue" button which must be pressed by
   the user to continue


5. after they continue their IP is granted access through the
   firewall

Another approach to this (as done by NoCat?) is to hand out very short leases (15 secs) in another range until the user 'Continue's, and then give them a lease that lets them outside. Maybe this would be easier given the questions that Manuel raises.

Open questions:

1. once the user does 'continue' do they have access until their lease
   expires?  (Or when?)


2. do we need to create a separate tracking mechanism or can we piggyback on
   the IP lease mechanism? (which implies, possibly, that static IPs, or
   preassigned-by-MAC DHCP IPs are exempt?)

Admin Tools

1. per development criteria, the captive portal page will be stored in
   config.xml and edited directly in the GUI. I propose a simple page where
   admins can specify all text on the admin page (to allow for localization).
   Note that there is no provision for a graphic due to the config.xml
   restriction




• page heading


• preface text


• legal wording


• continue button text
  

Another approach would be to allow the user to supply xhtml for the whole page - but that requires them to know what code to use for the button, etc. It seems less error prone to assemble the page from seperate pieces.

2. there should be a way to disconnect a given IP which means that


3. there should be a way to view all IPs in use


4. if we decide on a timeout separate from dhcp lease timeout, then we'll
   need to prompt and gather that info

Future Features

We won't try and do everything in this release. Here are some things we can
do next:

1. automatically add throttle rules for each new IP based on a global
   default

m0n0wall Captive Portal Development Constraints

M0n0wall is succesful in large part due to the vision of its designer. Manuel provided the following guidelines that a captive portal needs to meet for him to consider adding it to the core m0n0wall release (taken from Manuel's email):

• adds < 100 KB to the root filesystem


• copes with low-end embedded platforms (think about a 32 MB/100 MHz
  net4511),


• have to be put under the BSD license like the rest of m0n0wall


• will be subject to whatever changes Manuel finds appropriate


• all the config in one single place (config.xml)


• all admin via the http interface (no ftp of files)

Manual also asks:

Did you check that it fits in with the rest of m0n0wall
without requiring a complete overhaul thereof? I mean - you know that
ipfilter doesn't do layer 2 filtering, and that ipfw has got a kinda
"reserved" function for the traffic shaper, which must work no matter if the
captive portal is on or off. Same goes for other functions like VPN etc. of
course.

m0n0wall Captive Portal - Links to Existing Implementations & Thoughts

A little googling reveals a few FreeBSD captive portals:

http://www.cc.saga-u.ac.jp/opengate/index-e.html
http://opensplash.qalab.com/
http://software.stockholmopen.net/index.shtml

and a bunch of others (not necessarily FreeBSD based) at:

http://www.personaltelco.net/index.cgi/PortalSoftware

I admit I'm out of my depth here when it comes to the level of hacking required for this, but I figure I know enough to be dangerous and can kick start this conversation, so here goes...

Manuel asked here:

Did you check that it fits in with the rest of m0n0wall without requiring a complete overhaul thereof? I mean - you know that ipfilter doesn't do layer 2 filtering, and that ipfw has got a kinda "reserved" function for the traffic shaper, which must work no matter if the captive portal is on or off. Same goes for other functions like VPN etc. of course.

Two different ways I've heard of implementing captive portals are:
1) change the filtering rules to re-direct newly leased IPs to a specific page, then reset the rules when they're approved
2) change the DHCP server to initially supply very short leases in a different, walled-off, subnet and then provide a new IP when they're approved.

One problem with (2) is that someone might simply create their own static IP in the right (2nd) range, but if (1) proves hard, maybe its a good 80% solution?

I think NoCatSplash is an example of (1), http://nocat.net/download/NoCatSplash/.

Perhaps a better starting point is http://www.geekspeed.net/wicap/, which is a captive portal that runs on OpenBSD (presumably closer to FreeBSD than Linux?).

Btw, for those new to m0n0wall, read the full description of its FreeBSD based underlying software and configuration.

m0n0wall Captive Portal - US$222.50 Reward for Development

There is a $222.50 reward(*), plus 1 yr NYCWireless membership and T-Shirt, to anyone who can add captive portal support and an additional $222.50 to Manuel (m0n0wall's developer) to reflect the work he's done to date and the work doubtless involved with integrating even the best made additions. I'm doing this to try and speed up the appearance of captive portal support which is vital for using m0n0wall in more community projects.

Please email me if you'd like to add to this amount.

The rules are (hopefully) simple:

• The resulting code has to be integrated into the mainstream m0n0wall release. Hence it has to meet the criteria Manuel specifies (which is subject to change as needed).
• The reward is paid in US dollars by whatever legal mechanism is mutually agreed upon and convenient (e.g. either directly or as equivalent goods, or whatever).
• In the event of some confusion about who did what work, the final decision about who gets what money is mine alone. I'll do my best to be fair to all concerned. Its possible that the reward will be split amongst multiple people at my sole discretion.

Feel free to post comments directly to this page or on the m0n0wall mailing list. Thanks! Michael Mee.

(*) This total reflects $200 of my own money and, so far, $100 of an anonymous contributor, another $100 from www.openacces.org, $20 from Barry Murhpy and $25 from Benjamin Henry, as well as a contribution from NYCWireless. I'll continue to split contributions 50-50 with the contributor and Manuel.

Backhaul Subnet Allocations

The thirty-two 10.12.0.0/29 subnets are used for backhaul links within our various networks. This page is for tracking their allocation and other useful details.

Why We Have These

Our networks are generally routed networks of individual subnets rather than bridged networks. This is in large part because few of the wireless card drivers we use allow bridging directly between two wireless cards. Thus it is often necessary to have a couple of IP addresses to link between two nodes. Rather than take a large IP address space (e.g. a /24 containing up 252 addresses) we use smaller /29 subnets that allow 6 IPs. Most of the time we only need two IPs, but occaisionally we need more (e.g. a point to multi-point link, or a management IP) so we went with the slightly larger space.

Allocations

El Toyon Network Allocation

This page details the network work configuration for the Golden Villa installation.

Subnet 10.12.10.0/24

This installation uses the 10.12.10.0/24 subnet - i.e. 10.12.10.0 to 10.12.10.255. This is further divided as follows:

A Soekris 4511 is used as the main router, running m0n0wall. The two ports are assigned as follows:

Other addresses used on the network:

MAC addresses of equipment in the network:

Golden Hill Network Allocations

The following are the subnets and various hardware info for the Golden Hill network. It is currently incomplete.

Subnet 10.12.2.0/27 - K26 (924 26th Street)

This installation uses the 10.12.2.0/27 subnet - i.e. 10.12.2.0 to 10.12.2.31. This is further divided as follows:

A Netgate PowerG8 is used as the main AP, running m0n0wall. The three ports are assigned as follows:

802.11b config settings summary

Subnet 10.12.8.248/29 - backhaul network LC to 27th and K26

Network: 10.12.8.248/29 (255.255.255.248)
Broadcast: 10.12.8.255
HostMin: 10.12.8.249
HostMax: 10.12.8.254

This small subnet hooks the La Cresta 802.11a backhaul to Pink Palace to the 802.11a radio that services 27th and Broadway and soon also K26. The 'a' radio runs in bridged mode to avoid another subnet and for simplicity.

Allocated as follows:

Golden Villas Network Configuration

This page details the network work configuration for the Golden Villa installation.

Subnet 10.12.11.0/24

This installation uses the 10.12.11.0/24 subnet - i.e. 10.12.11.0 to 10.12.11.255. This is further divided as follows:

A Soekris 4501 is used as the main router, running m0n0wall. The three ports are assigned as follows:

Other addresses used on the network:

MAC addresses of equipment in the network:

Mercado network IP addresses

Mercado Network IP Information

The Mercado network consists of a master node and subnodes. Each subnode consists of an 802.11a relay radio and an 802.11b local AP radio. Each subnode has its own independent subnet and runs its own dhcp server and DNS cache. This allows easier location of problem clients (they can be readily identified by IP).

Each subnode works in a 32 address subnet and follows the same
general layout:

The subnets are allocated from the range 10.12.12.x as shown
below:

Using the scheme above, the actual addresses assigned are:

Master Node Addresses

Node 1 Addresses

The other nodes are configured similarly, using the following table for their 802.11a backhaul subnet address.

Backhaul subnet address allocation