Network Topology

The node's IP settings run under one of two basic configurations. One configuration is that the node can act simply as a router that connects to the wireless mesh and routes packets through the mesh. If another node on the mesh is acting as a gateway to the Internet, the local node will discover it and can route any packets destined for the Internet to that gateway. In the other configuration, if your LAN has an Internet connection, the local node will function as an internet gateway that provides an internet connection to other nearby nodes. In either configuration, you can use the resources of the wireless mesh. If there happens to be a local independent band sharing their music on the wireless mesh, anyone with a node can download it and an Internet connection is not required.

It should be noted that every machine on every LAN in the wireless mesh is accessible by every other machine in the wireless mesh. This is a very powerful feature because it enables anyone to create content and serve it to everyone on the mesh via their desktop computer with no additional cost. Local births, weddings, and deaths could be posted on the web via the county clerk's desktop computer. The municipal pool could broadcast their hours in a similar manner. Local radio stations could stream music to listeners on the wireless mesh. The imagination's the limit. The problem is that someone sitting in a van on the edge of town, or the latest computer virus outbreak, can also access everyone's computers if your firewall isn't set up appropriately. So it is important to remember to secure your computer(s) and place firewalls where appropriate.

It is the intention of the developers of CUWiNware that the final software incorporate firewall functionality into each node. Ideally, nodes would auto-configure themselves to allow others to only access the services that are advertised by their LAN, and allow users to explicitly allow others to access non-zeroconf services. None of this has been implemented as of this writing.

A major advantage of CUWiNware is that the mesh doesn't need an Internet connection to function properly. Everything described in this manual should function if a single backbone is used, if multiple volunteers provide home DSL lines, or if no Internet connection is used. It is completely stand alone.

Wired Interface

On the wired LAN side of the local node, CUWiNware checks for a DHCP server on the LAN. If one is found, the node takes the IP address assigned to it and provides an Internet gateway to other wireless nodes. If no DHCP server is found, the node assumes that it should function as a router and DHCP server for the LAN. The node creates a wired IP address for itself in the form 10.A.B.254. A and B are chosen via the MAC address to minimize IP address collisions with other LANs on the network, but because they are based on the MAC, they are the same every time the node is booted. The DHCP server assigns leases to addresses in the range 10.A.B.1 - 10.A.B.253. If you need to assign IP settings manually, that can be done via the SSH interface.

Wireless Interface

The wireless IP address is another number based on the MAC address that is in the form 10.0.A.B. In places, you may see a reference to a 192.254.A.B address. Do not be alarmed. Because of suttlties in the kernel, CUWiNware uses the 192.254.A.B address for link-local routing traffic.

At this time, you cannot use a node as a wireless access point, even if it has two wireless cards in it. Also, the nodes only serve as repeaters for mesh traffic, they don't route any other traffic. Each node can only connect wirelessly to each other node. The only public interface is through the ethernet port. At some point in the future when, the developers have more time or volunteers, much more wireless functionality will be included.

Channel and Mode Selection

Currently, CUWiNware uses a user defined channel (the default is 11) in the 802.11b mode. Currently, the mode selection selection is made at compile time, but there are plans to make CUWiNware automatically adapt the network to the best mode and channel for the area on the fly.

Can you change the radio used by CUWiN?

Posted to the developer's mailing list on July 13th, 2005 by David Young.

I cannot think of any reason the driver should not work for 802.11a. I have some a/b/g cards on our indoor testbed. I will give .11a a try sometime next week.

The problem I anticipate is a lot more mundane than device driver compatibility: we set the operating mode to 802.11b at "compile time." You have to fiddle with some scripts to use any other mode. To use 802.11a, you have a few choices:

• compile-time configuration: you can build a CUWiN distribution that sets the mode to 802.11a, instead. (Change the text 'mode 11b' to 'mode 11a' in cuw/trunk/src/boot-image/extras/etc/ifconfig.wireless.tmpl.) CUWiN can help you with that.
• you can change our web configuration widget so that it lets you program the operating mode (.11a, .11b, or .11g). CUWiN can also help you with that.

When you add a second radio, things get a little bit more complicated, because presumably you want to operate them on different channels, or even on different bands. The first problem is that the web configuration widget only works on one radio; that will have to be changed. It's not hard, just nobody has done it, yet.) You can do "compile-time" configuration of multiple radios, but you have to make assumptions about the order that radios are enumerated---that is, you have to take care that radio #0 and radio #1 are not reversed in your Metrix boxes, or else that they are not reversed in your configuration files.

Routing

The wireless mesh itself is created via a routing algorithm called HSLS (Hazy Sighted Link State). HSLS is in the family of wireless routing algorithms called FSLS (Fuzzy Sighted Link State). The basic observation behind FSLS algorithms is that changes in links that are far away on the mesh are less important than those links that are nearby. In an FSLS powered mesh, any changes in the link states are propagated quickly to the nearby nodes, but more slowly to distant nodes.

For example, consider a wireless mesh that spans a city and its suburbs. Nodes A, B, and C are located near a small park in the downtown area. Node Z is in the far reaches of the suburbs. Nodes A and B are linked together, but suddenly the link is broken when high winds knock A's antenna off of its mounting pole. C learns of this change within a second, and alters it's routing table, but it is many minutes before Z discovers that the link between A and B has been broken. Once Z learns of this altered link, no changes are made to its routing table because it doesn't use the link between A and B in its link state calculations anyway.

For more information see the HSLS documentation in this manual.

Scalability: Maximum Network Size

Generally, in ad-hoc mesh networks, the factor limiting the size of the mesh is the routing algorithm. Often, when an ad-hoc mesh reaches a certain size, it collapses because the routing algorithm doesn't scale. This can be due to a number of reasons. With some routing algorithms, the network spends all of its resources transmitting all link changes to each other node on the mesh, and no useful traffic can be transmitted. With other algorithms, link changes are not transmitted soon enough, and the packets are dropped because a node does not have enough information to transmit the packet to the next node. Other types of meshes do not scale because they require very specialized human intervention to define the routing table for each node. Sometimes, a mesh fails because the latency from one side to the other becomes too high. Because of these problems, many meshes have not been able to scale over twenty nodes.

The HSLS algorithm used by CUWiNware is intended to scale to at least thousands or tens of thousands of nodes. To be honest, though, we will not know for sure how well it scales until a community pushes the boundaries.