[CUWiN-Dev] more summer of code projects

[Sascha Meinrath]

uploaded to the www.cuwireless.net/2006soc website!

folks should send in any other ideas you may have.

--sascha

David Young wrote:
> 1 Cross-build CUWiN on non-i386 architectures
> 
>         CUWiN is based on NetBSD, which runs on a large number machine
>         architectures, including 64-bit AMD, ARM, i386, MIPS, PowerPC,
>         32- and 64-bit SPARC.  NetBSD also runs in Xen virtual machines.
> 
>         NetBSD comes with a script, build.sh, that builds the
>         cross-compilation toolchain, kernel, and user programs, for
>         every architecture that NetBSD supports.  Changing the target
>         architecture is a simple matter of changing the '-m' option
>         argument to build.sh.
> 
>         The CUWiN system uses build.sh to cross-build NetBSD from Linux
>         and Mac OS X, however, CUWiN does not build for more than one
>         architecture.
> 
>         Revamp the CUWiN build system to exploit NetBSD's ability to
>         cross-build for non-i386 machine architectures.  Add to the
>         CUWiN build script, mkstaboot, an '-m <architecture>' option.
>         Demonstrate either a CUWiN CD-ROM for a non-i386 system, or a
>         kernel with memory-disk root for non-i386, or both.
> 
> 2 Discovering and selecting Internet gateways on a dynamic mesh
>   network.
> 
>         Community wireless "mesh" networks are usually "multi-homed,"
>         that is, they connect to the Internet in more than one place.
>         Multi-homing on community wireless meshes is complicated by the
>         presence of Network Address Translation (NAT) at the gateways.
>         Dynamic wireless links compound the complexity.
> 
>         Write a daemon that advertises, discovers, and selects IPv4
>         gateways.  Select IPv4 gateways that are "best" according to the
>         routing metrics.  Protect against severance of TCP sessions with
>         a change of NAT gateway.
> 
>         CUWiN favors a solution that involves tunneling to one or more
>         IPv4 gateways and using the pf stateful firewall to "stick" a TCP
>         session to its NAT gateway.  If you understand IP-in-IP tunnels,
>         stateful firewalls, and IP routing, the intricacies (and evils)
>         of NAT, this may be the project for you!
> 
> 3 Distribute IPv4 & IPv6 prefixes on a community mesh
> 
>         CUWiN would like for everybody who belongs to a community mesh to
>         have their own global IP number, so that they can run their own
>         web server, place & receive VoIP telephone calls without grotty
>         hacks like STUN, and generally be a first-class network citizen.
> 
>         To that end, CUWiN needs a system for automatically distributing
>         global IP numbers to subscriber's mesh nodes.  The global numbers
>         may come from any number of sources, including a DHCP server,
>         IPv6 prefix advertisements, or manual configuration.
> 
>         Let us say that each router on the wireless mesh has a pool of
>         zero or more global IP numbers that it can allocate to itself and
>         to other routers on the mesh.  Write a daemon that advertises the
>         pool's availability throughout the routing domain, that grants and
>         requests "leases" on IP numbers from pools throughout the domain,
>         and that configures the router and subscribers' home PCs with
>         "leased" IP numbers.
> 
> 4 Configuration information store
> 
>         Have you ever botched the configuration of a wireless router
>         at the tip-top of your steeply-slanting roof in the middle of a
>         thunderstorm?  Did a lot of people depend on that wireless router?
>         Did it take a long time to restore the router to working order?
>         Did you need a ladder to do it?
> 
>         Sometimes CUWiN routers end up in places where it is inconvenient
>         or dangerous to plug your laptop into the ethernet or serial
>         port to manage them.  Sometimes an operator has no choice but
>         to reconfigure a router "over the air."  If an operator tunes
>         to the wrong frequency channel, for instance, or deactivates the
>         wrong wireless interface, they might lose control of the router.
> 
>         Commercial routers by Cisco, Juniper, NextHop, and others,
>         centralize the configuration of the router in a transactional
>         configuration information store that has commit/auto-rollback and
>         undo/redo functions.  An operator can make tentative and, more
>         importantly, incorrect configuration choices (e.g., deactivating
>         the wireless interface he sends his configuration commands
>         over!) with confidence, because the router will "roll back"
>         to the last good configuration if several seconds pass without
>         operator activity.
> 
>         Create a configuration information store for the CUWiN system.
>         The store should be structured as a tree, with individual
>         configuration items named by slash-delimited paths from the root
>         of the tree.  The operations on the tree are these:
> 
>                 value = get(path)
>                 old_value = set(path, value)
>                 create_container(path)
>                 delete_container(path)
>                 handle = start_listen(path)
>                 stop_listen(handle)
>                 stream = serialize(path)
>                 deserialize(path, stream)
>                 set_redo_action(path, action_string)
>                 set_undo_action(path, action_string)
>                 generation = get_generation()
>                 redo(generation)
>                 undo(generation)
>                 commit(generation)
> 
>         Applications that use the store (e.g., an SNMP server or a web
>         configurator) will control it by sending operations over a socket.
>         An application can monitor the state of configuration items at
>         a certain path by registering as a "listener" for that path.
> 
>         Applications label a path with both a "redo" and an "undo"
>         action; these are shell commands that the store runs to apply
>         a make a configuration change "live," and to "revert" a change,
>         respectively.  For example, consider this tree:
> 
>                 /interfaces
>                 /interfaces/0
>                 /interfaces/0/name              = eth0
>                 /interfaces/0/addresses
>                 /interfaces/0/addresses/ipv4
>                 /interfaces/0/addresses/ipv4/0  = 192.168.1.1
> 
>         The path /interfaces/0/addresses/ipv4/0 may be labeled by the
>         redo-action
> 
>                 ifconfig $(../../../name) inet $(.) alias
> 
>         and undo-action
> 
>                 ifconfig $(../../../name) inet $(.) -alias
> 
>         Where the $() notation interpolates the value stored at a path.
> 
>         This configuration manager should be versatile enough to
>         configure any kind of networked appliance.  It could work with
>         Quagga/BIRD/XORP.
> 
>         You only need to produce a simple command-line app for the store.
> 
>         TBD finish specs for this.
> 
>         This is an ambitious project for one summer.
> 
> 5 Community Domain Name Service & Service Discovery
> 
>         CUWiN has designs for a community name service that puts
>         subscribers in control of their name on the 'Net, and lets them
>         advertise web servers and chat-client "presence" information
>         to their neighbors.  Some code exists in a very rough form.
>         Finish it.
> 
> Dave
> 


-- 
Sascha Meinrath
Policy Analyst    *  Project Coordinator  *  President
Free Press       *** CUWiN               *** Acorn Active Media
www.freepress.net *  www.cuwireless.net   *  www.acornactivemedia.com