Welcome!

Thanks for checking out the CUWiN Summer of Code information page (find out more about CUWiN here and here). CUWiN is looking for interested summer developers to work on the projects below. If you are interested in working on any of these projects, you can learn about Google Summer of Code here. If you would like to propose a CUWiN project, sign up to be a CUWiN mentor, or have questions for the CUWiN team, send an e-mail to: cu-wireless-support@cuwireless.net. The following CUWiN staff have volunteered to head up coordination and mentoring of Summer of Code participants and help support their efforts:

• Sascha Meinrath
• Ross Musselman
• Chase Phillips
• Dave Young

If you would like to be a mentor, the requirements and responsibilities are here:

http://code.google.com/soc/mentorfaq.html

You can apply to be a mentor by submitting this form:

http://code.google.com/soc/mentor_step1.html

Information for Student Applicants

CUWiN is looking for a few good developers. Have what it takes? Then check out the Google Summer of Code Student FAQ for further information about: the program, eligibility, what a mentoring organization (like CUWiN) is, how to apply, getting paid, deadlines, how to get your t-shirt, and much, much more. Summer of Code applications can be filled out starting May 1, 2006.

Here is a short list of requirements that you must meet in order to get accepted as a student participant in the Summer of Code program:

1. You must not overbook yourself. Working on your CUWiN project should be your main activity for the entire summer.
2. You must be willing to provide weekly status reports.
3. You will be expected to learn how to use Subversion and maintain a Subversion account in our repository.

The most important item is #1. You may have a lot to learn before you will get to the point where you can begin coding your project. We will provide you with amazing support from the mentors and wireless community, but it is up to you to make sure that you can focus on your CUWiN project.

Here's information on writing a successful Summer of Code Application (thanks to the great folks at Drupal for pulling this together):

Competition will be fierce, so what can you do to help make sure your application gets serious consideration? Here are some tips, straight from last year's mentors themselves:

Sell your idea. Describe your idea in detail. What is its ultimate goal? What components will it have? What benefits does it have for CUWiN itself and its community? How do you plan to achieve completion of your project? If a specification already exists, what will you do that will go above and beyond expectations?

Sell yourself. Get across your enthusiasm for the project. Tell us what makes you stand out from the rest of the crowd. Talk about your past experiences, what makes you tick. Why are you interested in open source software, and CUWiN in particular? What interests do you have, and how do these interests relate to the project for which you're applying? There is a basic assumption that people applying for Summer of Code will have programming skills already. So rather than spend a lot of time elaborating on these (though by all means, do tell us what you know), spend time talking about you.

Show enthusiasm. Summer of Code is a very exciting opportunity, and CUWiN is an extremely exciting project to work on. We're not just looking for people who want a summer job to pass the time, we're looking for devoted people who have an intrinsic passion for open source, and are (or will become) CUWiN zealots down the road.

Tailor your application to the project. It was painfully obvious last year that certain people copied/pasted parts (or even the entirety) of their applications to multiple projects. This can be seen from a mile away, and it is a sure-fire way for your application to not be taken seriously. Each application you send should be targeted and tailored for the specific mentoring organization and project to which you are applying.

Get feedback on your idea from the community. Discussing your idea with some established CUWiN folks is vital. If your idea duplicates existing efforts or code (and does not provide a very convincing reason for doing so), it will be rejected. Try to have your application reviewed by someone before you submit it, whether that be the mentor for a particular project itself (in the case of already generated ideas on the following pages), or a person with expertise in a certain area (such as IPv6, or routing protocols). Don't be afraid to ask the community for help; we want you to succeed just as much as you do. You can contact the CUWiN support team at: cu-wireless-support@cuwireless.net or join the CUWiN Developers list here.

Don't be afraid to go out on a limb. Have a brilliant idea that's not covered by the proposals on the following pages? Great! Don't be scared to try and think "outside the box" and come up with a fantastic idea of your own. If you know enough about the project to suggest additional helpful projects, that lets us know you're serious about the CUWiN initiative.

Proposed Summer of Code Projects

1. Trimming the size of the CUWiN system.

Two benchmarks for the project exist: first, we absolutely must fit in 32MB RAM, 8MB ROM. To allow for upgrades, that is actually 4MB ROM that the whole system has to fit into; secondly, to fit on some interesting devices, we need to get as small as 2MB ROM total (there will be about 8MB RAM), in addition, keeping a "last good" partition may not be possible for installs of this size. Here are some things that will make CUWiN smaller for devices with very small ROM/RAM:
• Add more files to filter-syspkg/{trimlist,*-pass-omissions}. Remove ntpd altogether (easy).
• Use crunchgen(1). This will yield the greatest reduction in size.
• Make tiny version of tcpdump (don't print anything, just filter and record to a file; rare protocols removed).
• Build kernel w/o IPv6.
• Make it possible to build hslsd w/ only IPv6 or IPv4 (harder, may not make a big size difference).

2. Integrate Node Configuration GUI.

Build the GUI from the mockup available at www.cuwireless.net/nodeconfig.

3. 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 ' option. Demonstrate either a CUWiN CD-ROM for a non-i386 system, or a kernel with memory-disk root for non-i386, or both.

4. Add a kernel API for changing WLAN transmit parameters.

Just as it says -- ideally would interface with other facets of the GUI.

5. 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!

6. 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.

7. 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.

8. 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.

9. Create a scheme for harvesting and publicizing node data.

Community wireless networks are frequently created based largely on volunteer effort. As nodes in a CUWiN-based mesh are set up, there is no automatic data publication or harvesting that happens that gives network implementors a vision of their network's size, its strengths and weaknesses, and where future volunteer effort should be spent. Any effort to create this list is purely manual.

Implement a central authority for a wireless "cloud" that receives node status updates. The authority will receive reports sent by a daemon on each node which you will also implement. This project is less overall work than "Configuration information store" or they could be combined if a team of students chose to work together.

10. Implement a testing system for CUWiN's routing protocol and metric.

CUWiN networks use HSLS (hazy-sighted link state) as a routing protocol to determine how the network is laid out. Among other information, this protocol provides a way for node A to know how to talk to node C by finding out that both A and C can talk to node B. Each node has a "map" of the network and uses that to update its local routing table.

As the network grows in size, the protocol can succomb to scaling and complexity issues. The daemon that implements the protocol and metric can succomb to software bugs and performance problems. Since no test harness currently exists to test our HSLS implementation for bugs or for its capabilities, most of our testing happens in the field and under uncontrolled circumstances.

Implement a test harness for our HSLS implementation that will demonstrate CUWiN's current capabilities and provides an environment to validate the software we issue to community wireless networks.

The test harness should allow us to set conditions on testing to ensure certain pre-existing environments work as expected and for attempting to create reproduceable test cases in this lab. We should also be able to use it for testing other routing protocols to compare their performance as network size and configurations grow. (For example, other routing protocol implementations can be found in the quagga daemon which is included on a CUWiN node.)

11. CUWiN/WiFiDog Integration.

Combine the meshing fuctionality of CUWiN with the web-portal applications of WiFiDog.

12. Port CUWiN to Additional Consumer-Grade Devices

Have an idea? Pitch a device, why it's important, why CUWiN should be ported to it, how it'll help spread connectivity and low-cost bandwidth sharing.