SDCXTRA RADIO

Friday, April 10, 2009

A Recipe for Launching a Local Broadband Wireless Network





Local Network Cookbook:
A Recipe for Launching a Local Broadband Wireless Network

Introduction:

The American Recovery and Reinvestment Act includes $7.2 billion in stimulus funding for broadband deployment in unserved and underserved communities. This funding will be distributed by the National Telecommunications and Information Administration (NTIA) and the Rural Utilities Service (RUS) over the next 12 months. NTIA is an agency of the U.S. Department of Commerce; RUS is an agency of the U.S. Department of Agriculture. A summary of federal broadband stimulus funding can be found at: http://www.baller.com/pdfs/Baller_Herbst_Stimulus_2-19-09.pdf

Most of this federal broadband stimulus funding is earmarked for nonprofit organizations and government entities. Commercial providers must receive special permission from the director of NTIA. It is not yet clear whether RUS will adopt this funding approach. Grant application windows are expected in June, November, and May, 2010. These are approximate dates until an official request for proposal (RFP) is issued.

This is a once-in-a-lifetime opportunity for local nonprofit organizations -- especially community media centers -- to become Internet service providers and begin developing new revenue streams. It's also an historic opportunity for advocates of Internet Freedom. The proliferation of community-based, broadband networks would be a huge step toward creating the critical "third pipe" alternative to the cable/telco duopoly, thereby generating market pressure to force the major carriers to restore “net neutrality” protections for broadband users.

The broadband stimulus opportunity opens the door to a vision for a new Jeffersonian Internet comprised of a “network-of-grassroots-networks” where civil liberties and quality journalism are valued over Wall Street business models.

"Local Network Cookbook: A Recipe for Launching a Local Broadband Wireless Network" is aimed at helping nonprofit organizations -- especially those already using digital technologies -- move quickly to plan and submit a broadband stimulus funding proposal for one of the three application windows.

Why wireless? Some advocates believe that fiber-to-the-home should be the goal of U.S. broadband policy. While commendable, this view overlooks two critical factors: First, implementing this policy would take time, especially in rural areas. Wireless, meanwhile, could deliver broadband quickly in many rural and low-income urban areas, while a long-term fiber component is being pursued. Second, broadband is going mobile, which requires a wireless solution. Given these realities, it's clear that the best solutions for community-based networks will be some combination of fiber and wireless deployment. Fiber and wireless also provide symmetrical speeds – where upload and download speeds are roughly the same. By contrast, cable and DSL technologies are asymmetrical, whereby upload is a fraction of the download speed. That's why cable and DSL technologies have a limited future.

It's imperative that community-based groups seize this historic opportunity. The broadband stimulus funding guidelines are written to favor community-based networks; however, where local networks are not forthcoming, the absentee-owned networks of the cable/telco could prevail.

Underserved communities and neighborhoods -- both rural and urban -- have suffered long enough under absentee-owned networks. Advances in digital technologies now make it possible for even the smallest community to own and operate a broadband network. Moreover, local networks can build and operate broadband networks more cost-effectively because their designs do not include additional electronics for "deep packet inspection," a controversial digital-snooping technique that allows big carriers to track how customers use the Internet.

Local networks create local jobs, instead of outsourcing jobs overseas. Local networks also bring “social capital” benefits –- a critical ingredient for innovation -- because their IT experts live and work in the communities they serve. These local experts are thereby available to share their knowledge and experience with the community's schools, youth organizations, and local businesses. The social capital impact of local networks on innovation, job-creation, and economic development deserves serious attention from broadband policy analysts.

This recipe is aimed at locally-owned "last-mile" networks to serve homes and businesses. Some communities start with a "middle-mile" fiber network to help reduce wholesale bandwidth costs for local industry, hospitals, schools and government agencies. Too often, these networks leave the "last-mile" service to commercial providers, who -- by necessity -- cherry-pick the more lucrative business subscribers, leaving low-income neighborhoods underserved. This local network recipe, therefore, is aimed at potential nonprofit ISPs whose missions embrace digital inclusion. Let's get started with the basic ingredients.

Basic Ingredients:
1. Vision

2. The Need

3. IT Team

4. Upstream Internet Link

5. Network Design

6. Network Hardware

7. Wireless Transmitter Site:

8. Customer Premise Equipment (CPE)

9. Staffing and Operating Budget

1. The Vision -- Your vision can be simple (we want our own network) or more complex (a hybrid fiber-wireless network to support community journalism, etc). The important thing is to be flexible; let your vision evolve as circumstances and opportunities change. Community-based networks can address multiple problems and opportunities simultaneously. As a general rule, however, keep it simple if you're starting from scratch.

2. The Need -- Rural and urban low-income neighborhoods have the greatest need for affordable broadband. You may want to focus on a single neighborhood or town to start. The selection of your initial service area may be driven by existing assets, such as the location of your community radio station or PEG facility, or a community-owned tower, water tank, or tall building from which to deliver broadband wireless.

3. The IT Team -- Information technology (IT) is a highly technical field which can seem arcane and daunting to many community activists. Paradoxically, this may be the easiest step in building your own network. IT professionals are everywhere: every school system, hospital, community college, and local government has an in-house IT pro. Local computer clubs often have a wealth of IT expertise. IT pros usually have a solid understanding of Internet Freedom issues (digital inclusion, privacy, civil liberties, open-source, high cost of bandwidth, absentee-owned networks, etc). A few phone calls or a public meeting to share your vision is usually all it takes to begin assembling a solid IT team. Linux user groups (LUGs) are also an excellent source for IT professionals.

4. Upstream Link -- Your local IT pros can determine the cost and availability of the "fat pipe" you need to link your local broadband network to the Internet (more details below). Typical sources of this wholesale bandwidth (sometimes called the "middle-mile" or "backhaul" link) are the local phone or cable companies, or a "competitive local exchange carrier" (CLEC, one of the few good things to come out of the 1996 Telecom Act). Of course, the high cost of this wholesale bandwidth in rural areas is one of the great challenges we face, which is why some rural communities are building "middle-mile" fiber networks before tackling "last-mile" broadband service to homes and businesses. These community-based fiber networks typically start with a coalition of institutional users, such as hospitals, schools, government agencies, and major industries. Two examples of these nonprofit fiber networks are Berkshire Connect and ERC Broadband (for additional information on organizing a middle-mile fiber network, email: wallyb@main.nc.us).

5. Wireless Access Point -- This is typically a telecommunications tower, forest service fire tower, water tank, or roof of a tall building -- basically, any location which gives your wireless transmitter/antenna array an optimal viewshed of the area you want to serve. Rental fees for commercial cell towers are usually cost-prohibitive, while publically-owned structures can often be leased at low cost, or no cost in a barter arrangement.

6. Network Design -- Your IT team will draft a preliminary network design based on the area you plan to serve and the availability of the upstream link. The location of existing facilities (e.g. PEG studios or radio station) may also be key in your network design. Designing a network is like connecting the dots. The constraints of your existing assets, upstream link availability, and service area may limit you to a single network design. Or, your IT team may find several possible configurations for your network.

One of the most promising new 'last-mile' technologies is "mesh" wireless. The mesh network topology consists of very low-power radios -- called nodes -- strategically placed throughout a neighborhood to create an interconnected "mesh" network capable of more efficient bandwidth-sharing. Each node creates a giant Wi-Fi hotspot -- many times larger than a coffeehouse hotspot. Anyone with a Wi-Fi-enabled laptop in a "mesh" neighborhood can connect to the Internet. Roughly one-in-four of these nodes requires a direct connection to the Internet, enabling a more cost-effective way to extend affordable broadband access to more densely-populated underserved areas.

NOTE: Technology changes fast. If you're applying for a grant to build your own network, remember that funders are open to your changing the network design if a better option is found. Also, network hardware vendors are usually willing to give a free critique of your network design; their feedback can be very valuable. Just keep in mind their inherent bias toward their specific hardware solution.

7. Network Hardware -- Once your IT team has settled on a basic network design, you're ready to begin selecting your network hardware. If you're applying for a grant, it's usually OK to specify a particular hardware manufacturer, model and pricing (Motorola transmitter, etc) in order to flesh out your budget. However, as noted above, funders are generally open to your amending the budget if you find a more cost-effective solution between the time of your application and project implementation.

8. Customer Premise Equipment (CPE) -- This is the equipment which terminates your "last-mile" network at your subscriber's home or business. For wireless broadband networks, the CPE is typically a modem which can receive your network's wireless signal. This modem-receiver has a standard cable which plugs into a desktop computer or laptop (or Wi-Fi router for subscribers with Wi-Fi-enabled laptops). In most cases, the installation of the CPE will require a site-visit by your staff. However, as noted earlier, adding mesh technology to your network reduces the number of these modems you need to deploy, thereby reducing your labor and hardware costs.

9. Staffing & Operating Costs -- Designing, budgeting, and obtaining capital to build your network is the critical first step. The next step is calculating the ongoing operating costs of your network, which will also determine what you charge for broadband access. Some small wireless networks are two-person operations serving up to 500 subscribers. Their staff handles tech-support calls via mobile phones while they're in the field installing a new subscriber. A $200-a-year online accounting package allows them to sign-up new subscribers from their laptops in the field.

A more complex model is the nonprofit Mountain Area Information Network (MAIN) in Asheville, N.C. MAIN has four full-time technical staff (network director, assistant ND, webmaster, and tech support) plus several part-time wireless installers who work as needed. This tech staff is supported by a part-time receptionist and part-time billing/bookkeeper, and full-time executive director (who is mainly focused on policy, advocacy, and fundraising). This staff supports about 500 wireless subscribers over a four-county network (three rural counties plus the city of Asheville and environs). MAIN's taff also supports 1,200 local and national dial-up subscribers, more than 400 webhosting clients, and a low-power FM radio station. The LPFM station has a full-time manager who receives IT support from network staff and financial management/fundraising support from non-technical staff.

Four Basic Steps for Network Implementation
Once you have funding or financing to build your network, there are three basic steps for implementing your network plan.

Step One: Re-visit your IT team's plan for “upstream' bandwidth, as pricing and availability do change. This is the big “fat pipe” that takes all of your subscribers' traffic – in the aggregate -- to the Internet. Upstream bandwidth is usually leased from a phone, cable, or other 'middle-mile' provider. This wholesale bandwidth comes in two forms -- or measurements -- based on speed and/or capacity:

1. The T-1 line provides 1.5 megabits-per-second (mbps) and is usually leased from the local phone company. Individual T-1 lines can be "bundled" to increase network speed and capacity. For example, to create capacity of 3 mbps, you would have the provider “bundle” two T-1 lines.

2. Upstream bandwidth from other landline providers – such as a cable or fiber network (wireless on rare occasions) -- is usually measured and priced by the megabit. For example, MAIN's Asheville POP (telecom jargon for 'point of presence') has a capacity of 6.5 mbps. Our fiber provider is a local nonprofit called ERC Broadband, which we helped conceive. Our monthly rate is $124 per megabit.

How much bandwidth is enough? The 6.5 megabits our Asheville network consumes each month serves:

* 250 wireless subscribers with speeds beginning at 1 mbps, with symmetrical upload and download. (As noted earlier, cable and DSL broadband services are asymmetrical, which means the upload is only a fraction of the download speed. The reason for this discrepancy is that telephone and cable networks had to be re-engineered for broadband; this makeshift solution assumes that uploading content is a marginal need for broadband subscribers.)

* 400-plus domains (websites which we host);

* approximately 150 people who use our free Wi-Fi service (20 minutes a day);

Because all subscribers will not be downloading 3 mbps simultaneously, a single 3 mbps upstream link can support a large number of subscribers (150-200 or more), depending on time of day and types of usage (e.g. a relatively small number of "gamers" can quickly "soak" an upstream link). The correct subscribers-to-megabit ratio is a subject of passionate debate among network staff. There is no hard and fast rule.

Therefore, "networking monitoring" is standard operating procedure so that spikes in usage can be tracked and upstream capacity increased as needed. Some upstream providers will allow your usage to "burst" above the contracted limit; you simply pay the overage, thereby ensuring consistent network performance. "Traffic-shaping" tools are also available to optimize network performance.

Step Two: Set up your network hardware, which will terminate your upstream connection and form your broadband service platform, including email, hosting, etc.

Basic network hardware components are routers and servers.

a. Router -- The T-1 or fiber/cable upstream link connects to your core router. By using the open-source Linux operating system (OS), a core router can cost less than $1,000.

b. Servers -- For less than $2,000, these high-speed, high-capacity computers provide three basic services:

1. Domain name hosting (DNS) Example: www.yourname.com

2. Email services (including listserves, aliases, forwarding, etc)

3. Website hosting (a significant revenue stream for MAIN. We do not design or build websites; instead, we give referrals to our supporters in the local business community.

Many ISPs outsource these services with their upstream provider or with a third-party provider -- for as little as $300 a month for a complete package.

At MAIN, we "feed-and-water" our own servers because we are fortunate to employ a "Uber-geek" -- our webmaster -- who performs magic on these servers and is a terrific social-capital resource for local web-designers and our hosting clients.

Step Three: Set up your "last-mile" network to deliver broadband service to the home or business -- the end user.

As we await the unlicensed "white spaces" technology, the most common wireless technologies use existing unlicensed frequencies -- 2.4 GHz, 5.8 GHz, and 900 MHz. A new "lite-licensed" frequency -- 3.65 GHz -- promises far greater speeds and range (20 mbps with 25-30 mile range). Lite-licensing simply means that the geo-location of the transmitter must be registered with the FCC – via a simple online form – before deployment.

When MAIN launched its wireless broadband service in 2003, 900 MHz was the best "last mile" option, as this lower-frequency signal can "bend" to a small degree around buildings and ridges and penetrate foliage at close range (under two miles). Wireless broadband at 900 MHz can produce “non-line-of-sight” (NLOS) coverage at close range (1-2 miles). The two higher frequencies -- 2.4 GHz and 5.8 GHz – are strict "line of sight" (LOS) but can deliver a viable signal up to 20 miles or more, depending on power levels and signal concentration. The latest versions of these unlicensed technologies accommodate speeds of 4-8 mbps.

These wireless technologies are usually employed in three ways:

1. Last-mile to the home or business via a modem/receiver, which picks up the signal from the transmitter/attenna array;

2. Tower-to-tower (or roof-top to roof-top) to extend the reach of the network by connecting two or more transmitters to upstream bandwidth. These are known as “backhaul” links and can range up to 30 miles or more (LOS). They are critical in reaching underserved areas which do not have direct access to a fiber-based upstream provider.

3. "Mesh" wireless is a complementary "last-mile" application that can expand the network's reach and efficiency at lower cost. (Described above under "Network Design").

We are currently testing the 3.65 GHz "lite-licensed" technology, whose stronger signal and superior capacity supports higher speeds (up to 20 mbps) over greater distances (25-30 mile LOS) – and more subscribers. The 3.65 GHz technology is ideal for long backhaul links in rural areas. We are also hopeful that it can be used strategically in some of Asheville's densely-populated neighborhoods to provide greater speed and capcity for our Wi-Fi City mesh service.

Basic Wireless Access Point (WAP) (via a tower, water tank or roof of a tall building):

Transmitter: Generates the "juice" or electrical signal for broadband access. Cost range: $1,800 (up to 75 subscribers) to $3,800 (up to 300 subs). Multiple transmitters (technically a “transceiver” because they transmit and receive) are deployed to accommodate more subscribers.

Antenna: Omni-directional or sector. Omni antennas are ideal for small towns when mounted at a central location (courthouse roof or water tank). Their 360 degree coverage with effective ranges of 2-3 miles (NLOS) and 6 miles (LOS) works well in compact communities and neighborhoods.

Cost: Under $1,000

Sector antennas concentrate a signal over a 60, 90 or 120 degree area. A more concentrated sector (e.g. 60 degrees) yields a stronger signal and thus a greater range. Cost: Under $1,000

WAP Router: Routers for wireless access points range from $300 to $1,000.

Step Four: Hooking up the subscriber to your network. Strength-of-signal is the determining factor here. Avoid hooking-up subs with marginal signals, no matter how bad they want the service. They are at risk for disappointment – and can make life miserable for you and your staff.

As noted in item #8 above (“Customer Premise Equipment”), your subscriber will need either a modem to receive your wireless signal, or a Wi-Fi-enabled laptop if the sub is in range of one of your “mesh” nodes.

Modems are installed by hand and can sometimes require an additional outdoor antenna to get a sufficient signal. This type of installation can run $800 ($400 for the modem plus $400 for antenna, cabling, and labor).

Where the signal is stronger, an indoor modem can be placed near a window aimed toward the wireless access point (WAP). A cable is then run to plug into a desktop computer. Total cost: $500 (modem, cabling, and labor).

With mesh networking, a low-power node is added to either of the two installations described above. The node then broadcasts a Wi-Fi signal up to several thousand feet. That signal can then be picked up by anyone in the neighborhood with a Wi-Fi-enabled laptop.

Finding the optimum mix of modem and mesh subscribers is the goal of an efficient and high-performance wireless broadband network using current unlicensed frequenicies.

The field of wireless broadband technology for use in unlicensed frequencies is evolving fast. This summary is intended to provide a general and current snapshot of wireless broadband's costs, performance, and potential.

[EDITOR'S NOTE: “Local Network Cookbook” is a work-in-progress. Your feedback will help guide and refine it. Send comments and questions to: localnetworks@main.nc.us

Copyright 2009 Wally Bowen

Bridging the Rural Digital Divide: FCC Starts Work on National Broadband Strategy

Cables

The Federal Communications Commission, or the FCC, begins work today on a yearlong national broadband strategy to bring high-speed broadband internet into every American home. Under the $7.2 billion broadband stimulus plan, the FCC is responsible for developing a strategy to improve broadband coverage and present it to Congress in February of 2010. We speak with Wally Bowen, executive director of the Mountain Area Information Network in Asheville. [includes rush transcript]



Guest:

Wally Bowen, Executive director of Mountain Area Information Network, a nonprofit internet service provider that offers internet service in western North Carolina. It is based in Asheville, North Carolina. He is also the founder of the low-power FM station WPVM.

AMY GOODMAN: The Federal Communications Commission, or the FCC, began work yesterday on a yearlong national broadband strategy to bring high-speed broadband internet into every American home. Under the $7.2 billion broadband stimulus plan, the FCC is responsible for developing a strategy to improve broadband coverage and present it to Congress in February of 2010.

Acting FCC Chair Michael Copps has described the plan as, quote, “the biggest responsibility given to the FCC since the Telecom Act of 1996.” Improving and expanding internet service is expected to be a central part of the plan.

My next guest is Wally Bowen, longtime activist on bridging the rural digital divide. He is the executive director of the Mountain Area Information Network in Asheville, North Carolina, a nonprofit internet service provider that offers internet service in western North Carolina. He is also the founder of the low power FM station WPVM and a former member of the North Carolina Rural Internet Access Authority.

Wally Bowen, it’s nice to have you with us.

WALLY BOWEN: Great to be here, Amy.

AMY GOODMAN: It was great to be on PVM when I was in Asheville last time around.

WALLY BOWEN: Right.

AMY GOODMAN: But talk about what you think is most critical right now around the issue of rural broadband.

WALLY BOWEN: Well, it’s rural broadband and broadband in low-income urban neighborhoods. Well, it’s the stimulus package, it’s the $7.2 billion that you referenced, and it’s just an historic opportunity for the creation of local networks and moving away from the kind of absentee-owned networks that we’ve suffered under all these decades that are beholden to Wall Street and not beholden to our communities.

And what’s interesting about the $7.2 billion that has been allocated in the stimulus bill for broadband build-out is that the regulation is written specifically for community-based groups. It’s nonprofits, local and state governments are given priority for this funding. For-profit carriers, the Verizons and AT&Ts and the cable companies, have to show that they are working in the public interest before they’re eligible for any of this funding for a particular project. So the door is wide open for the creation of community-based internet service providers, like what we’ve been doing in western North Carolina.

AMY GOODMAN: Explain what MAIN is.

WALLY BOWEN: Mountain Area Information Network, it’s a nonprofit internet service provider, and what—we got started in around 1994, ’95, when we discovered that many of the rural counties here in the mountains had to call long distance to get on the internet. There was no public access at the public libraries for internet access. And so, we were fortunate enough to get a grant, a federal grant, to bridge the digital divide and put servers in each of these counties, and so people could get dial-up, get to the internet with a local phone call, and so there would also be public access at our public libraries.

And we woke up one day, and we were an ISP. And we had a business model. We had sustainable revenue. My background is journalism, so I always—you know, I was wanting to bridge the digital divide but also create sustaining revenue for journalism. And so, that’s what we’ve been moving toward all these years. And five years ago, we launched WPVM, a low power FM radio station, and brought Democracy Now! for the first time to Asheville public access TV. So we’ve been concentrating our efforts on creating media infrastructure that is grounded in our community and beholden to our community and not beholden to Wall Street.

AMY GOODMAN: As newspapers fold, what is this nonprofit model you see?

WALLY BOWEN: Well, you know, at the media reform conferences, when I present our work, it’s always this paradox, because all of us are trying to find a new way to do journalism and alternative media, and yet every month people are writing a check to Verizon, AT&T, Charter. And so, all those digital dollars are flowing out of our communities and going to these big companies that are working in the interests of Wall Street and not in the interests of democracy.

And so, what the community-based nonprofit ISP, internet service provider, does is capture some of those digital dollars, keeps them in the community to support things like low power FM radio, public access TV. Eventually we hope to be paying journalists to do stories in our community using this revenue from our ISP.

AMY GOODMAN: Explain how the stimulus package affects you.

WALLY BOWEN: Well, again, it’s just a historic opportunity, because we need to build our network out further to reach more people. We’re also using—most of the stimulus money we’re going to be going after will be used for fiber, to lay the groundwork, to extend our last-mile wireless network out further and reach more people.

One of the interesting things about western North Carolina is that we’re probably one of the only regions of the country that has both a last-mile wireless provider, which is Mountain Area Information Network, but a middle-mile, nonprofit fiber provider, which we have several of. One is a rural electric co-op, nonprofit, local. Another is called ERC Broadband; it’s a nonprofit we helped create through other allies in the community to own our own fiber. It’s reduced our bandwidth costs. We were paying $2,500 a month for a T1 line in 1996; we’re now paying about $200 for an equivalent amount of bandwidth. And so, we’ve been able to bring our bandwidth costs down, expand our capacity, because we have a locally owned fiber network and a locally owned last-mile network to reach homes and businesses.

This is a model that could be done anywhere in the country. And I’m particularly excited to be on your program, because you reach the 750 community-based media centers, community radio, public access operations that could also implement this model and thereby support their efforts by also helping bridge the digital divide.

AMY GOODMAN: And yet, public access is under attack right now.

WALLY BOWEN: Exactly, exactly. And so, you know, it’s just critical that we find alternative revenue streams, and here comes along the stimulus package, which is presenting that opportunity. One thing I’m concerned about is that—

AMY GOODMAN: And we just have thirty seconds.

WALLY BOWEN: —a lot of our colleagues in the media reform movement think that becoming an ISP is like rocket science. It’s not. And so, it’s just a terrific opportunity. I’ve drafted about a 5,000-word cookbook for local broadband networks, which is going up on our website today, Mountain Area Information Network, MAIN, main.nc.us, and maybe you could put it on the Democracy Now! website, as well .

AMY GOODMAN: We will link to it at democracynow.org.

WALLY BOWEN: But it’s a step-by-step process to show community radio, public access TV, community media centers around the country just how they can begin planning. The interesting thing about broadband stimulus is that the three windows for applications are June, November and May of next year, so there’s is still time to plan for broadband stimulus.

AMY GOODMAN: Well, I want to thank you for being with us. We will certainly link to your cookbook. What is it? A recipe book.

WALLY BOWEN: It’s a local broadband network cookbook, how to do it yourself.

AMY GOODMAN: And we’ll link to it at democracynow.org.

Thursday, March 19, 2009

Build and Install on a Soekris 4526 using Arch Linux - Part Eleven

Build and Install on a Soekris 4526 using Arch Linux

INSTRUCTIONS FOR PXEBOOT OF 4526 SOEKRIS BOARD WITH ARCH LINUX

*NOTE* Some of these instructions are specific to Arch Linux. If you would like to contribute instructions for other Linux distributions, please email them to us.

A text version of this document is available here: pxeboot4526archlinux.txt

SOFTWARE REQUIREMENTS:

    • A current Linux distribution (This tutorial was devised and tested on ArchLinux (http://www.archlinux.org)
    • GCC 3-4 and G++ 3-4 (and their dependencies)
    • Subversion (and its dependencies)
    • Wget
    • Minicom
    • Bunzip2

HARDWARE REQUIREMENTS

    • One Ethernet port
    • One serial port [We found that a USB-RS232 Serial Connector worked as well.]
    • One crossover cable
    • One cat5e cable
    • One null-modem cable
    • One power-over-ethernet injector [POE]

CONVENTIONS

Three different command line prompts will be used: # indicates the normal user; $ indicates the root user; and > indicates a prompt from the node. The end of all command line entries are signaled by the following notation: . All key strokes (e.g. Shift, Control, Enter, etc...) will use the following syntax: [e.g. , , etc.].

VI TUTORIAL

For text editing, we use VI, but feel free to use whatever text editor you like. Some useful vi commands:
i - enter the edit mode to change text
- to escape the edit mode
:q! - to exit without saving changes
zz - to save changes and exit

STEP 1: GETTING THE SOFTWARE IMAGE

M. The easiest way to get the software for your node is to go to http://cuwireless.net/node/208. You will need to download the pxeboot_ia32_com0.bin, netbsd.gz, and the update files. Download them and place them in your /var/tftpboot directory. [Directions for making the /var/tftpboot directory are in step 1B10.] Skip to step 1B12.

N. The best way to get the software is to compile it yourself. This is why we include GCC as a required package. These steps will help you compile the software from scratch. Be sure that you follow these directions as yourself, not as root.

      1. In this step, you will make a directory named "cuwin" in your home directory directory. At the command line, enter the following:
        # mkdir ~/cuwin
      2. Place the latest version of the CUWiN software in your home directory by typing:
        # svn co http://svn.cuwireless.net/svn/cuw/trunk
      3. Now we need to place the latest version of the NetBSD sources in your home directory. Enter:
        # wget http://superb-west.dl.sourceforge.net/sourceforge/wireless/cuwin-0.6.0-netbsd-src.tar.bz2
      4. Decompress the NetBSD files by entering the following at the command prompt:
        # tar -jxvf cuwin-0.6.0-netbsd-src.tar.bz2
      5. Move these directories and their contents to the directories you just created in 1.B.1:
        1. # mv trunk cuwin/cuw-trunk
        2. # mv cuwin-0.6.0-netbsd-src cuwin/scratch
      6. Make your .mkstabootrc file in your home directory and edit it:
        1. # vi .mkstabootrc
        2. Type
        3. Enter the following, where MACHINE_ARCH equals the processor architecture of your computer(i386 should be fine for most people):
d.        BUILDDIR=$HOME/cuwin/scratch
e.        SRC=$HOME/cuwin/scratch/src
f.          LOWER_FAT=yes
g.        MACHINE_ARCH=i386
        1. When you have typed the above information into the file, press .
        2. Exit the text editor by using the following command:
          :wq
      1. To fix a difference in syntax between Linux and *BSD, you may have to do the following:
        1. Edit the build.sh file in the NetBSD "src" directory
          # vi ~/cuwin/scratch/src/build.sh
        2. Find the line that reads "TOP=$(/bin/pwd -P 2>/dev/null)" by typing /pwd followed by pressing
        3. Type
        4. Edit the line to read "TOP=$(/bin/pwd 2>/dev/null)"
        5. Edit the text editor by typing :wq
      2. Move to the bootimage directory in the CUWiN source files by entering the following at the command line:
        # cd ~/cuwin/cuw-trunk/src/boot-image
      3. Start the compile process [This step takes a couple of hours to complete, so feel free to make other plans for about three hours.]:
        # ./buildmd
      4. Type "ls" at the command line. You should be able to find a file that has something similar to the following name:
 23-April-staboot.md 

If you do, you have successfully compiled the software. If not, don't be discouraged, that happens. We are working on a Troubleshooting Guide, but that may not be available for a few months. In the mean time, you should just use the sources provided on the website listed in 2.A.

      1. Assuming that you have successfully compiled the software, copy two files to the /var/tftpboot directory. The first command will create the /var/tftpboot directory. The next two commands will copy the required files.
        1. # mkdir /var/tftpboot
        2. # cp ~/cuwin/cuw-trunk/src/boot-image/23-April-staboot.img /var/tftpboot/netbsd
        3. [Because this command line is so long, it has been placed on the next line.]
          # cp ~/cuwin/scratch/O/sys/arch/i386/stand/pxeboot_com0_19200/pxeboot_ia32_com0.bin /var/tftpboot/pxeboot_ia32_com0_19200.bin
      2. Before we build the update file, we need to change the user accounts. To do this, we are going to need to move into the boot-image directory and change the passwords for root. Then we can add other users. Before you begin this step, be sure that you know what you want to make the root password and which new users you will want to add.
        1. # cd ~/cuwin/cuw-trunk/src/boot-image
        2. # ./cw_passwd ./pwds root
        3. The previous command prompts you for the new root password.
        4. # ./cw_passwd ./pwds newusername
        5. The previous command prompts you to enter the password for the account "newusername".
      3. Now we need to build an update file. First, you will return to the /boot-image directory. Then you will build the upgrade. Then you will copy the upgrade to the /var/tftpboot directory.
        1. # cd ~/cuwin/cuw-trunk/src/boot-image
        2. # ./buildelanup install
        3. # cp upgrade.tgz /var/tftpboot/.
      4. Change directories to the /var/tftpboot directory by entering
        # cd /var/tftpboot
      5. Compress the netbsd file by entering the following:
        # gzip netbsd
      6. Change the ownership and permissions of the /var/tftpboot directory and the files you just copied into /var/tftpboot by entering the following commands:
        1. # chown -R nobody:nobody /var/tftpboot
        2. # chmod -R 777 /var/tftpboot

Step 2: Setup the Network Boot

O. Get the most recent BIOS update from Soekris.

      1. Open your web browser and go to the following page: http://www.soekris.com/downloads.htm
      2. Save the most recent version of the BIOS to the /var/tftpboot directory.

P. DHCP Server [You will need root privileges for this step.]

      1. To find out if you have a DHCP Server running, type
        # ps wuax | grep dhcp
        If there is something on the next line (e.g. /etc/init.d/dhcpd or /usr/sbin/dhcpd), you have a DHCP Server already installed and running and you should proceed to Step 2.B.4.
      2. To find out if you have a DHCP Server installed, type
        # find /etc /usr/local/etc -name '*dhcp*' print
        If you see a file named "dhcpd.conf", you have a DHCP Server installed and should skip to Step 2.B.4.
      3. Install the DHCP Server by entering the appropriate installation command for your distribution:
        1. For ArchLinux:
          # pacman -Sy dhcp
      4. At this point, you will need to configure your DHCP server. NOTE: MAKE SURE THAT YOU ARE DISCONNECTED FROM YOUR NETWORK! RUNNING THIS SERVICE MAY DESTROY YOUR NETWORK. Enter the following commands:
        1. # vi /etc/dhcpd.conf

        2. Enter the following:
d.        subnet 192.168.1.0 netmask 255.255.255.0 {
e.          option routers 192.168.1.101;
f.            option subnet-mask 255.255.255.0;
g.          range 192.168.1.1 192.168.1.15
h.        }
i.          class "pxe-clients-ia32" {
j.            match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
k.           next-server 192.168.1.101;
l.            filename "pxeboot_ia32_com0_19200.bin";
m.       }
n.        class "netbsd-pxe-clients-ia32" {
o.          match if substring(option vendor-class-identifier, 0, 17) = "NetBSD:i386:libsa";
p.          next-server 192.168.1.101;
q.          filename "tftp:netbsd.gz";
r.         }
        1. zz
      1. Configure your Ethernet Device.
        1. Determine your Ethernet. When you use the following command, the item that says, "Link encap: Ethernet" is the Ethernet device [from here on, the Ethernet device will be indicated by dev0:
          # ifconfig -a
        2. Find out your IP address and subnet mask. The important line should look something like: inet 10.0.0.103 netmask 255.255.255.0 broadcast
          # ifconfig dev0
        3. Release and reset the current IP address by entering the following:
          1. # ifconfig dev0 down
          2. # ifconfig dev0 inet 192.168.1.101 netmask 255.255.255.0
          3. Now, if you enter "ifconfig dev0", you should see a line that reads:
 inet 192.168.1.101 netmask 255.255.255.0 broadcast 192.168.1.255 

Q. TFTP Server: There are two different ways to do this. The first is to use either inetd or xinetd, and the second is to start the tftpd daemon standalone, either manually or with a script [You will need root privileges for this step.]

      1. Now you need to edit the TFTP Server Configuration. TFTPD requires the INETD service. If you have inetd, you will need to edit /etc/inetd.conf.
        1. # vi /etc/inetd.conf
        2. Move to the line below and put the cursor on the "#". Press DEL to remove the comment mark.
 tftp    dgram   udp     wait    root    /usr/libexec/tftpd      tftpd -l -U 777 -s /var/tftpboot 
        1. zz
      1. If you are using xinetd, you will have to create a file in your /etc/xinetd.d entitled "tftp"
        1. # vi /etc/xinetd.d/tftp
        2. Type
        3. Insert the following in the file:
d.       service tftp
e.       {
f.             socket_type             = dgram
g.           protocol                = udp
h.           wait                    = yes
i.             user                    = root
j.             server                  = /usr/sbin/in.tftpd
k.            disable                 = yes
l.         }
      1. The other method is to start tftpd manually:
        1. # ls /etc/rc.d/
          Where /etc/rc.d is your init scripts directory. (Possibly /etc/init.d/) If you see a file entitled in.tftpd, tftpd, tftp, or similar, then you can most likely start the daemon by typing at the prompt:
          # /etc/rc.d/tftpd start
        2. Otherwise, you can most likely start tftp manually
          # /usr/sbin/in.tftpd -l -U 777 -s /var/tftpboot
          or
          # /usr/libexec/tftpd -l -U 777 -s /var/tftpboot

R. Allow the system to run TFTP and DHCP daemons. [You will need root privileges for this step.]

      1. Edit your /etc/hosts.allow file

1. # vi /etc/hosts.allow

2. Add the line in.tftpd:all

3. Type :wq

Step 3: Update the BIOS and flash the node [You will need root privileges for this step.]

S. Restart network services by entering the following commands (Depending on your distribution, your initscripts directory may be something different from /etc/rc.d/, like /etc/init.d/ or /usr/local/etc/rc.d/):

      1. # /etc/rc.d/dhcpd start
      2. # /etc/rc.d/tftpd start
      3. # /etc/rc.d/sshd start

T. Plug the null-modem cable into the serial port on your computer and the serial port on the Soekris board. If you do not have a serial port on your computer, you may need to use a USB-to-serial adapter cable. Now, plug the Crossover Cable into your computer's Ethernet port and the "Data" port on the POE injector. Make sure that the POE injector has power [there should be a green light on top to indicate that it has power].

U. Now you will need to run Minicom in order to connect to the node over the serial line

      1. Enter su and the root password when prompted.
      2. Now you will need to access the node console. At the command prompt, enter: # minicom
      3. Hit the key combination Ctrl-A Z to bring up the options screen, and select "Serial Port Setup." The correct settings BP/Par/Bits settings are 19200 8N1, and all flow control should be turned off. The serial device is the device file of your serial port. If you're using USB-to-serial, it will most likely be something like /dev/tts/USB0.
      4. Break into the comBIOS monitor with -P at the beginning of the boot process. [This may happen quickly when the node is started, so be prepared.]
      5. At the > prompt, enter the following commands:
        > download
        ~C lsx b4501_xxx.bin

        [where xxx is the number of the Soekris BIOS upgrade; note: the ~C can be a bit tricky. Think of it as follows: Press and hold the key, then press <~> and then ]
      6. When you are returned to the > prompt, enter: > flashupdate
      7. When the update is complete, you will need to reboot. Do that by entering: > reboot

V. Set the node to PXE boot.

      1. Break into the comBIOS monitor again with -P.
      2. At the prompt, enter: > set bootdrive=f0 80 81 ff
      3. Enter: > reboot

W. At this point, your node should PXEboot from your computer. A successful PXEboot looks like this:

X.                           Pre-boot eXecution Environment  PXE-2.0 (build 082)
Y.                           Copyright (C) 1997-2000  Intel Corporation
Z.                     
AA.                  
BB.                        CLIENT MAC ADDR: 00 00 24 C3 A8 40
CC.                       CLIENT IP: 192.168.1.9  MASK: 255.255.255.0  DHCP IP: 192.168.1.101
DD.                       GATEWAY IP: 192.168.1.101
EE.                  
FF.                  
GG.                       >> NetBSD/i386 PXE Boot, Revision 1.1
HH.                       >> (rgmussel@cuw.ojctech.com, Sun Apr 23 07:50:45 CDT 2006)
II.                            >> Memory: 582/64512 k
JJ.                          Press return to boot now, any other key for boot menu
KK.                        Starting in 0
LL.                         PXE BIOS Version 2.1
MM.                      Using PCI device at bus 0 device 6 function 0
NN.                       Ethernet address 00:00:24:c3:a8:40
OO.                       net_open: client addr: 192.168.1.9
PP.                        net_open: subnet mask: 255.255.255.0
QQ.                       net_open: net gateway: 192.168.1.101
RR.                       net_open: server addr: 192.168.1.101
SS.                        net_open: file name: tftp:netbsd.gz
TT.                        2159776+33612688-
  

UU. Update the node

      1. Log into the node using the root password: changeme
      2. Enter: # stty erase Control-v
      3. Enter: # fixlabel
      4. Enter: # ifconfig sip0
      5. Find a line that looks something like this:
 inet 10.168.64.254 netmask 0xffffff00 
      1. Enter:
        # ifconfig sip0 inet 10.168.64.254 netmask 0xffffff00 -alias
      2. Enter: # ifconfig sip0
        You should see a line that looks something like this:
 inet 192.168.1.7 netmask 0xffffff00 broadcast 192.168.1.255 
      1. Ping the server to verify your connection:
        # ping 192.168.1.101 -c 5
        You should see lines like this:
 64 bytes from 192.168.1.101: icmp_seq=0 ttl=64 time=0.656 m 
      1. Enter:
        # upgrade -f blah@192.168.1.101:/var/tftpboot/upgrade.tgz
        where blah is your user name. If that is successful, you should see something like this:
10.                               fdisk: DIOCGDEFLABEL: Invalid argument
11.                               fdisk: DIOCGDINFO: Invalid argument
12.                               Disk: /dev/rwd0d
13.                               NetBSD disklabel disk geometry:
14.                               cylinders: 977, heads: 4, sectors/track: 32 (128 sectors/cylinder)
15.                               total sectors: 125056
16.                         
17.                               BIOS disk geometry:
18.                               cylinders: 977, heads: 4, sectors/track: 32 (128 sectors/cylinder)
19.                               total sectors: 210453442400
20.                         
21.                               Partition 0:
22.                               NetBSD (sysid 169)
23.                                    start 32, size 62512 (31 MB, Cyls 0-488/2/17)
24.                               Making partition 0 active.
25.                               Preparing for upgrade on /dev/wd0e.
26.                               /dev/rwd0e: 30.5MB (62512 sectors) block size 8192, fragment size 1024
27.                                using 4 cylinder groups of 7.63MB, 977 blks, 1920 inodes.
28.                               super-block backups (for fsck_ffs -b #) at:
29.                               32, 15664, 31296, 46928,
30.                               Installing the upgrade.
31.                               The authenticity of host '192.168.1.101 (192.168.1.101)' can't be established.
32.                               DSA key fingerprint is a8:75:fe:7d:46:b7:a8:05:65:77:43:7a:67:e7:a4:fc.
33.                               Are you sure you want to continue connecting (yes/no)?yes
34.                               Warning: Permanently added '192.168.1.101' (DSA) to the list of known hosts.
35.                               Password:
36.                               100% |*************************************|  4041 KB  237.68 KB/s    --:-- ETA
37.                               Updating etc/fstab
38.                               Updating primary bootstrap
39.                               Updating active partition
40.                               Disk: /dev/rwd0d
41.                               NetBSD disklabel disk geometry:
42.                               cylinders: 977, heads: 4, sectors/track: 32 (128 sectors/cylinder)
43.                               total sectors: 125056
44.                         
45.                               BIOS disk geometry:
46.                               cylinders: 977, heads: 4, sectors/track: 32 (128 sectors/cylinder)
47.                               total sectors: 210453442400
48.                         
49.                               Partition 1:
50.                               NetBSD (sysid 169)
51.                                    start 62544, size 62512 (31 MB, Cyls 488/2/17-977)
52.                               Making partition 1 active.
53.                               Copying existing /etc/cuw_config.
54.                               Upgrade complete (/dev/wd0e).
55.                                #
      1. After that runs, type the following at the command line to reboot the node: shutdown -r now

VV. When you are finished, you will want to exit Minicom. Do that by typing Shift-Q.

Technical Documentation

HSLS

HSLS is the routing protocol that has been developed by CUWiN based on a technical paper from BBN. This routing protocol is specially designed to be scalable for ad-hoc mesh wireless networks. The HSLS daemon communicates with the kernel's routing tables via the Zebra daemon which provides some future portability to other operating systems.

The HSLS README explains how to invoke the HSLS daemon. On the standard CUWiNware image hslsd is started with these parameters.

CUWiNware has specified an HSLS packet format.

The ETX Protocol

Introduction

This protocol is intended to provide the expected transmission count (ETX) routing metric based on the work of the M.I.T. Computer Science and Artificial Intelligence Laboratory [1], and be used between routers on ad hoc wireless networks.

Protocol Description

The Expected Transmission Count (ETX) path metric is a simple, proven routing path metric that favors high-capacity, reliable links. The ETX metric is found from the proportion of beacons sent but not received in both directions on a wireless link.

Each participant router broadcasts a beacon to its one hop neighbors at a configurable interval. Each beacon contains the protocol version, flags and a sequence number. The beacon contains a list of the router's one hop neighbors. For each neighbor a history of whether or not the beaconing router received a beacon from this neighbor is included. The history includes the last BITFIELD_LENGTH (32) of this neighbor's beacon intervals. An optional set of extensions may be included. No extensions exist at this time.

At a configurable interval, the cost of the link associated with each peer is computed based on expected probability of beacons to be transmitted and received. See Receiving Beacons and Computing Link Costs.

Beacon Flags

ETX_F_INIT - this flag MUST be set for the first BITFIELD_LENGTH transmissions made by an ETX router. It is used to distinguish sequence number wrap-around. See Sending Beacons and Receiving Beacons.

ETX_F_EXTENSIONS - indicates that a beacon contains extensions. If set, each peer block in the beacon MUST contain at least one extension block. See Extensions.

ETX_F_SUSPEND - May be set by a router to indicate that it will be out of communication for some length of time. If set, the beacon MUST contain the 32-bit time of return field. See Transmitting Beacons.

Receiving Beacons

Upon receiving a beacon it is implicitly required that certain data must be available in order for the router to conform to the protocol. For example it is necessary to have accurate expectations regarding the arrival of future beacons from this neighbor.

When beacons are received from a previously unheard of neighbor, the data for the new neighbor are initialized appropriately. It is added to the neighbor list and the contents of the bit field are processed in full (dependent on the ETX_F_INIT flag).

If the beacon is from a neighbor that is already known, its sequence number is compared to the sequence number of the last beacon received from this neighbor. If the sequence number of the received beacon is less than or equal to the most recently received sequence number these statistics are recorded for MIB. If the sequence number of the received beacon is within BITFIELD_LENGTH intervals of the last heard sequence number, the previous bits of the affected bits in the bitfield are set accordingly.

The sequence number of the incoming beacon is compared to the currently expected sequence number from this neighbor. If it is less or more than expected these statistics are recorded for MIB. The bitfield is updated with the available data.

A sequentially valid beacon is processed as follows. Each sequence number that has passed since the last beacon received from this neighbor it is inferred that no beacon was received. Beacon received is set for the current beacon interval. This updated bitfield is used to recompute the probability of beacons being received from this peer. See Computing Link Costs.

Additionally, we expect that the received beacon will contain a peer block for the localhost. The bitfield from this block is used to recompute the probability of beacons being transmitted to this peer. See Computing Link Costs.

Transmitting Beacons

At each beacon interval, the router must assemble and broadcast a beacon to its one-hop neighbors. The sequence number MUST start at 0 and be incremented by exactly 1 with each beacon transmitted. The ETX_F_INIT flag MUST be set for the initial BITFIELD_LENGTH beacons transmitted.

For each known neighbor a valid bitfield must be determined. If a beacon was expected but not received, the bitfield must be updated accordingly (an expected and received beacon will have already been processed). If this neighbors beacon interval
is longer than the local beacon interval, the bitfield should not be updated until the neighbor beacon interval has expired. If the neighbor interval is shorter than the local interval, the extra bits of the bitfield must be evaluated (if these beacons have been received, they will already be set correctly).

Computing Link Costs

Periodically, the data of known peers is used to compute the cost associated with the link to that peer. To do so, smoothed probability ratings of transmission to and reception from each peer are used. Let 'srxp_k' and 'stxp_k' represent these respective probabilities for some peer at interval 'k'.

The cost of the link with this peer is computed as

cost_k = 1 / (srxp_k * stxp_k)

The probability of receiving from this peer is computed as

    Let srxp_0 = rx_0
        srxp_k = h * srxp_k-1 + (1-h) * rx_k 
    where rx_k = 1 if a beacon was received, 0 otherwise.

The values of rx_k are read from the bitfield associated with this peer. 'h' is a configurable value that specifies the influence of a single interval on the probability.

In the event that either srxp_k = 0 or stxp_k = 0, the cost is set to 1.

The probability of transmitting to this peer may be computed in the same manner, in this case the values of tx_k are read from the peer block corresponding to the localhost in the beacon received from this peer.

It is possible that no tx data is available for a number of reasons:

    1. a beacon was not received from this peer. A configurable tentative value is used for tk_k. If this beacon is received late, the actual value must be substituted in at that time.
    2. the received beacon did not contain a peer block referring to the receiver. The value of tk_k = 0 is used.
    3. the beacon's ETX_F_INIT flag is set and the 'k' interval is not yet valid (as determined by the sequence nubmer). This interval should not be included in computing the link cost.

For efficiency it is not desirable to recompute the probabilities at every BEACON_INTERVAL. The following formula may be used to include several intervals in a single recomputation:

    Let srxp_0 = rx_0
                                                                                         k
        srxp_k = h^k * rx_0 + (1-h) * Sum( h^(k-i) * rx_i )
                                                                                        i=1

Beacon Format

An ETX beacon consists of a 32-bit header, containing an 8-bit version number, 8-bit flags, 16-bit beacon interval and 32-bit sequence number. In the beacon interval the highest 11 bits are interpreted as a mantissa, while the lower 5 are an exponent. The actual beacon interval is m * 2**e microseconds.

If and only if the ETX_F_GLOBAL_EXTENSIONS flag is set, the header includes a global extensions block. The format is identical to the Peer extension blocks described below. No global extensions exist at this time.

If and only if the ETX_F_SUSPEND flag is set the header includes by a 32-bit field containing the expected time to return, in multiples of the beacon interval. The value of 0 indicates unspecified time, perhaps never.

The remainder of the beacon consists of one or more ETX peer blocks. An ETX peer block consists of the 128-bit IPv6 address of the peer. IPv4 addresses are encoded as v6 addresses. The address is followed by the bitfield (32-bit) for the peer. In the bitfield, the least significant bit is always most recent. During the ETX_F_INIT stage, the most significant bits are set to zero and are not used. If and only if the ETX_F_EXTENSIONS flag is set in the beacon header, the peer block concludes with one or more ETX Extension blocks.

An ETX Extensions block consists of a 16-bit extensions-used bitmask, and a 16-bit field indicating the length, in octets, of the extension block, not counting the Bitmask and Length fields. Extension blocks are padded with zeroes to a 32-bit boundary. To allow for more than 16 extensions, the most significant bit in the extensions-used bitmask is reserved to indicate another extension block follows.

Beacon Diagram

 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Version #   |    Flags      |       Beacon Interval         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                       Sequence Number                         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    (   Global Extensions Bitmask   |    Global Extensions Length   )
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    (   Time expected to return, iff ETX_F_SUSPEND flag is set.     )
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +-                                                             -+
    +-              IPV6 address (ipv4 padded to ipv6)             -+
    +-                                                             -+
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                            Bitfield                           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    (    Extensions Used Bitmask    |  Length of Extensions Block   )
    (-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-)
    (                            .......                            )
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    +-                                                             -+
    +-              IPV6 address (ipv4 padded to ipv6)             -+
    +-                                                             -+
    |                            .......                            |
 
    Beacon Flags
 
    0x0001 ETX_F_INIT
    0x0002 ETX_F_EXTENSIONS
    0x0004 ETX_F_SUSPEND
    0x0008 ETX_F_SECURE
    0x0010 ETX_F_GLOBAL_EXTENSIONS
 
    Extensions Bitmask
 
    0x8000 ETX_E_MORE_EXTENSIONS
 
    Global Extensions Bitmask
 
    0x8000 ETX_E_MORE_EXTENSIONS

Management Information Base

Beacon Interval - specifies how frequently this router transmits a beacon. It is not necessary that all routers use the same interval. Valid range is [ 2^(-8), 3^7 ].

Link Compute Interval - specifies how frequently this router recomputes link costs. No range limits apply. This parameter does not affect interoperability with other routers.

Hysteresis - This value controls the impact of a single interval when computing the smoothed probabilities of transmitting to and receiving from each peer. See Computing Link Weights.

Statistics - statistics of abnormal or unexpected behaviour are available to the MIB. See Receiving Beacons.

Security Considerations

At this time, ETX has no authentication and no confidentiality which presents certain vunerabilities. For example, a malicious or faulty router could transmit beacons that cause false link costs to be calculated. The mechanism of global extensions (see Beacon Format) may be used in future revisions to sign beacons.

References

[1] D. Decouto, D. Aguayo, J. Bicket, and R. Morris, "A high-throughput path metric for multi-hop wireless networks", in Proceedings of MobiCom, 2003.

Network Watchdog

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

I have added a "network watchdog" to the CUWiN station software. The way it works is that every time hslsd receives a Hello on the wireless interface, it runs a shell script, /usr/sbin/tickle, to "tickle" a shell "watchdog" daemon. The "tickling" is rate-limited to once every 15 seconds or more.

As long as the shell daemon, /usr/sbin/hellowdog, is getting tickled at least once every 5 minutes, it lays dormant. (I realize I'm mixing metaphors here.) If 5 minutes do elapse without a tickle, hellowdog wakes up and tries to restart hslsd. If that doesn't work (because, for example, hslsd is already running!), then it puts wdogctl to sleep. wdogctl is in charge of tickling the hardware watchdog timer. At most 32 seconds after wdogctl is put to sleep, the system will reboot.

In theory, if the wireless adapter or hslsd goes "out to lunch," the network watchdog will bring the router back onto the network in 5 minutes plus 32 seconds plus however long it takes for the node to reboot.

CUWiN Network IP Schema Design

This document describes the IP schema we use. The main point is that the DHCP server on non-Internet connected nodes assigns numbers on the ethernets from 10.A.B/24, where A and B are made by hashing the MAC number. A != 0.

Numbers are assigned to the wireless interface in the form 10.0.A.B/16.

OSPF

We will assign numbers to stations from 10.0/16. The last 16 bits are the XOR of the first two octets of the MAC number, the second two octets, and the third octets, where the bytes are taken in "reading order." That is, we produce numbers 10.0.A.B from the MAC numbers. If the MAC produces A = 0, B = 0 or A = 255, B = 255, then A and B are assigned randomly. The netmask is /16.

(We compute numbers from the MAC to begin with because in the common case, a station will boot with the same A and B every time, which is useful for diagnostic purposes.)

The host networks are assigned from 10/8. We assign to each Ethernet interface, a network 10.A.B.0, where A and B are computed as above from the Ethernet MAC number. If A = 0, we re-assign it randomly. The netmask is /24.

We run OSPF in point-to-multipoint mode on each wireless interface. The wireless and wired interfaces should be configured with 'network zzzzz/x area 0' clauses under the 'router ospf' command. All other interfaces are run in passive mode (i.e., no OSPF Hellos are sent).

802.11b

We will use channel 11. The SSID is 'cuw', all lower case, without the single quotes.

Known Limitations

Missing from this design are authentication, naming, etc.

We have not solved the BSSID partitioning problem. We will have to watch out for this (perhaps Prism-based cards such as ours are not affected).

Implementation

Linux implementation for Soekris board.

CD-ROM implementation of the new network design.

WiFiDog

Homepage

    • embedded captive portal
    • authentication server
    • central control
    • full bandwidth control
    • node heartbeating
    • local content specific to each hotspot and to each user (text, images, audio, rss feeds, flickr via the api)
    • doesn't rely on a javascript window, so it works with any platform with a web browser, including PDAs and cellphones that can only open one window (as well as console-based browsers)

As of 6 August 2006, WiFiDog has not yet been integrated into CUWiN software.

Building CUWiNware From Source

You can build your own CUWiNware images from the CUWiN sources with your local modifications included. Local modifications that you can make include setting up a default config file, changing the default root password and adding default local users, adding public key authentication for login to the nodes. You can also build against newer NetBSD sources to update the available kernel drivers and if you are a programmer you can freely modify the code as you see fit.

In order to build the software you will need a working NetBSD build environment. Once you have that you will need both the CUWiN sources and an appropriate NetBSD source snapshot.

You can get NetBSD sources either from sourceforge by downloading the cuwin-x.y.z-src-netbsd.tar.gz file or by going to NetBSD's anonymous CVS server and grabbing the CURRENT sources.

You can get the CUWiN sources via SVN from http://svn.cuwireless.net/svn/cuw/trunk/ or from anonymous CVS at sourceforge or by downloading cuwin-x.y.z-src-main.tar.gz from sourceforge. You will also need the src-extern file from sourceforge. The source forge downloads are source snapshots used to make our releases whereas the SVN and CVS repositories have the bleeding edge code.

Once you have unpacked all the sources you should have a trunk/src/boot-image directory. Parallel to the "trunk" directory you can create a "private-trunk/image-data" directory. In that directory you can put in local customization files that will be used instead of the defaults during the build process:

authorized_keys/

This directory contains files named after usernames. The contents of the file are put in the user's .ssh/authorized_keys file within the built image.

cuw_config

This file will be installed at /etc/cuw_config instead of the default.

known_hosts/

This directory contains files named after usernames. The contents of the file are put in the user's .ssh/known_hosts file within the built image.

pwds

This file has /etc/passwd style entries for each user that should be added to the built image. This overwrites the default root password.

When the tree is configured for build as you'd like it, you can call the mkstaboot script to build the sources into an image. The build script is a helper that makes calling mkstaboot easier. The Perl script nightly-test.pl calls build for several different targets and provides a good example for how it is called. Read over the comments in these scripts before attempting to build.

If you need help building CUWiNware please contact cu-wireless-info@cuwireless.net

Anonymous CVS and SVN access

Posted to the mailing list on October 1st, 2004 by Zach Miller.

Please note that anonymous CVS and SVN access are now both available.

Anonymous CVS has been available for some time but until recently updates have been broken.

Anonymous CVS is hosted by Source Forge:

Information: http://sourceforge.net/cvs/?group_id=89823
Web CVS Viewer: http://cvs.sourceforge.net/viewcvs.py/wireless

To checkout use these commands:
cvs -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/wireless login
cvs -z3 -d:pserver:anonymous at cvs.sourceforge.net:/cvsroot/wireless co cuw-trunk

Don't forget that you should use "cvs update -dP" when updating to make sure you get the right directories in your tree.

Anonymous SVN is hosted on cuwireless.net:
Browseable URL: http://svn.cuwireless.net/svn/cuw
svn checkout http://svn.cuwireless.net/svn/cuw/trunk

Both repositories are READ-ONLY. Please submit patches to this email list for discussion and eventual inclusion by the core developers.

mkstaboot

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

I got fed up with waiting 10+ minutes for mkstaboot to run, even with -u -o, so I broke mkstaboot into several stages. Now I can do routine rebuilds---after I modify, say, hslsd---in just 10 seconds.

The new mkstaboot and, by extension, build{,upgrade,iso,flash}, take two new options:

% mkstaboot -h
usage: mkstaboot [ ... ] [ -L ] [ stage ]
-L List the mkstaboot stages and quit.
stage Restart mkstaboot at this build stage.

Here are the build stages, in the order they will be built:

% ./buildupgrade -s ~/radix-nbsd/src/ -L
tools
toolenv
makewrapperenv
iso-kernel
flash-kernel
distrib
metalog
patch
makewrapper
mv-root-home
extras
users
modules
cuwinize-metalog
install
postinstallenv
flash
upgrade
floppy
iso

For example, if I run "./buildupgrade -s ~/radix-nbsd/src -f disk.img install", mkstaboot will restart at the 'install' stage of the build, skipping all of the preceding stages on the -L list, UNLESS

o the stage ends in an 'env' suffix

o the stage did not run to completion during the last build

o some prior stage did not run to completion

If I do not tell mkstaboot to restart at any stage, then it starts at the beginning.

A few caveats:

o I've tried hard to make stages idempotent, but at least one of them ('patch') is not.

o I do not (yet) leave out any build stage based on the options. That is, the 'iso' stage will run (although it will be a null operation) even if I don't use an '-i' option.

o It is still a good idea to use -u and, if you know what you're doing, -o, as they are indicated, to speed up your build.

Just a few bullets about the architecture of the staged builds:

o In steps.d/ are the build stages. They get "sourced" (with '.') by mkstaboot. They are derived from the old mkstaboot sources.

o steps.d/deps is a two-column list of stage dependencies: for every row, the stage on the left-hand side cannot be run until the stage on the right-hand side has completed. If you add new stages, be sure to add them to steps.d/deps !

o In $BUILDDIR/, mkstaboot touch(1)es ..begin when a stage begins; it touches ..end if and when the stage finishes successfully. Next time you run a build, if ..end is newer than ..begin, then the stage ran successfully.

o POSIX touch(1) has a time resolution of 1 second. Therefore, the shell command "touch a ; touch b ; test b -nt a && echo yes" does not necessarily yield the string "yes". Sometimes it's necessary to sleep for a second before touching ..end. Sleeping synchronously will slow the build by a lot. So mkstaboot sleeps in the background. Hence the "joining pid xxx" messages at the end of a build.

o step.subr contains most of the logic for deciding which build stages to run, when.

FCC Votes to Open TV White Spaces for Unlicensed Use

DatePublished by Dana Spiegel on November 3, 2008 under News Comments 1 Comment »

Lost in the (understandably) overwhelming media coverage about the new President of the United States, the FCC has voted to open “white spaces” between TV channels to unlicensed use. This is a big decision that will lead to more open devices and a big push for extending wireless internet access to areas where the internet was previously unavailable or limited.

NYCwireless supports this FCC decision, and we look forward to making use of white space devices to help bring more internet to all areas of New York City. You can read about it in the New York Times and Ars Technica.


After Tests, FCC Finds White Space Devices Don’t Cause Interference

DatePublished by Dana Spiegel on October 11, 2008 under News Comments No Comments »

As a follow up to the City Council Hearing on White Space Devices, the FCC has completed their tests of devices that use spectrum white spaces, and concluded that they work well with the other existing devices using the same spectrum:

A report released yesterday by the Federal Communications Commissionconcluded that using empty airwaves to provide free wireless Internet would not cause major interference with other services, paving the way for FCC Chairman Kevin J. Martin’s proposal to sell the airwaves at a federal auction.

* Has divestiture worked? A careful examination of the consequences of divestiture and deregulation over the last 25 years.

* America is ranked 15th in the world in broadband. What role does America’s closed broadband networks (e.g., Verizon’s FiOS and AT&T’s U-Verse) play in such a ranking? Do closed networks fulfill last mile requirements of the Telecom Act of 1996?

* The Obama administration and Congress have put together a massive economic stimulus package, including broadband infrastructure projects. Does this new legislation address the major issues or are other steps necessary?