[CUWiN-Dev] more summer of code projects

[David Young]

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

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933