Monday, June 15, 2009

FabFi 2.0oooh?

After a bit of a hiatus from FabFiing, I went back to the drawing board on the FabFi architecture, with the hope that I could solve the downstream routing issue and add meshing capability to the mix. The way we're trying to use Fabfi in JBad is special because we want both a long-haul backbone and local mesh using one setup routine. Additionally, the concept of AP and STA has proven confusing for the local users, so deleting it would be sweet...

Since we started on FF1.0, OpenWRT came out with a new release (8.09) that incorporated a bunch of new features, including an integrated web-admin GUI, and functioning OLSR packages, so after playing around with freifunk, which is still stuck back in Whiterussian, I flashed a few routers with 8.09 to see what they could do.

...and they did, but only very very slowly (72kbps slowly).

Here's the setup:
- 3 vlans: WAN, LAN, MESH; Wireless bridged to MESH
- olsr-luci runs on the br-mesh bridge (Wireless and wired MESH)
- The olsr-luci-mod-dyn-gw-plain plugin advetises nodes with net uplinks to the mesh
- The olsr-luci-mod-nameservice plugin passes around DNS server info from the nodes with uplinks.

All of the nodes are connected on the MESH addressed to Each node is statically given an IP (last octed is FabFi number). The nodes can be connected wirelessly or by wire.

Any node can provide an uplink, but as of this setup the user must specify that it is acting as such by identifying it as a DNS server.

Every node provides a LAN on 10.1.x.0/24 (x is Fabfi number).

Which nodes wirelessly link to each other can be controlled with the SSIDs and/or wireless channel (only matching ones link).

The Results:

- All nodes link nicely, and seem to do the meshing thing.
- One can ping any node in the mesh, and there are routes available to any subnet.
- All the nodes can see the net

not so good:
- The net is slooooow. (72kbps)
- If dnsmasq is started / restarted after olsrd, the DNS server information provided by the nameservice plugin gets blown away (presumably until the server changes? Not sure)

Ideas anyone?

Wednesday, June 10, 2009


I recently received some photos back from Amy, who's back in JBad doing some FabLab management. Due to absurdly high winds and some hardware problems, the GATR ball (net uplink) was down for about two weeks, during which many of the folks downstream on the FabFi net all of a sudden realized the usefulness of the resource they had been taking for granted for a while since the last significant outage.

It turns out the hospital link had been so reliable that they dumped their CDMA net, despite our admonition that the FabFi net was for research purposes only and could not be depended upon to be up all the time. Go FabFi?

Though, everyone seems very happy with access to FabFi, local participation in the maintenance and troubleshooting of the system still has a long way to go. After the GATR was restored, hospital administrators were still calling to complain that their net was down. Similarly to last time, the trouble was with plugging in cables. This time the power brick was not fully inserted into the wall. A simple push on the plug and the node hopped right back into the system. Oi.

Was it horribly frustrating that something like the above could still occur after being deployed for so long? Yes. But did Amy get mad? Nope. She channeled all of that frustration into a troubleshooting guide and an updated configuration manual.

So getting to the back to the title of this post:

As shown in the photos from the watertower above, the original plastic bag and gaff tape weatherproofing we used on the antennas (intended to last a month from mid-January) is still in use and more than a little worse for wear, but STILL the net stays up in 70+ mph winds, blistering heat and blowing sand.

These images bring two questions to mind. First, how do we jumpstart the local FabFi user community to get together and maintain the hardware? And second, why can't I get the Linksys router in my apartment to work this well?