Motherboard/CPU Considerations
While the CUWiNware software will operate on most 486 or better platforms, most old consumer-grade 486 and original Pentium desktop machines have such old motherboards that PCI Wireless NICs or PCI/PCMCIA bridge cards will not function properly. Check to see if your wireless card requires PCI 2.0 and, if so, whether the motherboard of the desktop you are using has a PCI 2.0 compliant motherboard.
Your options for a wireless NIC are to use a PCI wireless card, a USB wireless card, or a PCI/PCMCIA bridge card with a PCMCIA wireless NIC. It is probably easiest and cheapest to find a compatible PCI card.
It is easiest if the BIOS on your low resource node supports booting from CD-ROM. Some very old motherboards do not support this. If you can't boot from CD-ROM, it is possible to bootstrap with a special floppy disk which will then hand over control to the CD image.
An attic-based node will probably not have a keyboard attached to it. You'll want to disable the requirement in the BIOS that a keyboard be attached. Otherwise every time the node is turned off and back on it will hang on boot while it waits for a keyboard to be connected.
Other Node Possibilities
There are many other possible form-factors for CUWiNware nodes. These are currently untried but an adventurous community network designer could easily experiment with these possibilities.
- An old laptop or tablet PC could be converted into a node. It already has the PCMCIA slots and a small form factor. Because it is battery powered you could create a truly ad-hoc on-the-spot network anywhere if you had several of them.
- It is also possible that a laptop running the HSLS daemon on top of it's regular operating system could be a sort of "roaming" node on the mesh.
- The dream of cheap mesh nodes could be realized by flashing Access Points with CUWiNware. In order to do this CUWiNware will need to be stripped down to operate under MUCH tighter constraints but we believe this may be possible.
- CUWiNware could be installed on a hard drive in a node for R&D purposes. Then it'd be easier to tweak the contents of the running software without having to build and burn a new CD or compact flash image.
User's Guide
Introduction
The User's Guide section of the CUWiN manual is designed to help you after you have already decided which hardware setup is most relevant to you. Contained within this section is are how-to guides, node configuration information, and a trouble-shooting guide.
The CUWiNware package provides a completely self-contained, self-configuring bootable disk image for creating mesh wireless nodes for community wireless networks. The CUWiN developers distribute pre-built generic disk images for common disk types on the x86 architecture. Advanced users can also custom build a CUWiNware disk image from source code.
Because CUWiN is still engaged in an intensive development process, the software changes rapidly, as will the troubleshooting issues. When possible, we will try to be diligent about noting that particular troubleshooting issues are taken care of by particular upgrades. Also, we will try to transfer useful information from the developer's list regarding troubleshooting, but anyone responsible for maintaining a CUWiN network would be well advised to join the development list, which you can do under the Get Involved >> Mailing Lists.
Download Software
All images are distributed compressed with gzip. ISO and Compact Flash images will need to be uncompressed before they are copied onto media.
Images for official CUWiNware releases can be downloaded from SourceForge or from cuwireless.net.
Compact Flash Images ISO (CD-ROM) Updater Tarball
Compact Flash Images
Compact Flash images must be distributed according to the geometry of the compact flash device for which they are targeted. We distribute official images for SanDisk 64MB and for SanDisk 126MB Compact Flash cards. If you have a different compact flash card you will have to do a custom build from source code. It is important to note that the Soekris net4526 board which has 64MB of compact flash on board is NOT compatible with the SanDisk 64MB image. If you install a SanDisk 64MB image on a Soekris net4526 it will be bootable but it will not be online-upgradable.
The command to copy the staboot.img file to compact flash in NetBSD is
dd if=staboot.img of=/dev/rwd0d bs=8k
where rwd0d should be replaced with the raw device for the compact flash card.
ISO (CD-ROM)
ISO images are meant to be burned to CD-R which will then be bootable. Use your CD-R burning software to burn the disk. If the target platform can not boot from the CD-ROM drive then you will have to create a boot floppy. The CD-ROM you create will contain a file called /cuwboot/boot.img.
The command to copy the boot.img file to a floppy disk in NetBSD is
dd if=boot.img of=/dev/fd0a bs=1024 count=1440.
Updater Tarball
These files are just gzipped tars of the contents of the disk image. They are geometry independent. These tar files can be loaded by a special updater program on the compact flash versions of the software.
Installing the Software
Now that you have the software, you will need to install it on the node. Installing the software can be a complicated process. This page describes the various methods used to install software on the node. These methods can be broken down into the following methods: PXE Booting, Using the ISO, and Online Upgrading. So which one do you want to use? If you have purchased a Soekris board (or something similar), you will need to PXE Boot. If you are making a node out of an old computer, you are going to want to use the ISO. If you already have a functioning node but need to update the software, you can upgrade the node online (or by PXE booting, if you find that easier).
PXE Booting
A brand new net4526 or net4826 node has to be flashed with an initial version of the software. This is done by PXE booting the node, logging into it, and executing a dd to it's flash drive. PXE is a protocol for booting remotely over ethernet. In order to do this you will need to set up a PXE server.
If the node is already non-bootable then it'll default to PXE booting. If it has a bootable but non-upgradable image on it then you can render it unbootable by logging in and wiping out the boot block:
dd if=/dev/zero of=/dev/rwd0d count=32
Just connect the non-bootable node's ethernet to the same ethernet segment as the PXE server and turn it on. Within 2 minutes or so you should be able to log in to the node over the ethernet wire via SSH. You can then issue the following command:
dd if=/staboot.net4526.img of=/dev/rwd0d bs=8k
You can get the appropriate IP address to connect to by checking the PXE server's DHCP log or by pinging the broadcast address.
Instructions for PXE booting and setting up a PXE Server can be found in the "How-to" section of this manual.
Installing from an ISO
If you are using an old computer, you simply need to insert the live CD-ROM you created when you downloaded the software into the CD player. The system should boot on its own to CD-ROM. If it fails to do that, you will need to change your CMOS settings, which you can do by entering either DelF1, or Esc shortly after start-up. You will need to set your CD-ROM to be bootable before the harddrive becomes bootable.
Online Updates
If a compact flash node is bootable then it should be possible to do an on-line upgrade without a PXE boot server. This can be done over the wire or over the air.
Log into the node, become root, and run the script
/sbin/upgrade user@host:/path/to/upgrade.tgz
You will need to have the .tgz file on a host that is running sshd and is accessible to the node. Luckily sshd is available for all major platforms, including Windows (with Cygwin) so it is easy to turn any laptop into a roving upgrade platform.
Sometimes upgrades go badly. If you need to revert to your former installation, you should follow these instructions, provided by spditner.
If you find that the upgraded version isn't working all the great, you can roll back to the previously installed image by marking the alternate partition as "active".
# fdisk wd0 Partition table: 0: NetBSD (sysid 169) start 63, size 62497 (31 MB, Cyls 0/1/32-488/3/1) 1: NetBSD (sysid 169) start 62560, size 62496 (31 MB, Cyls 488/3/1-977), Active 2: 3: Set partition 0 as active: (WARNING, THIS WILL MODIFY YOUR PARTITION TABLE) # fdisk -af -0 wd0 # reboot
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:
o 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.
o 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 (
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.
No comments:
Post a Comment