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.

In this step, you will make a directory named "cuwin" in your home directory directory. At the command line, enter the following:
# mkdir ~/cuwin
Place the latest version of the CUWiN software in your home directory by typing:
# svn co http://svn.cuwireless.net/svn/cuw/trunk
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
Decompress the NetBSD files by entering the following at the command prompt:
# tar -jxvf cuwin-0.6.0-netbsd-src.tar.bz2
Move these directories and their contents to the directories you just created in 1.B.1:

# mv trunk cuwin/cuw-trunk
# mv cuwin-0.6.0-netbsd-src cuwin/scratch

Make your .mkstabootrc file in your home directory and edit it:

# vi .mkstabootrc
Type
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

When you have typed the above information into the file, press .
Exit the text editor by using the following command:
:wq

To fix a difference in syntax between Linux and *BSD, you may have to do the following:

Edit the build.sh file in the NetBSD "src" directory
# vi ~/cuwin/scratch/src/build.sh
Find the line that reads "TOP=$(/bin/pwd -P 2>/dev/null)" by typing /pwd followed by pressing
Type
Edit the line to read "TOP=$(/bin/pwd 2>/dev/null)"
Edit the text editor by typing :wq

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

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.

# mkdir /var/tftpboot
# cp ~/cuwin/cuw-trunk/src/boot-image/23-April-staboot.img /var/tftpboot/netbsd
[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

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.

# cd ~/cuwin/cuw-trunk/src/boot-image
# ./cw_passwd ./pwds root
The previous command prompts you for the new root password.
# ./cw_passwd ./pwds newusername
The previous command prompts you to enter the password for the account "newusername".

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.

# cd ~/cuwin/cuw-trunk/src/boot-image
# ./buildelanup install
# cp upgrade.tgz /var/tftpboot/.

Change directories to the /var/tftpboot directory by entering
# cd /var/tftpboot
Compress the netbsd file by entering the following:
# gzip netbsd
Change the ownership and permissions of the /var/tftpboot directory and the files you just copied into /var/tftpboot by entering the following commands:

# chown -R nobody:nobody /var/tftpboot
# chmod -R 777 /var/tftpboot

Step 2: Setup the Network Boot

O. Get the most recent BIOS update from Soekris.

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

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

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.
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.
Install the DHCP Server by entering the appropriate installation command for your distribution:

For ArchLinux:
# pacman -Sy dhcp

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:

# vi /etc/dhcpd.conf
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.         }

Configure your Ethernet Device.

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
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
Release and reset the current IP address by entering the following:

# ifconfig dev0 down
# ifconfig dev0 inet 192.168.1.101 netmask 255.255.255.0
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.]

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.

# vi /etc/inetd.conf
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

If you are using xinetd, you will have to create a file in your /etc/xinetd.d entitled "tftp"

# vi /etc/xinetd.d/tftp
Type
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.         }

The other method is to start tftpd manually:

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

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/):

# /etc/rc.d/dhcpd start
# /etc/rc.d/tftpd start
# /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

Enter su and the root password when prompted.
Now you will need to access the node console. At the command prompt, enter: # minicom
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.
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.]
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 ]
When you are returned to the > prompt, enter: > flashupdate
When the update is complete, you will need to reboot. Do that by entering: > reboot

V. Set the node to PXE boot.

Break into the comBIOS monitor again with -P.
At the prompt, enter: > set bootdrive=f0 80 81 ff
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

Log into the node using the root password: changeme
Enter: # stty erase Control-v
Enter: # fixlabel
Enter: # ifconfig sip0
Find a line that looks something like this:

 inet 10.168.64.254 netmask 0xffffff00

Enter:
# ifconfig sip0 inet 10.168.64.254 netmask 0xffffff00 -alias
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

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

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

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:

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.
the received beacon did not contain a peer block referring to the receiver. The value of tk_k = 0 is used.
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

        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

Published by Dana Spiegel on November 3, 2008 under News 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

Published by Dana Spiegel on October 11, 2008 under News 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?

SDCXTRA RADIO

Thursday, March 19, 2009