[CUWiN] FreeNet Router Project

Dan Flett conhoolio at hotmail.com
Wed Jan 12 23:15:58 CST 2005

Hi Ian, thanks for your comments

> Running my own Locustworld mesh but slightly unhappy about the way the
> source is
> controlled etc, I've been looking at the other projects around.
> WRT based ones , seasoft... wifidog

OpenWRT at this point is by far the best third-party firmware - the
closest to being a true Linux distro.  But it has it's own faults -
user-unfriendliness being the main problem.

> PC based ones like cuwin.

I'm trying to move away from PC-based nodes as PCs make noise and take
up valuable real-estate in the houses of mainstream users.  Geeks like
you and me don't mind white boxes humming away behind the couch or in a
cupboard, but we have to learn to think like non-Geeks. :)  A small,
silent box that can be easily mounted outside is far more attractive.
With a PC-based node you need to add up the costs of PCMCIA cradles,
pigtails and antenna cable. A small embedded platform costs about the
same or cheaper than a PC-based node - even if the PC is an old Pentium
box obtained for free.

> People want
> 1) 11b/11g support

Agree, but 802.11b isn't the greatest medium for backbone connections.
It's cheap though, and with good 'band-aid' solutions like Frottle it is
still viable as a scalable backbone medium.  There should be support for
adding-on other network mediums such as 802.11a, WiMAX, 802.11n, Ronja
red-light beams, Motorola Canopy gear, etc.

> 2) nodes capable of dynamic meshing and routing

Not necessarily.  Here in Australia government regulations largely
prevent us from using the Internet to link fixed nodes - so we are using
wireless as our fixed-backbone.  So that's where our priorities lie.
Roaming mobile access is not a priority for us yet.  So we are more
interested in traditional routing protocols such as BGP and OSPF to
route on our fixed-wireless networks.  I would like to see a
web-interface that makes configuring BGP as simple as possible for a

> 3) User authorization (nocat in most cases), and vpn support for users

I agree - users must be made accountable for their actions on the
network.  Anonymous access must be limited to access to captive portal
web pages.  As for VPNs, I see them as important, but not necessarily
needed to be supported on an embedded box.  I prefer OpenVPN myself, and
the WRT54G can support one or maybe two endpoints.

> 4) inter-node security/firewall (vpn or certs)

Should this be linked in with the User Authorisation system?
Node-to-node traffic, once the link has been established and authorised,
should not be firewalled at all (except to provide QoS measures).

> 5) traffic control, dianogtics and limits

I feel it is best to get a network up and running first before deciding
what QoS measures to use.  But yes, these issues will arise and will
need to be dealt with.
> and most of the stuff is open source and just needs taping together.

The taping together is the interesting and time consuming bit for me.
It requires that we know and understand all the nuances of all the open
source applications being used.  And then making them work in concert
with each other.

> The only main difference appears to be routing algorithm, and in
> thats a pluggable module.

I have thought a lot about how to approach the issue of regional
differences.  The German Friefunk-Firmware for the WRT54G is an example
of a firmware that is tailored specifically to local conditions.  It
could however be adapted to other regions.  Since the aim is to make the
firmware as user-friendly as possible, I think a tightly integrated
software suite is the best way to go.  The disadvantage is that it loses
modularity and therefore easy portability to other regions.  In time I'm
sure we'll see both modular and tightly-integrated approaches appear.



More information about the CU-Wireless mailing list